Rétablir la synchronisation WebDAV d'ownCloud en trouvant le chemin rompu

Pour corriger l'avertissement « L'interface WebDAV semble défectueuse », vérifiez que le point de terminaison DAV d'ownCloud est accessible et que votre serveur web transfère les requêtes WebDAV, y compris la PROPFINDméthode, à l'application PHP d'ownCloud. La modification appropriée dépend du serveur (Apache, Nginx ou proxy inverse) qui gère l'URL publique ; testez le point de terminaison avant de modifier la configuration afin de corriger la couche défaillante.

Découvrez ce que l'avertissement teste réellement.

L'outil de vérification d'administration d'ownCloud Classic signale cet avertissement lorsque sa vérification de synchronisation des fichiers ne peut pas utiliser l'interface WebDAV. Il s'agit souvent d'un problème de serveur web ou de chemin de requête, et non d'une preuve que les fichiers ou la base de données sont endommagés. La documentation officielle d'ownCloud Server 11 décrit cet avertissement séparément de la /.well-known/caldavvérification /.well-known/carddavde découverte de services.

Utilisez le point de terminaison DAV correspondant à votre chemin d'installation public. À la racine du domaine, ce point de terminaison est généralementhttps://cloud.example.com/remote.php/dav ; s'il est installé dans un sous-répertoire, incluez-le, par exemplehttps://cloud.example.com/owncloud/remote.php/dav . ownCloud Classic 10.16 documente également l'URL de compatibilité /remote.php/webdavpour certaines connexions de bureau et de gestionnaire de fichiers. Ne considérez pas l'ancienne URL du client et le nouveau point de terminaison DAV comme interchangeables dans toutes les configurations.

Envoyez une PROPFINDrequête authentifiée avec une profondeur nulle. Dans cette commande, remplacez l'hôte/le chemin et le nom d'utilisateur d'exemple. Curl demande le mot de passe car seul le nom d'utilisateur est fourni -u.

curl -i -u 'USERNAME' -X PROPFIND \
  -H 'Depth: 0' \
  'https://cloud.example.com/owncloud/remote.php/dav'

Une réponse WebDAV réussie est généralement `true` 207 Multi-Status. Interprétez les autres réponses comme des indices : 301`false` 302indique un problème de redirection ou d'URL canonique ; ` 401false` signifie que l'authentification a échoué ; `false` 404indique souvent que le chemin ou la réécriture PHP n'a pas atteint ownCloud ; et 405`false` 501suggère qu'un serveur, un proxy ou une couche de sécurité a rejeté la méthode DAV. Le fait qu'un navigateur ouvre l'URL avec une page de connexion ne prouve pas que la PROPFINDconnexion fonctionne.

Choisissez la solution en fonction de la configuration du serveur web

Apache : maintenir les règles de réécriture d'ownCloud actives

.htaccessPour une installation Apache standard, vérifiez d'abord la présence du fichier fourni par ownCloud et l'autorisation d'Apache à réécrire ses directives dans le répertoire d'installation. Le programme d'installation et de mise à jour d'ownCloud gère ces règles. Si AllowOverride NoneApache ne parvient pas à les lire, autorisez les substitutions nécessaires pour le répertoire ownCloud ou déplacez les règles correspondantes dans la configuration de l'hôte virtuel. La première option est plus simple à gérer pour un site ownCloud unique ; des règles centralisées pour l'hôte virtuel peuvent être préférables lorsque la politique exige une configuration en dehors des répertoires d'application.

Ne collez pas un bloc de réécriture générique par-dessus une configuration fonctionnelle. Vérifiez que la mod_rewriteréécriture est activée, que le site pointe vers la racine de documents ownCloud correcte et que les requêtes /remote.php/davatteignent le gestionnaire PHP. Après avoir modifié la configuration Apache, exécutez un test de configuration avant de la recharger. Sur ownCloud Classic 11 basé sur Docker, l'image gère sa configuration Apache intégrée ; utilisez les mécanismes de configuration et d'environnement pris en charge par l'image au lieu de modifier les fichiers générés dans un conteneur en cours d'exécution. Consultez la documentation de dépannage d'ownCloud Server 11 .

Nginx : utiliser la configuration du serveur ownCloud

Nginx ne lit pas .htaccessles fichiers Apache. Si Nginx sert directement ownCloud, utilisez la configuration Nginx correspondant à votre version d'ownCloud et à son chemin d'installation, y compris la gestion des emplacements PHP et le routage DAV. Un emplacement PHP minimal personnalisé peut afficher l'interface web tout en générant une erreur 404 ou en redirigeant la requête vers le mauvais gestionnaire. Comparez votre configuration serveur active avec la documentation d'installation d'ownCloud 10.16/remote.php/dav fournie par le fournisseur , puis testez la configuration et redémarrez Nginx. Les directives exactes dépendent de la distribution, du socket PHP-FPM et de l'emplacement d'ownCloud (racine du domaine ou sous-répertoire).

Proxy inverse : préserver le chemin, la méthode et l’URL publique

Si un proxy termine le trafic HTTPS ou achemine un sous-chemin tel que /cloud, vérifiez qu'il transmet bien l'intégralité du chemin DAV au serveur et autorise les méthodes WebDAV telles que PROPFIND, PUT, MOVEet DELETE. Un proxy ou un pare-feu d'application web peut bloquer une méthode même si le point de terminaison PHP est correct. Comparez une requête envoyée via l'URL publique avec une requête envoyée directement au serveur depuis un réseau de confiance ; si l'accès direct renvoie un code 207 mais que la requête publique échoue, examinez le routage du proxy, le filtrage des méthodes, les redirections et les en-têtes d'autorisation.

Configurez les paramètres ownCloud uniquement trusted_proxiesavec des adresses proxy réelles. Si la détection automatique d'URL échoue, les paramètres `<URL_publique>`, ` overwritehost<URL_de_proxy_password> overwriteprotocol` et `<URL_de_proxy_password>` peuvent décrire l'URL publique, mais ils ne résolvent pas le problème d'une méthode DAV bloquée ou d'une route PHP manquante. Une configuration de proxy incorrecte peut permettre l'usurpation d'en-têtes d'adresse client. Suivez les instructionsoverwritewebroot officielles de configuration du proxy inverse pour votre topologie.

Séparer la découverte DAV de l'accès aux fichiers

Les URL permettent aux applications de calendrier et de contacts de découvrir les points de terminaison du service. Elles devraient rediriger vers le point de terminaison DAV d'ownCloud, mais une erreur à ce niveau génère un avertissement distinct de celui lié à une vérification WebDAV de synchronisation de fichiers défaillante. La correction de ces seules redirections de découverte peut ne pas faire disparaître l'avertissement de synchronisation. Pour Apache, les règles fournies par ownCloud peuvent gérer la découverte lorsqu'elles sont activées ; les déploiements Nginx et les déploiements dans des sous-répertoires nécessitent une configuration serveur correspondante. Vérifiez chaque URL et sa cible de redirection indépendamment, en suivant les /.well-known/caldavrecommandations officielles d'ownCloud concernant les avertissements ./.well-known/carddav

Vérifier la réparation

Répétez le PROPFINDtest d'authentification sur l'URL DAV publique et vérifiez qu'il renvoie une réponse 207 Multi-Status. Actualisez ensuite la page d'administration d'ownCloud et effectuez un test de synchronisation rapide avec le client de bureau. Si la requête échoue toujours, comparez le statut HTTP et l'horodatage avec les journaux du serveur web, du proxy, de PHP et d'ownCloud. Dans Docker, la documentation d'ownCloud indique que les journaux d'application peuvent se trouver dans le répertoire de logs monté, tandis que les journaux Apache et PHP sont envoyés vers la sortie du conteneur ; docker compose logs owncloudcela peut aider à localiser ces erreurs.

Les manuels actuels d'ownCloud couvrent les versions Classic 11.0 et 10.16, et le comportement lors de l'installation diffère selon la version ; la documentation de Classic 11 spécifie Docker comme méthode d'installation prise en charge. Utilisez le manuel correspondant à la version déployée et évitez d'appliquer sans discernement d'anciens extraits de code Apache ou Nginx à une configuration de conteneur ou de proxy plus récente.