ownCloud WebDAV-Synchronisierung wiederherstellen, indem die defekte Route gefunden wird

Beheben Sie die Warnung „WebDAV-Schnittstelle scheint defekt zu sein“, indem Sie sicherstellen, dass der DAV-Endpunkt von ownCloud erreichbar ist und Ihr Webserver WebDAV-Anfragen inklusive der PROPFINDMethode an die PHP-Anwendung von ownCloud weiterleitet. Die erforderliche Änderung hängt davon ab, ob Apache, Nginx oder ein Reverse-Proxy die öffentliche URL verarbeitet. Testen Sie den Endpunkt, bevor Sie die Konfiguration bearbeiten, um die fehlerhafte Ebene zu beheben.

Finden Sie heraus, was die Warnung tatsächlich testet.

Der Administrator-Checker von ownCloud Classic meldet diese Warnung, wenn die Dateisynchronisierung nicht über die WebDAV-Schnittstelle funktioniert. In vielen Fällen liegt das Problem am Webserver oder am Anfragepfad und beweist nicht, dass Dateien oder die Datenbank beschädigt sind. Die offizielle Dokumentation zu den Warnungen von ownCloud Server 11 beschreibt dies separat von der /.well-known/caldavDiensterkennungsprüfung /.well-known/carddav.

Verwenden Sie den DAV-Endpunkt, der Ihrem öffentlichen Installationspfad entspricht. Im Stammverzeichnis der Domäne lautet der Endpunkt üblicherweise `/etc/` . https://cloud.example.com/remote.php/davBei einer Installation in einem Unterverzeichnis geben Sie ihn an, z. B. `/etc/` https://cloud.example.com/owncloud/remote.php/dav. ownCloud Classic 10.16 dokumentiert außerdem die Kompatibilitäts-URL /remote.php/webdavfür einige Desktop- und Dateimanager-Verbindungen. Behandeln Sie die ältere Client-URL und den neueren DAV-Endpunkt nicht in jeder Konfiguration als austauschbar.

Senden Sie eine authentifizierte PROPFINDAnfrage mit Tiefe Null. Ersetzen Sie in diesem Befehl den Beispielhost/Pfad und den Benutzernamen. Curl fordert das Passwort an, da nur der Benutzername angegeben wurde -u.

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

Eine erfolgreiche WebDAV-Antwort ist typischerweise 207 Multi-Status. Andere Antworten deuten auf Folgendes hin: 301oder 302weist auf eine Weiterleitung oder ein Problem mit der kanonischen URL hin; 401bedeutet, dass die Authentifizierung nicht akzeptiert wurde; 404bedeutet oft, dass der Pfad oder die PHP-Umschreibung ownCloud nicht erreicht hat; und 405oder 501deutet darauf hin, dass ein Server, Proxy oder eine Sicherheitsebene die DAV-Methode abgelehnt hat. Dass ein Browser die URL mit einer Anmeldeseite öffnet, beweist nicht, dass die PROPFINDVerbindung funktioniert.

Wählen Sie die Lösung anhand des Webserver-Layouts.

Apache: Die Rewrite-Regeln von ownCloud aktiv halten

Bei einer Standardinstallation von Apache prüfen Sie zunächst, ob die von ownCloud bereitgestellte .htaccessDatei vorhanden ist und ob Apache die Rewrite-Regeln im Installationsverzeichnis zulässt. Der ownCloud-Installer und der Upgrade-Prozess verwalten diese Regeln. Falls AllowOverride NoneApache diese nicht lesen kann, erlauben Sie entweder die erforderlichen Überschreibungen für das ownCloud-Verzeichnis oder verschieben Sie die entsprechenden Regeln in die Virtual-Host-Konfiguration. Die erste Option ist für eine typische einzelne ownCloud-Website einfacher zu handhaben; zentrale Virtual-Host-Regeln sind jedoch vorzuziehen, wenn die Richtlinien eine Konfiguration außerhalb der Anwendungsverzeichnisse erfordern.

Fügen Sie keinen generischen Rewrite-Block in eine funktionierende Konfiguration ein. Stellen Sie sicher, dass die Rewrite- mod_rewriteRegeln aktiviert sind, die Website auf das korrekte ownCloud-Dokumentenverzeichnis verweist und Anfragen /remote.php/davden PHP-Handler erreichen. Führen Sie nach Änderungen an der Apache-Konfiguration einen Konfigurationstest durch, bevor Sie die Website neu laden. Bei Docker-basiertem ownCloud Classic 11 verwaltet das Image seine eingebettete Apache-Konfiguration. Verwenden Sie die vom Image unterstützten Konfigurations- und Umgebungsmechanismen, anstatt generierte Dateien in einem laufenden Container zu bearbeiten. Weitere Informationen finden Sie in der Dokumentation zur Fehlerbehebung für ownCloud Server 11 .

Nginx: Verwenden Sie die ownCloud-Serverkonfiguration

Nginx liest keine Apache- .htaccessDateien. Wenn ownCloud direkt über Nginx bereitgestellt wird, verwenden Sie die Nginx-Konfiguration, die Ihrer ownCloud-Version und Ihrem Installationspfad entspricht, einschließlich der PHP-Speicherortverwaltung und des DAV-bezogenen Routings. Ein benutzerdefinierter minimaler PHP-Speicherort kann zwar die Weboberfläche bereitstellen, aber /remote.php/daveinen 404-Fehler ausgeben oder die Anfrage an den falschen Handler weiterleiten. Vergleichen Sie Ihren aktiven Serverblock mit der Installationsdokumentation des Herstellers für ownCloud 10.16 , testen Sie anschließend die Konfiguration und laden Sie Nginx neu. Die genauen Anweisungen hängen von der Distribution, dem PHP-FPM-Socket und davon ab, ob sich ownCloud im Stammverzeichnis oder in einem Unterverzeichnis der Domain befindet.

Reverse-Proxy: Pfad, Methode und öffentliche URL beibehalten

Wenn ein Proxy HTTPS beendet oder einen Teilpfad wie z. B. `/example.com` weiterleitet /cloud, prüfen Sie, ob er den gesamten DAV-Pfad an das Backend weiterleitet und WebDAV-Methoden wie `get` PROPFIND, PUT`get`, MOVE`get` und ` get` zulässt DELETE. Ein Proxy oder eine Web Application Firewall kann eine Methode blockieren, selbst wenn der PHP-Endpunkt korrekt ist. Vergleichen Sie eine Anfrage, die über die öffentliche URL gesendet wird, mit einer Anfrage, die direkt von einem vertrauenswürdigen Netzwerk an das Backend gesendet wird. Wenn der direkte Zugriff den Statuscode 207 zurückgibt, die öffentliche Anfrage aber fehlschlägt, überprüfen Sie die Proxy-Route, die Methodenfilterung, Weiterleitungen und Autorisierungsheader.

Verwenden Sie für ownCloud ausschließlich trusted_proxiesdie tatsächlichen Proxy-Adressen. Schlägt die automatische URL-Erkennung fehl, können die Einstellungen `<proxy-name>`, overwritehost`<proxy-name> overwriteprotocol` und overwritewebroot`<proxy-name>` zwar die öffentliche URL beschreiben, beheben aber weder eine blockierte DAV-Methode noch eine fehlende PHP-Route. Eine fehlerhafte Proxy-Vertrauensstellung kann gefälschte Client-Adress-Header zulassen. Beachten Sie die offiziellen Richtlinien zur Reverse-Proxy-Konfiguration für Ihre Netzwerktopologie.

DAV-Erkennung und Dateizugriff sollten getrennt gehalten werden.

Die URLs `<name>` /.well-known/caldavund /.well-known/carddav`<name>` helfen Kalender- und Kontaktclients, die Service-Endpunkte zu finden. Sie sollten zum DAV-Endpunkt von ownCloud weiterleiten. Ein Fehler dort führt jedoch zu einer separaten Warnung, unabhängig von der Warnung bei einer fehlerhaften WebDAV-Dateisynchronisierung. Die alleinige Behebung dieser Weiterleitungen bei der Suche beseitigt die Synchronisierungswarnung möglicherweise nicht. Bei Apache können die mitgelieferten Regeln von ownCloud die Suche übernehmen, sofern diese aktiviert sind. Nginx- und Unterverzeichnis-Bereitstellungen erfordern eine entsprechende Serverkonfiguration. Überprüfen Sie jede URL und ihr Weiterleitungsziel separat gemäß den offiziellen ownCloud-Warnhinweisen .

Überprüfen Sie die Reparatur

Wiederholen Sie den Authentifizierungstest PROPFINDmit der öffentlichen DAV-URL und prüfen Sie, ob eine Antwort zurückgegeben wird 207 Multi-Status. Aktualisieren Sie anschließend die ownCloud-Administrationsseite und führen Sie einen kurzen Synchronisierungstest mit dem Desktop-Client durch. Falls die Anfrage weiterhin fehlschlägt, vergleichen Sie den HTTP-Status und den Zeitstempel mit den Protokollen des Webservers, des Proxys, von PHP und ownCloud. In Docker weist die ownCloud-Dokumentation darauf hin, dass sich Anwendungsprotokolle im eingebundenen Protokollverzeichnis befinden können, während Apache- und PHP-Protokolle in die Containerausgabe geschrieben werden. docker compose logs owncloudDies kann bei der Fehlersuche helfen.

Die aktuellen Handbücher von ownCloud decken sowohl Classic 11.0 als auch 10.16 ab, wobei sich das Installationsverhalten je nach Version unterscheidet. Die Dokumentation zu Classic 11 gibt Docker als unterstützte Installationsmethode an. Verwenden Sie das Handbuch für die eingesetzte Version und vermeiden Sie es, alte Apache- oder Nginx-Codeabschnitte unreflektiert auf neuere Container- oder Proxy-Konfigurationen anzuwenden.