Seafdav - MOVE command causing 502

I just enabled seafdav and I’m experiencing weird issue. Everything works fine, except for the MOVE command which returns 502. This is from seafdav.log:

2020-04-17 06:08:19.931 - <140367234227392> wsgidav.wsgidav_app         INFO    : - - [2020-04-17 06:08:19] "PUT /" length=156, elap=0.030sec -> 204 No Content
2020-04-17 06:08:19.968 - <140367234227392> wsgidav.wsgidav_app         INFO    : - - [2020-04-17 06:08:19] "PROPFIND /" length=277, depth=0, elap=0.020sec -> 207 Multi-Status
2020-04-17 06:08:20.008 - <140367234227392> wsgidav.wsgidav_app         INFO    : - - [2020-04-17 06:08:20] "MOVE /" dest="", depth=0, overwrite=T, elap=0.023sec -> 502 Bad Gateway

Any idea what could be causing this? Where could I find more logs about this?


I have the same problem. As your log mentions “tactipart”: Do you use the Android App FolderSync? I used this app in the last years and in the last month it stopped working. I upgraded Seafile Server to 7.1 but it could also be caused by a FolderSync update.

Yes, I’m using FolderSync. I managed to get it working by disabling “Use temp-file scheme” toggle, but I still don’t like the fact that Seafile is throwing 502 for me.

As described here I had the same issue with KeePass for Windows and I solved it in the same way, disabling the temp file writing and using direct write, that probably it’s a bit more error-prone.

So I guess the problem is with a “move” command issued immediately after PUT, my logs are really similar to yours.

I use Foldersync, the developer clearly stated he was not maintaining it anymore, so it’s unlikely it’s caused by an upgrade on Foldersync side.

Last night, my Seafile got upgraded to 7.1.3, and Foldersync started failing (reported here Seafdav 502 Bad Gateway after upgrade to 7.1.3 yesterday (Docker))

It is definitely related to 7.1.x webdav breaking.

I’m running to the same issue, MOVE commands cause a 502 bad gateway error. Seems like a bug.

That’s a different issue (caused by not setting up the reverse proxy properly, as you mentioned in the linked post).

Files are indexed in the background. That’s why put request finishes before the file is actually present in the library itself and on immediate move request it is missing.

Do not use temp files.

Unfortunately this is not limited to temp files. Doing any renames on a file or folder via DAV results in this error.

Hey @saman so yeah, the reverse proxy fix helped. Joplin started working again, but Foldersync on Android was indeed still failing, so something is definitely still off.

My Foldersync sends the complete file with .tacitpart extension just fine, but it fails when it’s trying to remove the extension (the MOVE).

Disabling “Use temp-file scheme” also works for me, but I do not consider this a fix.

A simple rename in Thunar file explorer fails:

Log: x.x.x.x [28/Apr/2020:23:48:28 +0200] "MOVE /seafdav/Android/test.txt HTTP/1.1" 502 435 "-" "gvfs/1.42.2" 0.080

As @Gabri said, there’s definitely an issue with the MOVE operation over webdav.

Yes, MOVE operations are broken. Other operations (e.g. PUT, GET, PROPFIND, HEAD, …) seem to work.

Indeed, that is not a fix. It’s worth noting, again, that this has nothing to do with temporary files or what WebDAV client you are using. The only reason it shows up when using temporary files is because temporary files make heavy use of MOVE commands.

Upgraded to 7.1.4 hoping it could have been fixed (even if not reported in changelog) but without luck :disappointed:

@Gabri @saman My suggestion: SeafDAV is based basically on WebDAV. You could open an issue to check if this problem is already known upstream.

In order to debug this issue, you must run the command from CLI:

Stop seafile && seahub services and then run:

su seafile -c "PYTHONPATH=$PYTHONPATH:/media/sda/seafile/seafile-server-latest/seahub/thirdpart/:/media/sda/seafile/seafile-server-latest/seafile/lib/python3.6/site-packages/ CCNET_CONF_DIR=/media/sda/seafile/ccnet SEAFILE_CONF_DIR=/media/sda/seafile/seafile-data SEAFILE_CENTRAL_CONF_DIR=/media/sda/seafile/conf SEAFDAV_CONF=/media/sda/seafile/conf/seafdav.conf SEAFILE_RPC_PIPE_PATH=/media/sda/seafile/seafile-server-7.1.3/runtime /usr/bin/python3 -m wsgidav.server.server_cli --server gunicorn --root / --log-file /media/sda/seafile/logs/seafdav.log -v --pid /media/sda/seafile/pids/ --port 8080 --host --verbose"

and substitute your system paths accordingly.

The trick is done by the flag --verbose. Check then the seafdav.log

Tried with your command but I get this error:

  File "/usr/lib/python3.6/", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.6/", line 85, in _run_code
    exec(code, run_globals)
  File "/opt/seafile/seafile-server-latest/seahub/thirdpart/wsgidav/server/", line 44, in <module>
    from wsgidav.dc.domain_controller import SeafileDomainController
  File "/opt/seafile/seafile-server-latest/seahub/thirdpart/wsgidav/dc/", line 4, in <module>
    from pysearpc import SearpcError
ModuleNotFoundError: No module named 'pysearpc'

Anyway here @Jonathan says that in 7.1 they had done

major upgrade to the webdav functionality

So I guess is something more on Seafile side than wsgidav

What I’m guessing:

The major upgrade means that until R7.1. SeafDAV was based on wsgidav=“1.2.0.pre” and after R7.1. SeafDAV is based on wsgidav=3.0.1. The major changes didn’t happen on Seafie but on the original wsgidav, in which SeafDAV is based on.

/home/seafile # diff seafile-server-7.0.5/seahub/thirdpart/wsgidav/ seafile-server-7.1.4/seahub/thirdpart/wsgidav/
< __version__ = "1.2.0.pre"

> __version__ = "3.0.1"

And here the whole ChangeLog from wsgidav, where you can observe the release version and date.

So, there are more possibilities than the MOVE issue is comming upstream from wsgidav than from Seafile itself. But like @shoeper already commented, could not be at all a general wsgidav/seafdav issue, instead a specific one.

I also had an issue with Keepass2Android not reliably uploading a changed KDBX to my Seafile, it also ended up with having a 502.
So I played around a little bit and connected to Webdav through Ubuntu’s file manager (Nautilus) and didn’t see any obvious issue with renaming or moving files on Seafile 7.1.4 Pro.
Any specific tests I can do to see if the issue also exists here?

The Keepass issue is somehow related to the builtin okhttp server they use, this has some issues with http2 so I disabled this on my nginx and it’s reliable again.

Hi, just to confirm, I can also see the 502 errors here with the MOVE operations, when my FolderSync is uploading and renaming files. I’m running 7.1.3, but there is nothing in the changelog about WebDav in 7.1.4.

Hi, the corresponding bug in the wsgidav is 183. Unfortunately, I can’t add links here, but it looks like we need to rewrite the Destination header in nginx (or patch wsgidav).

@Erik_Tews A couple of weeks ago I was reading every issue in wsgidav and already applied the workaround, here is how it looks like nginx in my case for seafdav

    proxy_set_header   Host $host;
    proxy_set_header   X-Real-IP $remote_addr;
    proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header   X-Forwarded-Host $server_name;

    proxy_set_header   X-Forwarded-Proto $scheme; # wsgidav issue 183

    client_max_body_size 0;
    proxy_connect_timeout  36000s;
    proxy_read_timeout  36000s;
    proxy_send_timeout  36000s;
    send_timeout  36000s;
    proxy_http_version                 1.1;

    # This option is only available for Nginx >= 1.8.0. See more details below.
    proxy_request_buffering off;      # works well with mp4
    proxy_buffering off;

But even that, the js could not be served properly. The pictures (wsgidav logo) are missing and not properly displayed the pages in chrome browser. Just going without nginx in between works fine. If someone has hacked that (regex in nginx) to display properly the pages, go ahed pls. and share it.