Herstel de ownCloud WebDAV-synchronisatie door de defecte route te vinden.

Los de waarschuwing "WebDAV-interface lijkt defect te zijn" op door te controleren of het DAV-eindpunt van ownCloud bereikbaar is en of uw webserver WebDAV-verzoeken, inclusief de PROPFINDmethode, doorstuurt naar de PHP-applicatie van ownCloud. De juiste wijziging hangt af van of Apache, Nginx of een reverse proxy de openbare URL afhandelt; test het eindpunt voordat u de configuratie aanpast, zodat u de oorzaak van het probleem kunt achterhalen.

Ontdek wat de waarschuwing precies test.

De beheerderscontrole van ownCloud Classic geeft deze waarschuwing weer wanneer de bestandssynchronisatiecontrole de WebDAV-interface niet kan gebruiken. In veel gevallen is dit een probleem met de webserver of het aanvraagpad, en geen bewijs dat bestanden of de database beschadigd zijn. De officiële waarschuwingsreferentie van ownCloud Server 11 beschrijft dit apart van de /.well-known/caldavservice /.well-known/carddav-discoverycontrole.

Gebruik het DAV-eindpunt dat overeenkomt met uw openbare installatiepad. In de domeinroot is het eindpunt doorgaans https://cloud.example.com/remote.php/dav; als het in een submap is geïnstalleerd, voeg het dan toe, bijvoorbeeld https://cloud.example.com/owncloud/remote.php/dav. ownCloud Classic 10.16 documenteert ook de compatibiliteits-URL /remote.php/webdavvoor sommige desktop- en bestandsbeheerverbindingen. Beschouw die oudere client-URL en het nieuwere DAV-eindpunt niet als onderling verwisselbaar in elke configuratie.

Verzend een geauthenticeerd PROPFINDverzoek met diepte nul. Vervang in dit commando de voorbeeldhost/pad en gebruikersnaam. Curl vraagt ​​om het wachtwoord omdat alleen de gebruikersnaam wordt meegegeven -u.

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

Een succesvolle WebDAV-respons is doorgaans 207 Multi-Status. Interpreteer andere responsen als aanwijzingen: 301of 302wijst op een probleem met een redirect of canonieke URL; 401betekent dat de authenticatie niet is geaccepteerd; 404betekent vaak dat het pad of de PHP-rewrite ownCloud niet heeft bereikt; en 405of 501suggereert dat een server, proxy of beveiligingslaag de DAV-methode heeft afgewezen. Het feit dat een browser de URL opent met een inlogpagina bewijst niet dat PROPFINDwerkt.

Kies de oplossing op basis van de lay-out van de webserver.

Apache: houd de herschrijfregels van ownCloud actief

Controleer bij een standaard Apache-installatie eerst of het door ownCloud geleverde .htaccessbestand aanwezig is en of Apache de herschrijfrichtlijnen in de installatiemap toestaat. Het ownCloud-installatie- en upgradeproces beheert deze regels. Als AllowOverride NoneApache deze niet kan lezen, moet u de benodigde overschrijvingen voor de ownCloud-directory toestaan ​​of de overeenkomstige regels in de virtuele-hostconfiguratie plaatsen. De eerste optie is gemakkelijker te onderhouden voor een typische ownCloud-site; centrale virtuele-hostregels kunnen de voorkeur hebben wanneer het beleid configuratie buiten de applicatiedirectory's vereist.

Plak geen algemeen rewrite-blok bovenop een werkende configuratie. Controleer of de rewrite- mod_rewritefunctie is ingeschakeld, of de site naar de juiste documentroot van ownCloud verwijst en of /remote.php/davde PHP-handler wordt bereikt. Voer na het wijzigen van de Apache-configuratie de configuratietest uit voordat u de configuratie opnieuw laadt. Op de Docker-gebaseerde ownCloud Classic 11 beheert de image de ingebouwde Apache-configuratie; gebruik de ondersteunde configuratie- en omgevingsmechanismen van de image in plaats van gegenereerde bestanden in een draaiende container te bewerken. Zie de documentatie voor probleemoplossing van ownCloud Server 11 .

Nginx: gebruik de serverconfiguratie van ownCloud

Nginx leest geen Apache- .htaccessbestanden. Als Nginx ownCloud rechtstreeks serveert, gebruik dan de Nginx-configuratie die overeenkomt met uw ownCloud-versie en installatiepad, inclusief de afhandeling van de PHP-locatie en DAV-gerelateerde routing. Een aangepaste, minimale PHP-locatie kan de webinterface wel serveren, maar /remote.php/daveen 404-foutmelding geven of de aanvraag doorsturen naar de verkeerde handler. Vergelijk uw actieve serverblok met de installatiedocumentatie van ownCloud 10.16 van de leverancier , test vervolgens de configuratie en herlaad Nginx. De exacte instructies zijn afhankelijk van de distributie, de PHP-FPM-socket en of ownCloud zich in de domeinroot of een subdirectory bevindt.

Reverse proxy: behoudt pad, methode en openbare URL

Als een proxy HTTPS beëindigt of een subpad routeert, zoals /cloud, controleer dan of het volledige DAV-pad naar de backend wordt doorgestuurd en of WebDAV-methoden zoals PROPFIND, PUT, MOVEen zijn toegestaan DELETE. Een proxy of webapplicatie-firewall kan een methode blokkeren, zelfs als het PHP-eindpunt correct is. Vergelijk een verzoek dat via de openbare URL is verzonden met een verzoek dat rechtstreeks naar de backend is verzonden vanuit een vertrouwd netwerk; als directe toegang een 207-statuscode retourneert, maar het openbare verzoek mislukt, richt u zich dan op de proxyroute, methodefiltering, omleidingen en autorisatieheaders.

Stel de eigen proxy-instellingen van ownCloud alleen trusted_proxiesin op daadwerkelijke proxy-adressen. Als automatische URL-detectie mislukt, kunnen de instellingen overwritehost, overwriteprotocol, en overwritewebrootde openbare URL beschrijven, maar ze herstellen geen geblokkeerde DAV-methode of ontbrekende PHP-route. Een onjuiste proxy-vertrouwensstatus kan leiden tot vervalste clientadresheaders. Raadpleeg de officiële configuratiehandleiding voor reverse proxy's voor uw topologie.

Houd DAV-detectie gescheiden van bestandstoegang.

De /.well-known/caldavURL /.well-known/carddav's helpen agenda- en contactclients bij het vinden van service-eindpunten. Ze zouden moeten doorverwijzen naar het DAV-eindpunt van ownCloud, maar een fout daar leidt tot een aparte waarschuwing, los van een mislukte WebDAV-controle voor bestandssynchronisatie. Het oplossen van alleen deze ontdekkingsomleidingen lost de synchronisatiewaarschuwing mogelijk niet op. Voor Apache kunnen de meegeleverde regels van ownCloud de ontdekking afhandelen wanneer deze zijn ingeschakeld; Nginx en implementaties in submappen vereisen een overeenkomstige serverconfiguratie. Controleer elke URL en de bijbehorende omleidingsbestemming afzonderlijk, volgens de officiële waarschuwingsrichtlijnen van ownCloud .

Controleer de reparatie.

Herhaal de authenticatietest PROPFINDmet de openbare DAV-URL en controleer of deze een resultaat retourneert 207 Multi-Status. Vernieuw vervolgens de ownCloud-beheerpagina en voer een korte synchronisatietest uit met de desktopclient. Als de aanvraag nog steeds mislukt, vergelijk dan de HTTP-status en het tijdstempel met de logbestanden van de webserver, proxy, PHP en ownCloud. In Docker vermeldt de documentatie van ownCloud dat applicatielogbestanden zich mogelijk in de gemounte logmap bevinden, terwijl Apache- en PHP-logbestanden naar de containeruitvoer worden verzonden; docker compose logs ownclouddit kan helpen bij het lokaliseren van deze fouten.

De huidige handleidingen van ownCloud behandelen zowel Classic 11.0 als 10.16, en het installatiegedrag verschilt per release; de ​​documentatie van Classic 11 vermeldt Docker als de ondersteunde installatiemethode. Raadpleeg de handleiding voor de geïmplementeerde versie en vermijd het blindelings toepassen van oude Apache- of Nginx-codefragmenten op een nieuwere container- of proxy-configuratie.