Résoudre l'erreur « Interface WebDAV défectueuse » dans ownCloud

Si ownCloud se charge dans un navigateur mais que sa page d'administration affiche le message « Interface WebDAV défectueuse », le chargement de fichiers, la synchronisation avec votre ordinateur et l'application Fichiers peuvent également être indisponibles. Ce message d'avertissement est un symptôme, et non un diagnostic : le point de terminaison DAV peut être inaccessible, mal réécrit, bloqué par un proxy ou une règle de sécurité, ou encore inaccessible lorsque ownCloud accède à sa propre URL publique.

Ce guide concerne les installations d'ownCloud Classic Server. ownCloud Infinite Scale possède une architecture et un modèle de déploiement différents ; par conséquent, n'appliquez pas les paramètres Apache de Classic Server à un déploiement Infinite Scale. Les pages officielles mentionnées ci-dessous couvrent ownCloud Server 10.15 et 10.16, ainsi que Classic Server 11.0 ; les vérifications utilisent les routes WebDAV et les exigences Apache documentées, tandis que l'avertissement d'administrateur exact peut varier selon la version.

Note concernant l'illustration : Les images d'interface et de terminal ci-dessous sont des exemples schématiques. Les noms d'hôtes, les lignes d'état et les valeurs affichées sont des exemples fictifs ; ils ne correspondent pas à une installation réelle ni à la réalisation d'un test.

Que signifie l'avertissement WebDAV ?

WebDAV est l'interface HTTP utilisée par ownCloud pour lister et gérer les fichiers pour les clients de synchronisation et les opérations de fichiers associées. La connexion via un navigateur confirme uniquement que l'interface web répond. Elle ne garantit pas qu'une requête WebDAV parvienne à ownCloud avec son chemin d'accès, sa méthode, ses en-têtes d'authentification et sa connexion HTTPS intacts.

Commencez par déterminer si l'erreur est externe ou si elle provient uniquement de l'autodiagnostic d'ownCloud. Une erreur du client de synchronisation et un échec d'authentification WebDAV indiquent un problème avec le routage DAV ou l'authentification. Si les clients fonctionnent mais que l'avertissement de l'administrateur persiste, vérifiez si le serveur peut résoudre et atteindre son nom d'hôte public, y compris son certificat TLS.

Étape 1 : Enregistrez l’URL exacte et testez directement WebDAV.

Utilisez le même nom d'hôte et le même chemin d'installation que ceux saisis par les utilisateurs dans un navigateur. Pour une installation sur un domaine racine, le chemin DAV actuel de Classic Server suit généralement le format suivant :

https://cloud.example.com/remote.php/dav/files/USERNAME/

Si ownCloud est installé dans un répertoire spécifique, indiquez ce chemin avant `/etc/ownCloud` /remote.php, par exemple `/etc/ https://example.com/owncloud/remote.php/dav/files/USERNAME/ownCloud`. Utilisez votre propre nom de compte et votre URL. N'utilisez pas un nom d'hôte fictif et ne supposez pas que chaque installation utilise le même sous-répertoire.

Depuis une machine cliente, envoyez une requête PROPFIND authentifiée. Avec cURL, en ne fournissant que le nom d'utilisateur, le système vous invite à saisir le mot de passe au lieu de l'inclure dans la commande :

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

Une réponse WebDAV authentifiée valide utilise généralement le protocole HTTP 207 Multi-Status. Une erreur 401peut simplement signifier que les informations d'identification n'ont pas été acceptées ; une autre 404erreur indique souvent une route incorrecte ou une réécriture de chemin proxy ; une troisième 403erreur suggère une règle d'accès, un pare-feu applicatif web (WAF) ou une politique de serveur ; et une 301quatrième erreur 302peut indiquer une redirection que le client ou l'autocontrôle ne suit pas comme prévu. Consultez les en-têtes de réponse et les journaux du serveur avant de modifier la configuration. Masquez les noms d'utilisateur, les cookies, les jetons et les adresses IP publiques avant de partager la sortie d'une commande.

Étape 2 : Vérifier si le serveur peut accéder à sa propre URL publique

Certaines vérifications de configuration effectuent une requête depuis le serveur ownCloud vers son adresse publique configurée. Effectuez les vérifications DNS et HTTPS de base depuis ce serveur, et pas seulement depuis votre ordinateur portable :

getent hosts cloud.example.com
curl -I https://cloud.example.com/status.php

Le nom d'hôte doit correspondre à une adresse accessible depuis le serveur, et la requête HTTPS doit aboutir sans erreur de certificat, de chaîne de confiance ou de connexion. Si le DNS redirige le serveur via un pare-feu ne prenant pas en charge la réflexion NAT (également appelée NAT en boucle), un client externe peut fonctionner tandis que l'autocontrôle interne échoue. Un DNS fractionné, une route interne vers le proxy inverse ou une modification du réseau côté fournisseur peuvent être nécessaires ; effectuez la modification la plus ciblée compatible avec votre architecture réseau.

Une entrée de domaine de confiance est une liste blanche d'hôtes pour les requêtes entrantes ownCloud. N'ajoutez que les noms d'hôtes réellement utilisés par les utilisateurs, en suivant la procédure de configuration documentée. N'ajoutez pas d'adresses internes arbitraires. Ce overwrite.cli.urlparamètre contrôle l'URL utilisée par les contextes de ligne de commande/d'arrière-plan dans certaines configurations ; il ne remplace pas la correction des paramètres DNS, de routage ou TLS. Vérifiez le message d'avertissement avant de modifier ce paramètre.

Étape 3 : Vérifier les paramètres de réécriture et de répertoire d’Apache

Pour les installations Apache, le guide de configuration manuelle d'ownCloud recommande de spécifier un chemin d'accès mod_rewriteau AllowOverride Allrépertoire ownCloud lorsqu'on utilise le répertoire fourni .htaccess, ainsi qu'un paramètre Apache lié à DAV qui empêche le module DAV d'Apache de prendre le contrôle de la route de l'application. Comparez votre hôte virtuel et votre bloc de répertoire avec le guide officiel plutôt que de copier-coller un exemple complet sur un site personnalisé.

Sous Debian ou Ubuntu, examinez le module de réécriture chargé et la syntaxe de configuration d'Apache :

sudo apachectl -M | grep rewrite
sudo apachectl -t

Si la réécriture d'URL est absente, activez-la sudo a2enmod rewrite, puis validez à nouveau la configuration et rechargez Apache uniquement après la réussite de la vérification syntaxique. Assurez-vous que le <Directory>chemin correspond bien à la racine web d'ownCloud et que les substitutions ne sont pas désactivées plus haut dans la configuration. Évitez de remplacer manuellement les règles générées par ownCloud .htaccesspar une règle de réécriture générique ; les règles personnalisées peuvent perturber le routage des applications ou être perdues lors des mises à jour.

Étape 4 : Vérifier les proxys inverses, les règles WAF et les en-têtes d’authentification

Si le point de terminaison fonctionne lorsqu'il est appelé directement sur le serveur web, mais échoue via l'URL publique, examinez le proxy inverse ou l'équilibreur de charge. Assurez-vous qu'il conserve le /remote.php/dav/chemin complet, transmet les informations d'hôte et HTTPS attendues et autorise les méthodes WebDAV telles que PROPFIND` git push` OPTIONS, `git PUTpush`, `git push` et MOVE`git push` lorsque cela est nécessaire. Un proxy qui supprime un préfixe d'installation ou qui envoie les requêtes DAV à un autre serveur peut donner l'impression que l'interface web fonctionne correctement alors que les opérations sur les fichiers échouent.

Consultez les journaux du proxy, d'Apache/Nginx et d'ownCloud au moment de l'échec de la requête. Un pare-feu applicatif web (WAF) ou une règle ModSecurity peut bloquer une méthode ou le corps d'une requête. Identifiez l'ID exact de la règle et créez une exception spécifique pour la route ou la requête ownCloud concernée, puis effectuez un nouveau test. Ne désactivez pas le WAF globalement pour faire disparaître un simple avertissement. Si l'authentification DAV échoue uniquement derrière un gestionnaire FastCGI/PHP, vérifiez que l'en-tête d'autorisation est bien transmis à PHP ; la documentation de configuration d'ownCloud décrit ce type de problème.

Étape 5 : Valider le protocole TLS et les redirections

Les clients WebDAV, tout comme les navigateurs, dépendent d'une connexion HTTPS valide. Vérifiez que le certificat est valide pour le nom d'hôte, qu'il inclut les certificats intermédiaires nécessaires et qu'il est approuvé par l'environnement serveur qui exécute l'autovérification d'ownCloud. Un navigateur peut masquer ou approuver séparément un problème de certificat signalé par cURL ou PHP. Ne désactivez pas la vérification des certificats pour résoudre le problème.

Vérifiez la présence de boucles de redirection, de redirections HTTP vers HTTPS inattendues ou d'une redirection de la route DAV vers une page de connexion ou une page d'accueil générique. Une redirection peut être normale pour l'URL de base d'un navigateur, mais la requête DAV doit finalement atteindre le point de terminaison de l'application en conservant sa méthode et son en-tête d'autorisation. Si un proxy termine la connexion TLS, assurez-vous qu'ownCloud reçoit le protocole et l'hôte corrects, conformément à la configuration documentée du proxy.

Vérifiez la correction des deux côtés

Après chaque modification ciblée, répétez les mêmes vérifications plutôt que de modifier plusieurs couches à la fois :

• Du côté client, authentifiez-vous auprès de l'URL DAV documentée et confirmez que la réponse est une réponse WebDAV attendue, généralement 207 Multi-Statuspour PROPFIND.
• Depuis l'hôte ownCloud, vérifiez que le nom d'hôte public est résolu et que le protocole HTTPS atteint l'instance sans erreur de validation TLS.
• Vérifiez à nouveau la vue d'ensemble de l'administration d'ownCloud et examinez les journaux pour détecter de nouvelles erreurs DAV, de proxy ou d'authentification.
• Effectuez un test de chargement, de renommage et de téléchargement d'un petit fichier via l'interface web ou un client de synchronisation compatible.

Si les requêtes client fonctionnent mais que l'avertissement persiste, vérifiez la configuration DNS, le routage, la confiance des certificats et l'URL publique du serveur. Si l'autotest et les clients échouent, examinez en priorité le chemin d'accès au point de terminaison, les règles de réécriture, le routage proxy, les méthodes de requête et le transfert d'authentification. Si le serveur est géré par un hébergeur, transmettez au support l'horodatage, le statut HTTP anonymisé, le chemin demandé et l'entrée de journal correspondante ; ne communiquez ni mots de passe ni informations de configuration sensibles.

Pour les directives spécifiques à votre version, comparez votre déploiement avec le guide d'installation d'ownCloud Server 10.15 Apache , la documentation d'accès WebDAV d'ownCloud Classic et les notes de configuration d'ownCloud concernant l'authentification WebDAV . Suivez le manuel correspondant à votre version installée et à votre type de déploiement.