Seafdav not (completely) working after server migration

Hi all,
after upgrade to 7.1.3, I’ve migrated my Seafile installation from one server to another and everything it’s working properly, but looks like I’m having some issues with Seafdav.
The only difference (I don’t know if it matters) is that previous installation had nginx reverse proxy local, while the new one has still nginx reverse proxy (with same configuration) but on another machine.

I’m using it to synchronize a Keepass database between my desktops and my mobile phone.
From mobile everything it’s working properly: I can open files, edit, save etc…

From desktop, I can open the file, but when I’m saving it I have an error “502 bad gateway”.
Now, looking deeper into the problem, looks like Windows Keepass when saving a WebDav DB it’s doing the following:

  1. Delete “database”.tmp
  2. Save the database as “database”.tmp
  3. Delete the original database
  4. Rename “database”.tmp to the original name

Looking at my seafdav.log I can confirm the steps, but I don’t know why when it receives a “MOVE” command I get the 502 bad gateway error:

2020-04-06 20:34:57.967 - <140112484820800> wsgidav.wsgidav_app         INFO    :  192.168.6.2 - {seafile username} - [2020-04-06 18:34:57] "GET /{FileName}.kdbx" depth=0, elap=0.134sec -> 200 OK
2020-04-06 20:35:01.621 - <140112484820800> wsgidav.wsgidav_app         INFO    :  192.168.6.2 - {seafile username} - [2020-04-06 18:35:01] "PUT /{FileName}.kdbx.tmp" length=175662, elap=0.296sec -> 201 Created
2020-04-06 20:35:01.667 - <140112484820800> wsgidav.wsgidav_app         INFO    :  192.168.6.2 - {seafile username} - [2020-04-06 18:35:01] "GET /{FileName}.kdbx" depth=0, elap=0.036sec -> 200 OK
2020-04-06 20:35:02.908 - <140112484820800> wsgidav.wsgidav_app         INFO    :  192.168.6.2 - {seafile username} - [2020-04-06 18:35:02] "DELETE /{FileName}.kdbx" depth=0, elap=0.224sec -> 204 No Content
2020-04-06 20:35:02.954 - <140112484820800> wsgidav.wsgidav_app         INFO    :  192.168.6.2 - {seafile username} - [2020-04-06 18:35:02] "MOVE /{FileName}.kdbx.tmp" dest="https://{seafile domain}/seafdav/{FileName}.kdbx", depth=0, overwrite=T, elap=0.041sec -> 502 Bad Gateway

This instead is the seafdav.log of the same operation on the old server:

2020-04-05 20:30:21.684 - <140483044108096> wsgidav.wsgidav_app         INFO    :  127.0.0.1 - {seafile username} - [2020-04-05 18:30:21] "GET /{FileName}.kdbx" depth=0, elap=0.03
2020-04-05 20:30:22.575 - <140483044108096> wsgidav.wsgidav_app         INFO    :  127.0.0.1 - {seafile username} - [2020-04-05 18:30:22] "PUT /{FileName}.kdbx.tmp" length=174638, elap=0.311sec -> 201 Created
2020-04-05 20:30:22.670 - <140483044108096> wsgidav.wsgidav_app         INFO    :  127.0.0.1 - {seafile username} - [2020-04-05 18:30:22] "GET /{FileName}.kdbx" depth=0, elap=0.021sec -> 200 OK
2020-04-05 20:30:22.971 - <140483044108096> wsgidav.wsgidav_app         INFO    :  127.0.0.1 - {seafile username} - [2020-04-05 18:30:22] "DELETE /{FileName}.kdbx" depth=0, elap=0.082sec -> 204 No Content
2020-04-05 20:30:23.115 - <140483044108096> wsgidav.wsgidav_app         INFO    :  127.0.0.1 - {seafile username} - [2020-04-05 18:30:23] "MOVE /{FileName}.kdbx.tmp" dest="https://{seafile domain}/seafdav/{FileName}.kdbx", depth=0, overwrite=T, elap=0.080sec -> 204 No Content

What I don’t understand is why in seafdav.log I have a 502 bad gateway that should be a nginx message? Or also seafdav internally it’s doing something similar?

Thanks!

1 Like

@Jonathan I’ve found this old topic about the same issue:

To be honest new server could be slower and also latencies are really reduced (new server is on premise while old one was in cloud), could be related? Or the same issue could be present in the “delete” call so move it’s executed while file was still there?
Is there any other log that could be helpful for you in case or you think everything should be solved already in 6.0.4 patch?

I have the same problem. See also:

Hi,

I’m facing the same issue with 7.1.3.
Are there any updates or has this maybe been fixed with 7.1.4?

Thanks!

This worked. Thanks a lot!