Corrija o aviso "A interface WebDAV parece estar com problemas" confirmando se o endpoint DAV do ownCloud está acessível e se o seu servidor web está encaminhando as requisições WebDAV, incluindo o PROPFINDmétodo, para a aplicação PHP do ownCloud. A alteração correta depende de qual componente, Apache, Nginx ou proxy reverso, está lidando com a URL pública; teste o endpoint antes de editar a configuração para corrigir a camada com falha.
Descubra o que o aviso está realmente testando.
O verificador administrativo do ownCloud Classic exibe este aviso quando a verificação de sincronização de arquivos não consegue usar a interface WebDAV. Em muitos casos, trata-se de um problema no servidor web ou no caminho da requisição, e não uma prova de que os arquivos ou o banco de dados estejam corrompidos. A documentação oficial de avisos do ownCloud Server 11 descreve esse aviso separadamente da verificação de descoberta /.well-known/caldavde /.well-known/carddavserviços.
Use o endpoint DAV correspondente ao seu caminho de instalação público. Na raiz do domínio, o endpoint geralmente é `/var/www/owncloud` https://cloud.example.com/remote.php/dav; quando instalado em um subdiretório, inclua-o, por exemplo, `/var/ www https://cloud.example.com/owncloud/remote.php/dav/owncloud`. O ownCloud Classic 10.16 também documenta a URL de compatibilidade /remote.php/webdavpara algumas conexões de desktop e gerenciador de arquivos. Não considere a URL antiga do cliente e o novo endpoint DAV como intercambiáveis em todas as configurações.
Envie uma PROPFINDsolicitação autenticada com profundidade zero. Neste comando, substitua o host/caminho e o nome de usuário de exemplo. O Curl solicita a senha porque apenas o nome de usuário é fornecido para -u:
curl -i -u 'USERNAME' -X PROPFIND \
-H 'Depth: 0' \
'https://cloud.example.com/owncloud/remote.php/dav'
Uma resposta WebDAV bem-sucedida é tipicamente 207 Multi-Status. Interprete outras respostas como pistas: 301ou 302aponta para um redirecionamento ou problema de URL canônica; 401significa que a autenticação não foi aceita; 404frequentemente significa que o caminho ou a reescrita PHP não alcançou o ownCloud; e 405ou 501sugere que um servidor, proxy ou camada de segurança rejeitou o método DAV. Um navegador abrir a URL com uma página de login não prova que PROPFINDfunciona.
Escolha a solução de acordo com o layout do servidor web.
Apache: mantenha as regras de reescrita do ownCloud ativas
Para uma instalação padrão do Apache, primeiro verifique se o arquivo fornecido pelo ownCloud .htaccessestá presente e se o Apache permite suas diretivas de reescrita no diretório de instalação. O instalador e o processo de atualização do ownCloud mantêm essas regras. Se isso AllowOverride Noneimpedir o Apache de lê-las, permita as substituições necessárias para o diretório do ownCloud ou mova as regras equivalentes para a configuração do host virtual. A primeira opção é mais fácil de manter para um site ownCloud típico; regras de host virtual centralizadas podem ser preferíveis quando a política exige configuração fora dos diretórios do aplicativo.
Não cole um bloco de reescrita genérico sobre uma configuração funcional. Confirme se mod_rewriteestá habilitado, se o site aponta para o diretório raiz correto do ownCloud e se as requisições /remote.php/davchegam ao manipulador PHP. Após alterar a configuração do Apache, execute o teste de configuração antes de recarregá-lo. No ownCloud Classic 11 baseado em Docker, a imagem gerencia sua configuração Apache embutida; use os mecanismos de configuração e ambiente suportados pela imagem em vez de editar arquivos gerados dentro de um contêiner em execução. Consulte a documentação de solução de problemas do ownCloud Server 11 .
Nginx: utilize a configuração do servidor ownCloud
O Nginx não lê .htaccessarquivos do Apache. Se o Nginx estiver servindo o ownCloud diretamente, use a configuração do Nginx que corresponda à sua versão do ownCloud e ao caminho de instalação, incluindo o tratamento de localização do PHP e o roteamento relacionado ao DAV. Uma localização mínima personalizada do PHP pode servir a interface web, mas retornar /remote.php/davum erro 404 ou encaminhá-la para o manipulador errado. Compare seu bloco de servidor ativo com a documentação de instalação do ownCloud 10.16 do fornecedor , teste a configuração e reinicie o Nginx. As diretivas exatas dependem da distribuição, do socket PHP-FPM e se o ownCloud está na raiz do domínio ou em um subdiretório.
Proxy reverso: preservar caminho, método e URL pública
Se um proxy encerrar o HTTPS ou rotear um subcaminho como `/` /cloud, verifique se ele encaminha todo o caminho DAV para o servidor e permite métodos WebDAV como PROPFIND`get` PUT, `get` MOVE, `get` e `get` DELETE. Um proxy ou firewall de aplicação web pode bloquear um método mesmo quando o endpoint PHP estiver correto. Compare uma requisição enviada pela URL pública com uma enviada diretamente para o servidor a partir de uma rede confiável; se o acesso direto retornar 207, mas a requisição pública falhar, concentre-se na rota do proxy, no filtro de métodos, nos redirecionamentos e nos cabeçalhos de autorização.
Configure o ownCloud apenas trusted_proxiespara endereços de proxy reais. Se a detecção automática de URL falhar, as configurações `<url>`, overwritehost`<url> overwriteprotocol` e overwritewebroot`<url>` podem descrever a URL pública, mas não corrigem um método DAV bloqueado ou uma rota PHP ausente. Uma confiança incorreta no proxy pode permitir cabeçalhos de endereço do cliente falsificados. Use as diretrizes oficiais de configuração de proxy reverso para sua topologia.
Mantenha a descoberta de DAV separada do acesso a arquivos.
Os URLs /.well-known/caldavde /.well-known/carddavdescoberta ajudam os clientes de calendário e contatos a descobrir os endpoints de serviço. Eles devem ser roteados para o endpoint DAV do ownCloud, mas uma falha nesse endpoint gera um aviso separado daquele referente a uma verificação WebDAV de sincronização de arquivos com falha. Corrigir apenas esses redirecionamentos de descoberta pode não eliminar o aviso de sincronização. Para o Apache, as regras padrão do ownCloud podem lidar com a descoberta quando ativadas; implantações em Nginx e subdiretórios exigem uma configuração de servidor correspondente. Verifique cada URL e seu destino de redirecionamento individualmente, seguindo as orientações oficiais de aviso do ownCloud .
Verifique o reparo
Repita o PROPFINDteste autenticado com a URL DAV pública e confirme se ela retorna o resultado esperado 207 Multi-Status. Em seguida, atualize a página de administração do ownCloud e execute um pequeno teste de sincronização com o cliente desktop. Se a solicitação ainda falhar, compare o status HTTP e o carimbo de data/hora com os logs do servidor web, proxy, PHP e ownCloud. No Docker, a documentação do ownCloud observa que os logs do aplicativo podem estar no diretório de logs montado, enquanto os logs do Apache e do PHP são enviados para a saída do contêiner; docker compose logs owncloudisso pode ajudar a localizar esses erros.
Os manuais atuais do ownCloud abrangem as versões Classic 11.0 e 10.16, e o comportamento de instalação varia de acordo com a versão; a documentação da Classic 11 especifica o Docker como o método de instalação suportado. Use o manual da versão que você está utilizando e evite aplicar trechos de código antigos do Apache ou Nginx indiscriminadamente a uma configuração de contêiner ou proxy mais recente.