Webdav stopped working after upgrade from V12 to V13

Seafile Server
1

My WebDAV access is broken with version 13, seadav.conf shows enabled= true, just like in version 12. Browsing to seafile.mydomain.com/seafdav is automatically redirected to /seafdav/, showing that routing by caddy and nginx works, but it shows 502 Bad Gateway? What am I missing? How can I confirm that seafdav is running inside the container?

Thanks again for your help

2

You can try the following to debug the issue:

Recommended Troubleshooting Steps

  1. Verify SeafDAV Process: check if the SeafDAV process is running inside the container by executing:
docker exec -it <container_name> ps aux | grep seafdav

If it is not running, check the logs located at /opt/seafile/logs/seafdav.log inside the container (or the mapped volume) for startup errors.

  1. Check seafdav.conf: Ensure the configuration is correct in /opt/seafile-data/seafile/conf/seafdav.conf:
  • enabled = true
  • port = 8080 (Standard for internal Docker proxying)
  • share_name = /seafdav (Required when behind a reverse proxy)
  1. Check External Proxy Logs: you can check the error logs of external reverse proxy. A “Bad Gateway” log will usually specify which internal IP/port it tried to reach and why it failed (e.g., “Connection refused”).
3

Thanks for your advice!
ps aux returns the following, so I guess it is running?

root 685 0.0 0.0 9468 2276 pts/0 S+ 17:48 0:00 grep --color=auto seafdav

seafdav.conf is correctly configured

seafdav.log shows nothing, but seafdav.access.log shows

192.168.0.100 10.90.0.43 [03/Apr/2026:17:46:03 +0200] “GET /seafdav/ HTTP/1.1” 502 552 “Log In - Schernthaner Cloud “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36” 0.000

and seafdav.error.log shows

2026/04/03 17:46:03 [error] 38#38: *13 connect() failed (111: Connection refused) while connecting to upstream, client: 10.90.0.43, server: , request: “GET /seafdav/ HTTP/1.1”, upstream: “http://127.0.0.1:8080/seafdav/”, host: “cloud.schernthaner.eu”, referrer: “Log In - Schernthaner Cloud

Any ideas why? I even checked the nginx file inside the container, it looks exactly like the file i had before in seafile v12 at /shared/nginx.

Thanks

4

Here is an analysis:

1. Root Cause Identification

The issue is that the SeafDAV process is not running.

In the troubleshooting output:

  • The ps aux | grep seafdav command only returned the grep process itself (grep --color=auto seafdav).
  • If SeafDAV were running, there would be a second line showing the actual Python process for the WebDAV server.
  • The seafdav.error.log confirms this with a (111: Connection refused) error. This indicates that the internal Nginx proxy is trying to forward the request to 127.0.0.1:8080, but no service is listening on that port.

2. Analysis of Logs

  • seafdav.error.log: connect() failed (111: Connection refused) while connecting to upstream. This proves the internal routing is correct, but the destination service (SeafDAV) is down.
  • seafdav.access.log: The 502 status code is being generated by the internal Nginx because it cannot reach the backend SeafDAV service.
  • seafdav.log: this log “shows nothing.” This is unusual if the process failed to start; normally, Python tracebacks or configuration errors would appear here.

3. Recommended Next Steps

To resolve this, the following should be checked:

  • Check for Configuration Syntax Errors: Even if enabled = true is set, a typo in seafdav.conf can prevent the service from starting.
  • Check controller.log: Since SeafDAV is managed by the Seafile controller, any failure to spawn the process is often logged in controller.log rather than seafdav.log.
  • Manual Start Attempt: Try to identify the specific error by looking at the Seafile startup sequence when the container boots. You can check the output of docker logs <container_name> to see if there are errors related to starting the WebDAV server.
1 Like
5

Thanks again for your help!
I was able to find two errors, some tables were missing in ccnet.db, perhaps another quirks from the failed upgrade before. I copied these tables over from my clean installation on my test system.

Second issue was an error related to onlyoffice although EnableOnlyoffice was set to false in seahub_settings.py. I disabled to lines related to onlyoffice and now seafdav works again.

Strange, but I am still happy.
Will now work on onlyoffice integration.