Beheben des Fehlers „WebDAV-Schnittstelle ist defekt“ in ownCloud

Wenn ownCloud im Browser geladen wird, die Admin-Seite aber die Meldung „WebDAV-Schnittstelle defekt“ anzeigt, können Datei-Uploads, Desktop-Synchronisierung und die Dateien-App ebenfalls fehlschlagen. Die Warnung ist ein Symptom, keine Diagnose: Der DAV-Endpunkt ist möglicherweise nicht erreichbar, fehlerhaft umgeschrieben, durch einen Proxy oder eine Sicherheitsregel blockiert oder nicht zugänglich, wenn ownCloud seine eigene öffentliche URL aufruft.

Diese Anleitung gilt für ownCloud Classic Server-Installationen. ownCloud Infinite Scale verwendet eine andere Architektur und ein anderes Bereitstellungsmodell. Wenden Sie daher die Apache-Einstellungen von Classic Server nicht auf eine Infinite Scale-Bereitstellung an. Die unten verlinkten offiziellen Seiten behandeln ownCloud Server 10.15 und 10.16 sowie Classic Server 11.0. Die Prüfungen verwenden dokumentierte WebDAV-Routen und Apache-Anforderungen. Die genaue Administratorwarnung kann je nach Version variieren.

Anmerkung zur Abbildung: Die untenstehenden Abbildungen der Benutzeroberfläche und des Terminals sind schematische Beispiele. Hostnamen, Statuszeilen und angezeigte Werte sind Platzhalter und stellen weder eine erfasste Installation noch die Durchführung eines Tests dar.

Was bedeutet die WebDAV-Warnung?

WebDAV ist die HTTP-basierte Schnittstelle, die ownCloud zum Auflisten und Verwalten von Dateien für Synchronisierungsclients und zugehörige Dateivorgänge verwendet. Eine Browseranmeldung bestätigt lediglich, dass die Weboberfläche antwortet. Sie bestätigt nicht, dass eine WebDAV-Anfrage ownCloud mit intaktem Pfad, Methode, Authentifizierungsheadern und HTTPS-Verbindung erreicht.

Ermitteln Sie zunächst, ob der Fehler extern bedingt ist oder nur im Selbsttest von ownCloud auftritt. Ein Synchronisierungsclientfehler und eine fehlgeschlagene authentifizierte WebDAV-Anfrage deuten auf ein Problem mit der DAV-Route oder der Authentifizierung hin. Wenn die Clients funktionieren, die Administratorwarnung aber weiterhin angezeigt wird, testen Sie, ob der Server selbst den öffentlichen Hostnamen einschließlich des zugehörigen TLS-Zertifikats auflösen und erreichen kann.

Schritt 1: Notieren Sie sich die genaue URL und testen Sie WebDAV direkt.

Verwenden Sie denselben Hostnamen und Installationspfad, den Benutzer im Browser eingeben. Bei einer Installation in einer Stammdomäne sieht der aktuelle Classic Server DAV-Pfad üblicherweise wie folgt aus:

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

Wenn ownCloud unter einem bestimmten Pfad installiert ist, geben Sie diesen Pfad vor dem Pfad an /remote.php, z. B. https://example.com/owncloud/remote.php/dav/files/USERNAME/. Verwenden Sie Ihren eigenen Kontonamen und Ihre eigene URL. Testen Sie keinen erfundenen Hostnamen und gehen Sie nicht davon aus, dass jede Installation dasselbe Unterverzeichnis verwendet.

Senden Sie von einem Client-Rechner aus eine authentifizierte PROPFIND-Anfrage. Mit cURL wird durch die Übergabe nur des Benutzernamens die Eingabe des Passworts erzwungen, anstatt es im Befehl anzugeben.

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

Eine gültige, authentifizierte WebDAV-Antwort verwendet üblicherweise HTTP 207 Multi-Status. Ein „A“ 401kann bedeuten, dass die Anmeldeinformationen nicht akzeptiert wurden; ein „B“ 404deutet oft auf die falsche Route oder eine Umleitung des Proxy-Pfads hin; ein „B“ 403deutet auf eine Zugriffsregel, eine Web Application Firewall (WAF) oder eine Serverrichtlinie hin; und ein „B“ 301oder „C“ 302kann auf eine Umleitung hinweisen, der der Client oder der Selbsttest nicht wie erwartet folgt. Lesen Sie die Antwortheader und Serverprotokolle, bevor Sie die Konfiguration ändern. Schwärzen Sie Benutzernamen, Cookies, Tokens und öffentliche IP-Adressen, bevor Sie die Befehlsausgabe weitergeben.

Schritt 2: Überprüfen Sie, ob der Server seine eigene öffentliche URL erreichen kann.

Einige Einrichtungsprüfungen senden eine Anfrage vom ownCloud-Server an seine konfigurierte öffentliche Adresse. Führen Sie grundlegende DNS- und HTTPS-Prüfungen von diesem Server aus durch, nicht nur von Ihrem Laptop:

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

Der Hostname sollte zu einer vom Server erreichbaren Adresse aufgelöst werden, und die HTTPS-Anfrage sollte ohne Zertifikats-, Vertrauensketten- oder Verbindungsfehler abgeschlossen werden. Wenn der DNS-Server den Server über eine Firewall leitet, die keine NAT-Reflexion (auch Hairpin-NAT genannt) unterstützt, kann ein externer Client funktionieren, während der interne Selbsttest fehlschlägt. Split-DNS, eine interne Route zum Reverse-Proxy oder eine Anpassung des Provider-Netzwerks können Abhilfe schaffen; wählen Sie die kleinstmögliche Änderung, die zu Ihrem Netzwerkdesign passt.

Ein Eintrag in der Liste vertrauenswürdiger Domänen ist eine Zulassungsliste für eingehende ownCloud-Anfragen. Fügen Sie nur Hostnamen hinzu, die Benutzer tatsächlich verwenden, und befolgen Sie dabei die dokumentierte Konfigurationsanleitung. Fügen Sie keine beliebigen internen Adressen wahllos hinzu. Diese overwrite.cli.urlEinstellung steuert die URL, die in bestimmten Konfigurationen von Befehlszeilen-/Hintergrundkontexten verwendet wird; sie ersetzt jedoch nicht die Behebung von DNS-, Routing- oder TLS-Problemen. Prüfen Sie die Bedeutung der Warnung, bevor Sie eine der Einstellungen ändern.

Schritt 3: Apache-Rewrite- und Verzeichniseinstellungen überprüfen

Für Apache-Installationen empfiehlt die manuelle Konfigurationsanleitung von ownCloud die Konfiguration des ownCloud-Verzeichnisses mod_rewrite( bei Verwendung des mitgelieferten Verzeichnisses) sowie eine DAV-bezogene Apache-Einstellung, die verhindert, dass das DAV-Modul von Apache die Anwendungsroute übernimmt. Vergleichen Sie Ihren virtuellen Host und den Verzeichnisblock mit der offiziellen Anleitung, anstatt ein komplettes Beispiel in eine angepasste Website einzufügen.AllowOverride All.htaccess

Unter Debian oder Ubuntu sollten Sie das geladene Rewrite-Modul und die Apache-Konfigurationssyntax überprüfen:

sudo apachectl -M | grep rewrite
sudo apachectl -t

Falls keine Rewrite-Regeln vorhanden sind, aktivieren Sie diese mit `<option>` sudo a2enmod rewrite, überprüfen Sie anschließend die Konfiguration erneut und laden Sie Apache erst neu, nachdem die Syntaxprüfung erfolgreich war. Stellen Sie sicher, dass der <Directory>Pfad mit dem tatsächlichen ownCloud-Webverzeichnis übereinstimmt und dass Überschreibungen nicht weiter oben in der Konfiguration deaktiviert wurden. Vermeiden Sie es, die von ownCloud generierten Regeln manuell .htaccessdurch generische Rewrite-Regeln zu ersetzen; benutzerdefinierte Regeln können Anwendungsrouten beschädigen oder bei Aktualisierungen verloren gehen.

Schritt 4: Reverse-Proxys, WAF-Regeln und Authentifizierungsheader prüfen

Wenn der Endpunkt bei direktem Aufruf über den Webserver funktioniert, aber über die öffentliche URL nicht, überprüfen Sie den Reverse-Proxy oder Load Balancer. Stellen Sie sicher, dass er den vollständigen /remote.php/dav/Pfad beibehält, die erwarteten Host- und HTTPS-Informationen weiterleitet und WebDAV-Methoden wie z. B. PROPFIND`get`, OPTIONS`get` PUT, `get` und MOVE`get` zulässt. Ein Proxy, der ein Installationspräfix entfernt oder DAV-Anfragen an ein anderes Backend sendet, kann die Web-Oberfläche fälschlicherweise als funktionsfähig erscheinen lassen, obwohl Dateivorgänge fehlschlagen.

Überprüfen Sie die Proxy-, Apache/Nginx- und ownCloud-Logs zum Zeitpunkt einer fehlgeschlagenen Anfrage. Eine Web Application Firewall (WAF) oder eine ModSecurity-Regel kann eine Methode oder den Anfragetext ablehnen. Ermitteln Sie die genaue Regel-ID und erstellen Sie eine spezifische Ausnahme für die betroffene ownCloud-Route oder -Anfrage. Testen Sie anschließend erneut. Deaktivieren Sie die WAF nicht global, nur um eine Warnung zu beheben. Falls die DAV-Authentifizierung nur hinter einem FastCGI/PHP-Handler fehlschlägt, überprüfen Sie, ob der Autorisierungsheader an PHP übergeben wird. Die ownCloud-Konfigurationshinweise dokumentieren diese Art von Problem.

Schritt 5: TLS und Weiterleitungen validieren

WebDAV-Clients benötigen, genau wie Browser, eine gültige HTTPS-Verbindung. Prüfen Sie, ob das Zertifikat für den Hostnamen gültig ist, die erforderlichen Zwischenzertifikate enthält und von der Serverumgebung, die den Selbsttest von ownCloud ausführt, als vertrauenswürdig eingestuft wird. Ein Browser kann ein von cURL oder PHP gemeldetes Zertifikatsproblem ausblenden oder separat als vertrauenswürdig einstufen. Deaktivieren Sie die Zertifikatsprüfung nicht als Lösung.

Prüfen Sie auf Weiterleitungsschleifen, unerwartete HTTP-zu-HTTPS-Weiterleitungen oder Weiterleitungen von der DAV-Route auf eine Anmeldeseite oder eine allgemeine Startseite. Eine Weiterleitung kann für die Basis-URL eines Browsers normal sein, die DAV-Anfrage sollte jedoch letztendlich den Anwendungsendpunkt mit erhaltener Methode und erhaltenem Authorization-Header erreichen. Falls ein Proxy die TLS-Verbindung beendet, stellen Sie sicher, dass ownCloud das korrekte weitergeleitete Protokoll und den korrekten Host gemäß der dokumentierten Proxy-Konfiguration empfängt.

Überprüfen Sie die Reparatur von beiden Seiten

Nach jeder gezielten Änderung sollten die gleichen Prüfungen wiederholt werden, anstatt mehrere Ebenen gleichzeitig zu ändern:

• Vom Client aus authentifizieren Sie sich an der dokumentierten DAV-URL und bestätigen Sie, dass die Antwort eine erwartete WebDAV-Antwort ist, typischerweise 207 Multi-Statusfür PROPFIND.
• Prüfen Sie vom ownCloud-Host aus, ob der öffentliche Hostname aufgelöst werden kann und ob HTTPS die Instanz ohne TLS-Validierungsfehler erreicht.
• Überprüfen Sie erneut die ownCloud-Admin-Übersicht und inspizieren Sie die Protokolle auf neue DAV-, Proxy- oder Authentifizierungsfehler.
• Testen Sie das Hochladen, Umbenennen und Herunterladen einer kleinen Datei über die Weboberfläche oder einen unterstützten Synchronisierungsclient.

Wenn Clientanfragen funktionieren, die Warnung aber weiterhin angezeigt wird, überprüfen Sie die DNS-Einstellungen, das Routing, die Zertifikatsvertrauenswürdigkeit und die konfigurierte öffentliche URL des Servers. Falls sowohl der Selbsttest als auch die Clientanfragen fehlschlagen, prüfen Sie zunächst den Endpunktpfad, die Rewrite-Regeln, das Proxy-Routing, die Anfragemethoden und die Authentifizierungsweiterleitung. Wird der Server von einem Hosting-Anbieter verwaltet, senden Sie dem Support den Zeitstempel, den bereinigten HTTP-Statuscode, den angeforderten Pfad und den entsprechenden Logeintrag. Senden Sie keine Passwörter oder Konfigurationsdateien mit geheimen Informationen.

Versionsspezifische Anweisungen finden Sie in der Installationsanleitung für ownCloud Server 10.15 Apache , der Dokumentation zum WebDAV-Zugriff in ownCloud Classic und den ownCloud-Konfigurationshinweisen zur WebDAV-Authentifizierung . Beachten Sie die Anweisungen im Handbuch für Ihre installierte Version und Ihren Bereitstellungstyp.