Restore ownCloud WebDAV Sync by Finding the Broken Route

Fix the “WebDAV interface seems to be broken” warning by confirming that ownCloud’s DAV endpoint is reachable and that your web server forwards WebDAV requests, including the PROPFIND method, to ownCloud’s PHP application. The right change depends on whether Apache, Nginx, or a reverse proxy handles the public URL; test the endpoint before editing configuration so you fix the failing layer.

Find what the warning is actually testing

ownCloud Classic’s admin checker reports this warning when its file synchronization check cannot use the WebDAV interface. It is a web-server or request-path problem in many cases, not proof that files or the database are damaged. The official ownCloud Server 11 warning reference describes it separately from the /.well-known/caldav and /.well-known/carddav service-discovery check.

Use the DAV endpoint matching your public installation path. At the domain root, the endpoint is commonly https://cloud.example.com/remote.php/dav; when installed in a subdirectory, include it, for example https://cloud.example.com/owncloud/remote.php/dav. ownCloud Classic 10.16 also documents the compatibility URL /remote.php/webdav for some desktop and file-manager connections. Do not treat that older client URL and the newer DAV endpoint as interchangeable in every configuration.

Send an authenticated PROPFIND request with depth zero. In this command, replace the sample host/path and username. Curl prompts for the password because only the username is supplied to -u:

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

A successful WebDAV response is typically 207 Multi-Status. Interpret other responses as clues: 301 or 302 points to a redirect or canonical URL issue; 401 means authentication was not accepted; 404 often means the path or PHP rewrite did not reach ownCloud; and 405 or 501 suggests a server, proxy, or security layer rejected the DAV method. A browser opening the URL with a login page does not prove that PROPFIND works.

Choose the fix by web-server layout

Apache: keep ownCloud’s rewrite rules active

For a standard Apache installation, first check that the ownCloud-provided .htaccess file is present and that Apache allows its rewrite directives in the installation directory. The ownCloud installer and upgrade process maintain these rules. If AllowOverride None prevents Apache from reading them, either allow the required overrides for the ownCloud directory or move the equivalent rules into the virtual-host configuration. The first option is easier to maintain for a typical single ownCloud site; central virtual-host rules can be preferable when policy requires configuration outside application directories.

Do not paste a generic rewrite block on top of a working configuration. Confirm that mod_rewrite is enabled, the site points to the correct ownCloud document root, and requests to /remote.php/dav reach the PHP handler. After changing Apache configuration, run its configuration test before reloading it. On Docker-based ownCloud Classic 11, the image manages its embedded Apache configuration; use the image’s supported configuration and environment mechanisms instead of editing generated files inside a running container. See the ownCloud Server 11 troubleshooting documentation.

Nginx: use the ownCloud server configuration

Nginx does not read Apache .htaccess files. If Nginx serves ownCloud directly, use the Nginx configuration matching your ownCloud version and install path, including its PHP location handling and DAV-related routing. A custom minimal PHP location may serve the web interface while leaving /remote.php/dav as a 404 or passing it to the wrong handler. Compare your active server block with the vendor’s ownCloud 10.16 installation documentation, then test the configuration and reload Nginx. The exact directives depend on the distribution, PHP-FPM socket, and whether ownCloud is at the domain root or a subdirectory.

Reverse proxy: preserve path, method, and public URL

If a proxy terminates HTTPS or routes a subpath such as /cloud, check that it forwards the entire DAV path to the backend and allows WebDAV methods such as PROPFIND, PUT, MOVE, and DELETE. A proxy or web application firewall can block a method even when the PHP endpoint is correct. Compare a request sent through the public URL with one sent directly to the backend from a trusted network; if direct access returns 207 but the public request fails, focus on the proxy route, method filtering, redirects, and authorization headers.

Only set ownCloud’s trusted_proxies to actual proxy addresses. If automatic URL detection fails, the overwritehost, overwriteprotocol, and overwritewebroot settings can describe the public URL, but they do not repair a blocked DAV method or missing PHP route. Incorrect proxy trust can permit spoofed client-address headers. Use the official reverse proxy configuration guidance for your topology.

Keep DAV discovery separate from file access

The /.well-known/caldav and /.well-known/carddav URLs help calendar and contacts clients discover service endpoints. They should route to ownCloud’s DAV endpoint, but a failure there is a separate warning from a broken file-synchronization WebDAV check. Fixing only those discovery redirects may not clear the synchronization warning. For Apache, ownCloud’s shipped rules may handle discovery when enabled; Nginx and subdirectory deployments need matching server configuration. Check each URL and its redirect target independently, following the official ownCloud warning guidance.

Verify the repair

Repeat the authenticated PROPFIND test against the public DAV URL and confirm it returns 207 Multi-Status. Then refresh the ownCloud Administration page and run a small sync test with the desktop client. If the request still fails, compare the HTTP status and timestamp with the web-server, proxy, PHP, and ownCloud logs. In Docker, ownCloud’s documentation notes that application logs may be in the mounted log directory while Apache and PHP logs are sent to container output; docker compose logs owncloud can help locate those errors.

ownCloud’s current manuals cover both Classic 11.0 and 10.16, and installation behavior differs by release; Classic 11 documentation specifies Docker as its supported installation method. Use the manual for the deployed version and avoid applying old Apache or Nginx snippets blindly to a newer container or proxy setup.