Quando os uploads do ownCloud travam em 99%, verifique estes limites.

Quando a página de Arquivos do ownCloud estiver em 99%, verifique primeiro se o arquivo completo já aparece na pasta de destino antes de tentar novamente. Se estiver faltando ou incompleto, peça ao administrador para verificar a cota de usuário, o espaço livre nos diretórios temporários do PHP e nos arquivos chunk do ownCloud, e também os limites de requisições do PHP e do servidor web. Um indicador de 99% não é suficiente para identificar qual parte falhou.

Este guia prático aborda os uploads realizados através da interface web do ownCloud Server (Classic) 10.16. Os uploads do Infinite Scale e do desktop-sync utilizam caminhos de servidor e logs diferentes. Os exemplos seguem a documentação oficial da versão 10.16; utilize as configurações e os caminhos de arquivo para a sua própria implementação.

Triagem rápida

1. Confirme o estado do upload antes de tentar novamente.

Abra a pasta de destino em uma segunda aba ou atualize-a após o upload parar de atualizar. Se o arquivo estiver presente, compare seu tamanho em bytes com o original local e abra-o. Um arquivo completo com uma barra de progresso desatualizada indica uma falha na resposta de conclusão ou um problema de exibição no navegador; isso não justifica o envio de uma segunda cópia.

Se o arquivo estiver ausente ou for menor, tente com um arquivo de teste pequeno na mesma pasta e, em seguida, tente com o arquivo original usando outro navegador ou rede, se disponível. Anote o tamanho do arquivo, o usuário, o destino, o tempo aproximado e se o teste falhou. Essas comparações ajudam a diferenciar um problema específico de um arquivo ou cliente de um problema que afeta todo o servidor. Evite cancelar e reiniciar repetidamente um upload grande enquanto o servidor ainda estiver processando-o.

2. Verifique a cota, o espaço temporário e as permissões.

Peça ao administrador do ownCloud para verificar a cota do usuário afetado e a permissão de gravação da pasta de destino. Um limite de cota pode impedir que um novo arquivo seja armazenado, mesmo quando o navegador já tiver enviado a maior parte dos dados. Se o destino for um ponto de montagem externo, verifique também o espaço disponível e o acesso de gravação desse servidor.

No servidor, verifique os blocos livres e os inodes no diretório de dados e em todos os diretórios temporários relevantes. Um inode é o registro do sistema de arquivos usado para criar um arquivo; um volume pode ter gigabytes livres, mas nenhum inode disponível. Use os caminhos reais da sua configuração do PHP e do ownCloud:

df -h /path/to/owncloud-data /path/to/php-temp /path/to/chunk-temp
df -i /path/to/owncloud-data /path/to/php-temp /path/to/chunk-temp

Os arquivos PHP upload_tmp_dirdevem ter permissão de escrita para a conta do servidor PHP/web. O ownCloud também possui uma configuração de diretório temporário, e os uploads de partes são armazenados temporariamente no diretório de uploads do usuário por padrão. Durante a montagem, o ownCloud pode precisar de espaço temporário aproximadamente igual ao tamanho final do arquivo. O usuário dav.chunk_base_dirpode alterar esse local. Verifique todos esses volumes, não apenas o disco de dados principal.

3. Ajuste os limites de upload e os tempos limite aos do arquivo.

Se arquivos pequenos funcionarem, mas um arquivo maior não, compare o tamanho dele com as configurações efetivas do PHP na web: upload_max_filesizee post_max_size. O PHP exige post_max_sizeque seja maior que upload_max_filesize. Verifique a configuração do PHP usada pelo servidor web ou pelo PHP-FPM; a configuração do PHP na linha de comando pode ser diferente. Em configurações do PHP-FPM, o ownCloud observa que as configurações do PHP pertencem a .user.iniou à configuração do FPM, e não apenas a .htaccess.

Analise também max_input_timequando os uploads demoram muito e o tempo limite de execução do PHP, caso os logs mostrem um timeout. Defina limites para sua carga de trabalho esperada, em vez de copiar um número de exemplo; reinicie ou recarregue o PHP e o servidor web após alterar a configuração. Consulte a Configuração de Upload de Arquivos Grandes do ownCloud e a referência da diretiva de upload do PHP .

Em seguida, verifique cada camada HTTP à frente do PHP. O Nginx client_max_body_sizerejeita corpos de requisição muito grandes com HTTP 413; defina-o com um valor suficientemente alto para o tamanho da requisição usada pelo seu caminho de upload. O Apache LimitRequestBodytambém mod_reqtimeoutpode restringir uploads. O ownCloud alerta especificamente que proxies reversos, Cloudflare, limites de E/S de hospedagem e configurações de tempo limite de requisição do Apache podem afetar uploads grandes. Altere apenas a camada implicada pelos logs e evite desativar módulos de segurança globalmente como primeira solução. Consulte a documentação oficial do Nginx sobre corpo de requisição .

4. Utilize os registros para localizar a camada com falha.

Reproduza o problema uma vez, anotando o horário, e verifique o log do ownCloud e o log de erros do servidor web ou proxy para aquele mesmo minuto. O log do ownCloud geralmente fica no diretório de dados configurado; o caminho exato pode ser alterado em config.php. Procure por mensagens sobre cota, permissões, arquivos temporários, bloqueios, tamanho da requisição ou tempo limite. Se a requisição não aparecer no log do ownCloud, investigue primeiro o proxy ou o servidor web.

tail -n 100 /path/to/owncloud.log

Substitua o marcador pelo caminho configurado na sua instalação. O comando exibe apenas as linhas de log recentes; ele não altera os dados do servidor. Evite publicar logs brutos sem remover nomes de usuário, caminhos de arquivos, endereços IP e tokens. O ownCloud explica a localização dos logs em sua documentação de depuração .

Verifique a correção

• Faça o upload de um arquivo pequeno e, em seguida, tente novamente com o arquivo afetado.
• Confirme se a cópia de destino tem o tamanho esperado e abre corretamente.
• Verifique se não há erros de cota, armazenamento, HTTP 413, permissão ou tempo limite no momento do upload.
• Se o problema persistir, forneça ao administrador o tamanho do arquivo, o destino, o registro de data e hora e a entrada de log correspondente para que ele possa identificar a camada que interrompeu a solicitação.

Não aumente todos os limites nem desative as proteções de requisição de uma só vez. Uma alteração direcionada, seguida de uma nova tentativa controlada, facilita a confirmação da causa e mantém o restante da configuração do servidor intacto.