Corrigir o problema de congelamento do upload de arquivos no ownCloud em 99%: Guia prático de solução de problemas

Um upload no ownCloud que chega a 99% e depois parece congelar geralmente não é resolvido reiniciando o upload repetidamente. Nesse ponto, o navegador pode já ter transferido a maior parte ou todo o arquivo enquanto o servidor ainda está concluindo tarefas como receber o último fragmento, montar os fragmentos, mover o arquivo completo para o destino, atualizar metadados ou liberar bloqueios. A porcentagem por si só não identifica a causa, portanto, a abordagem mais rápida é verificar as evidências do lado do servidor em uma ordem específica.

Este guia utiliza a documentação de administração atual do ownCloud Server 11.0, disponível em outubro de 2026. Os mesmos conceitos se aplicam a muitas implementações do ownCloud Classic, mas os caminhos de configuração e o comportamento do Docker podem ser diferentes em versões mais antigas. Antes de alterar os limites, confirme a versão instalada e o método de implementação.

Lista de verificação para diagnóstico rápido

1. Reproduza o problema uma vez e, em seguida, inspecione os registros imediatamente.

Faça um upload controlado com um arquivo que reproduza o problema de forma consistente e anote o horário exato. Em seguida, inspecione o log do ownCloud, o log do PHP e o log de erros do servidor web em torno desse horário. Não faça várias alterações de configuração primeiro; isso dificulta a identificação de qual camada realmente falhou.

A documentação oficial de resolução de problemas do ownCloud recomenda explicitamente verificar primeiro os logs do PHP, Apache e ownCloud. Na implantação padrão do Docker, o ownCloud documenta que a saída do Apache e do PHP é roteada através do stdout/stderr do contêiner e sugere acompanhar os logs do contêiner com docker compose logs owncloud -f.

Você também pode obter o log do ownCloud na interface de administração. O guia de log e configuração do ownCloud descreve o caminho através de Configurações > Administração > Geral e oferece uma occ configreport:generateopção para gerar um relatório de configuração mais completo quando necessário.

Que mensagens de registro você deve procurar?

Concentre-se no primeiro erro associado à solicitação com falha, e não em todos os avisos subsequentes. Categorias úteis incluem tempos limite de solicitação, armazenamento insuficiente, impossibilidade de criar ou renomear um arquivo temporário, erros de permissão, exceções WebDAV, respostas HTTP 413/502/504 e falhas de bloqueio de arquivos. Se você aumentar temporariamente o nível de registro do ownCloud para DEBUG, retorne-o ao nível normal posteriormente; o ownCloud observa que o registro detalhado pode afetar o desempenho do servidor. Consulte a referência oficial de configuração de registro .

2. Verifique o espaço livre tanto nos locais temporários quanto no local de armazenamento final.

Esta é uma das verificações mais importantes para uma paralisação de 99%. O ownCloud Server 11.0 explica que os uploads podem usar mais de uma área temporária. O diretório temporário de upload do PHP deve ter espaço para os fragmentos ativos, enquanto o diretório de upload do usuário coleta os fragmentos de um arquivo até que o upload seja concluído.

De acordo com a documentação do ownCloud sobre upload de arquivos grandes , o espaço temporário do PHP deve ser planejado aproximadamente como o número de uploads simultâneos multiplicado pelo tamanho do fragmento. Mais importante ainda, para um único arquivo grande, o diretório de upload do usuário precisa temporariamente de espaço comparável ao tamanho final do arquivo, pois ele armazena os fragmentos até que a montagem seja concluída. Assim que o upload termina, o ownCloud grava os fragmentos no destino final e os remove.

Verifique o sistema de arquivos que contém o diretório de dados, o diretório temporário do PHP e qualquer local configurado por meio de OWNCLOUD_DAV_CHUNK_BASE_DIR. Verifique também o destino real, especialmente quando o alvo for um armazenamento externo. Um servidor pode ter bastante espaço livre em /enquanto um volume de dados separado está cheio.

Não mova arquivos manualmente para dentro ou para fora do diretório de dados do ownCloud para "finalizar" o upload. O ownCloud alerta que seu diretório de dados é exclusivo do aplicativo; modificações diretas podem causar inconsistências de sincronização e no banco de dados.

3. Confirme a quota antes de aumentar os limites técnicos.

Uma cota de usuário pode bloquear um arquivo final grande, mesmo quando a área de armazenamento temporário de upload tem espaço suficiente. Verifique a cota do usuário afetado e, se relevante, a capacidade e as permissões de um ponto de armazenamento externo montado. Um teste útil é enviar o mesmo arquivo para outra conta ou destino com espaço claramente suficiente. Se a falha ocorrer com o usuário ou pasta, e não com o arquivo em si, a cota ou a política de armazenamento passa a ser a causa mais provável.

4. Revise as configurações de upload do PHP e do ownCloud.

Se os registros apontarem para limites de tamanho de requisição ou de execução, revise as configurações efetivas do PHP em vez de presumir que os valores em um php.iniarquivo aleatório estejam ativos. Diretivas comuns incluem post_max_size` upload_max_filesize--request -size` , `--request-size`, `--request-size`, `--request-size` e `--request - upload_tmp_dirsize` .max_input_timemax_execution_timememory_limit

Para a configuração do ownCloud Server 11.0 em Docker, a documentação mapeia estas variáveis ​​para os seguintes parâmetros: OWNCLOUD_MAX_UPLOAD`< nome_da_variável >`, OWNCLOUD_TEMP_DIRECTORY` <nome_da_variável>`, `<nome_da_variável>`, `<nome_da_variável >` e `<nome_da_variável >`. Isso é importante porque o ownCloud afirma que as implementações que utilizam sua configuração em Docker devem usar as variáveis ​​de ambiente fornecidas, em vez de depender de padrões antigos do PHP ou de personalizações.OWNCLOUD_MAX_INPUT_TIMEOWNCLOUD_MAX_EXECUTION_TIMEOWNCLOUD_MEMORY_LIMIT.htaccess

Não defina todos os limites com números extremamente altos. Um objetivo melhor é um valor que acomode o tamanho máximo de arquivo pretendido e a conexão legítima mais lenta, preservando as medidas de segurança operacionais.

5. Verifique a duração da sessão para uploads lentos.

O ownCloud alerta especificamente que o session_lifetimetempo de upload não deve ser menor que o tempo de upload mais longo esperado. Se você o personalizou, defina-o para pelo menos o número de segundos necessário para o upload mais lento esperado ou remova um valor personalizado desnecessário e retorne ao comportamento padrão compatível.

Isso é particularmente importante verificar quando um arquivo de 500 MB termina de ser baixado, mas um arquivo de vários gigabytes falha repetidamente após aproximadamente o mesmo período de tempo.

6. Teste o proxy reverso ou a CDN separadamente.

A documentação do ownCloud sobre arquivos grandes observa que proxies e serviços do lado do cliente, como o Cloudflare, podem restringir uploads. Isso significa que uma pilha ownCloud/PHP perfeitamente configurada ainda pode falhar porque outro nó limita o corpo da requisição, armazena em buffer uma requisição longa, fecha uma conexão ociosa ou atinge o tempo limite enquanto o ownCloud monta o upload.

Se sua arquitetura permitir um teste administrativo seguro, compare o mesmo upload pela rota pública normal e por um caminho que contorne o proxy reverso ou a CDN. Se o caminho direto for bem-sucedido, verifique a documentação oficial desse intermediário para obter informações sobre tamanho da requisição, tempo limite de upload, buffer e comportamento do WebDAV. Não enfraqueça o TLS nem exponha o backend publicamente apenas para realizar este teste.

7. Verifique o bloqueio de arquivos quando os uploads falharem durante a finalização.

O bloqueio transacional de arquivos está ativado por padrão e protege os arquivos contra mutações simultâneas. O ownCloud documenta que isso também é importante quando uploads em partes estão sendo reunidos. Em servidores ocupados, um problema de bloqueio pode se manifestar como uma transferência concluída, mas que não pôde ser confirmada corretamente.

Antes de alterar este subsistema, revise a documentação sobre bloqueio de arquivos transacionais . O ownCloud recomenda o uso de um cache de memória como backend para bloqueio em cargas de trabalho mais pesadas, em vez de depender do bloqueio do banco de dados. Em implantações em cluster, o bloqueio compartilhado do Redis é particularmente importante, pois todos os nós da aplicação devem visualizar o mesmo estado de bloqueio.

Há também um caso especial documentado para uploads muito longos para pastas públicas quando o particionamento (chunking) não está em vigor. O ownCloud afirma que uploads com duração superior a uma hora podem exigir um tamanho de arquivo suficientemente grande OWNCLOUD_FILELOCKING_TTL; caso contrário, a coleta de lixo do Redis pode remover o bloqueio adquirido no início da operação. Não altere essa configuração a menos que seu caminho de upload corresponda a esse cenário.

8. Realize novos testes metodicamente após cada alteração.

Após corrigir um problema identificado, tente novamente com o mesmo arquivo, conta, destino, navegador e caminho de rede. Em seguida, verifique três coisas: o processo é concluído, o arquivo aparece no destino com o tamanho esperado e os registros não contêm um novo erro para essa solicitação.

Uma progressão útil é usar um arquivo pequeno, um arquivo médio e, finalmente, o tamanho do arquivo que causou a falha originalmente. Se arquivos pequenos sempre forem baixados com sucesso, mas as falhas começarem a ocorrer acima de um tamanho repetível, concentre-se na capacidade de armazenamento e nos limites de tamanho. Se as falhas começarem após um período repetível, concentre-se nas sessões e nos tempos limite. Se elas ocorrerem apenas em um nome de host ou caminho de rede específico, concentre-se em proxies e balanceadores de carga.

O que não fazer

• Não tente repetidamente enviar arquivos de vários gigabytes sem verificar os registros. Falhas repetidas no envio de blocos consomem tempo e podem consumir espaço de armazenamento temporariamente.
• Não modifique o diretório de dados do ownCloud manualmente. Use o ownCloud, WebDAV ou ferramentas de administração compatíveis.
• Não desative o bloqueio de arquivos como primeira solução. O bloqueio protege a integridade dos dados; em vez disso, diagnostique o problema no servidor.
• Não assuma que uma configuração do PHP seja efetiva apenas porque aparece em um arquivo de configuração. Contêineres, PHP-FPM, módulos do Apache e múltiplos locais de arquivos INI podem gerar configurações efetivas diferentes.
• Não aumente indefinidamente todos os tempos limite. Identifique a camada que está fechando a solicitação e defina um limite apropriado para a taxa máxima de upload suportada.

Caminho de decisão prático

Se precisar de um guia rápido, siga esta ordem: reproduza o problema uma vez; leia os logs do ownCloud/PHP/servidor web; verifique o armazenamento de dados, temporário e em partes; verifique a cota; confirme as configurações de upload e tempo de execução; inspecione o tempo de vida da sessão; ignore ou inspecione o proxy reverso/CDN; por fim, investigue o bloqueio transacional. Esta ordem prioriza evidências e as restrições de infraestrutura com maior probabilidade de ocorrência antes de alterações de configuração arriscadas.

O detalhe importante é que "99 por cento" não é um código de erro em si. Ele indica onde o usuário percebeu o problema, não qual componente o causou. A solução confiável vem da comparação do registro de data e hora da falha no upload com evidências de armazenamento, tempo limite, proxy, sessão ou bloqueio no servidor.