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:
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.
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.
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.
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.
File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/opt/seafile/seafile-server-latest/seahub/thirdpart/wsgidav/server/server_cli.py", line 44, in <module>
from wsgidav.dc.domain_controller import SeafileDomainController
File "/opt/seafile/seafile-server-latest/seahub/thirdpart/wsgidav/dc/domain_controller.py", line 4, in <module>
from pysearpc import SearpcError
ModuleNotFoundError: No module named 'pysearpc'
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.
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 https://github.com/mar10/wsgidav/issues/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.