Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docker Seafile 11 Seafdav (Webdav) upload issue: 0 Byte Files Windows/Linux/Mac #2809

Open
nobe80 opened this issue Aug 12, 2024 · 21 comments
Open

Comments

@nobe80
Copy link

nobe80 commented Aug 12, 2024

Hi,

i have faced an issue with Seafile webdav (Seafdav) when i use Seafile Version 11 after upgrade to 11.0.11.
The issue is the follow:

In Windows file explorer i have successful a Webdav drive over https to the Seafile server. So seafdav is enabled, we can see all folders. When i upload some files like pdf or simple text files i get an error “…
file is to big…” and i have 0 Bytes files in the folder.

When i downgrade to Seafile Version 10 again no problems at all. Everything works fine then.
We use Seafile docker community.

Does anyone have a hint what could be the reason?

seafdav2
seafdav1

@imwhatiam
Copy link
Member

Hello, Seafile’s seafdav is based on the wsgidav project(GitHub - mar10/wsgidav: A generic and extendable WebDAV server based on WSGI 1). Seafile version 10 uses wsgidav 4.1, while version 11 uses wsgidav 4.3.

It seems that wsgidav added some checks in version 4.3, which caused your issue.

We have also conducted tests, and it seems that this issue only occurs when connecting to seafdav using Windows File Explorer. Other WebDAV clients do not encounter this problem.

We will debug it to see if they can resolve this problem.

@nobe80
Copy link
Author

nobe80 commented Sep 2, 2024

Hi @imwhatiam

so that means that with wsgidav as standalone the bug would also be there?

So the functionality without any apps is the most important thing for using Seafile with Windows.
It is a must have that it works further, like before.

Thanks and please keep me updated

@imwhatiam
Copy link
Member

@nobe80 We will try to solve this problem, but we need to gain a deep understanding of the WsgiDAV project, which may take quite a long time.

@nobe80
Copy link
Author

nobe80 commented Sep 9, 2024

@imwhatiam Thanks for that info. Do you know how long Seafile 10 will work further?
Because in that case we have to use Seafile 10 until the bug is fixed.

regards

@gianogli
Copy link

@imwhatiam Any news regarding this issue?
We upgrade our seafile installation to 11 some weeks ago and now all our users have 0 byte files only!!! If they try to upload/restore the correct file, the server change it again with a file of 0 byte after 3/4 seconds. Unusable!!!
Can you tell us how the correct way to rollback to 10? (on-premise pro installation without docker).
Thanks...

@nobe80
Copy link
Author

nobe80 commented Nov 21, 2024

Hi @imwhatiam ,

do you have any news on this? The issue is still pending since summer this year! We need that feature because the native webdav is the most important function and the reason why we are using Seafile!
So please tell me when this mistake will be fixed? What happend in the meantime ate the dev team?

thanky & regards

@harenber
Copy link

harenber commented Dec 1, 2024

We have also conducted tests, and it seems that this issue only occurs when connecting to seafdav using Windows File Explorer. Other WebDAV clients do not encounter this problem.

Are you sure about this? I see the same misbehaviour using davfs2 on Debian (crostini on a Chromebook):

harenber@penguin:~/seafile/private/ansible/plus$ df .
Filesystem                           1K-blocks  Used Available Use% Mounted on
https://XXX/seafdav/      7184  7184         0 100% /home/harenber/seafile
harenber@penguin:~/seafile/private/ansible/plus$ echo "Testfile" > aaa
bash: aaa: Input/output error
harenber@penguin:~/seafile/private/ansible/plus$ cat aaa
harenber@penguin:~/seafile/private/ansible/plus$ ls -l aaa
-rw-r--r-- 1 harenber davfs2 0 Dec  1 17:55 aaa
harenber@penguin:~/seafile/private/ansible/plus$ 

This bug is really a bummer. My strategy to re-install my vserver farm after a catastropic failure in the VMs is based on the possibility to mount via WebDAV. And I learned the hard way that this fails now as I upgraded my Seafile server.

Cheers!

@harenber
Copy link

harenber commented Dec 8, 2024

Just to add to that: I tried from a Linux Mint 22 "Wilma" (davfs2 1.7.0) as well as from Alpine Linux 3.20 (davfs2-1.6.1-r2), all the same results:

Mint:

root@ThinkCentre-M720q:/tmp/a/private/ansible# echo "hallo" > test
-bash: test: Eingabe-/Ausgabefehler
root@ThinkCentre-M720q:/tmp/a/private/ansible# cat test
root@ThinkCentre-M720q:/tmp/a/private/ansible# ls -l test
-rw-r--r-- 1 root root 0 Dez  8 17:26 test
root@ThinkCentre-M720q:/tmp/a/private/ansible# rm test

Alpine:

cubietruck:/tmp/a/private# echo "hallo from Alpine" > alpinetest
-ash: can't create alpinetest: I/O error
cubietruck:/tmp/a/private# ls -l alpinetest 
-rw-r--r--    1 root     root             0 Dec  8 16:27 alpinetest
cubietruck:/tmp/a/private# rm alpinetest 

So it seems that all Linux CLI clients are broken as well.

@imwhatiam : any chance to get an update?

A hint to anyone who needs to "mount" the repos urgently without a full client install: rclone seems to work well with a Seafile 11 server.

Cheers!

@nobe80
Copy link
Author

nobe80 commented Dec 9, 2024

Hi @harenber

thanks for that informations! So that means Webdav does not work generally in Seafile? Not only in Windows!
I don't understand hardly anyone has noticed this.

regards

@harenber
Copy link

harenber commented Dec 9, 2024

@nobe80 looks like. I had a chance to do a last test on a recent MacBook Pro and:

harenber@dhcp-109-37 ansible % echo "test from MacOS" > testfile
harenber@dhcp-109-37 ansible % cat testfile
harenber@dhcp-109-37 ansible % ls -l testfile
-rwx------  1 harenber  staff  0  9 Dez 13:08 testfile
harenber@dhcp-109-37 ansible % df .
Filesystem                           512-blocks Used Available Capacity iused ifree %iused  Mounted on
https://XXX/seafdav/          0    0         0   100%       0     0     -   /Volumes/seafdav
harenber@dhcp-109-37 ansible %

So also on MacOS the 0 byte problem. Only difference (compared to Linux): MacOS doesn't throw an error - it just silently drops the content of the file.

Maybe I have a problem with my server (docker based - and it used to work with WebDAV in the past), but all WebDAV clients I could test don't seem to work. What seems to work, however, is the WebDAV implementation used by the Keepass2Android app.

@nobe80
Copy link
Author

nobe80 commented Dec 9, 2024

@harenber thank for the info.

We need the native webdav support thats works.

I have changed/expanded the title from only at "Windows" to "Windows/Linux/Mac"

@nobe80 nobe80 changed the title Docker Seafile 11 Seafdav (Webdav) upload issue: 0 Byte Files Docker Seafile 11 Seafdav (Webdav) upload issue: 0 Byte Files Windows/Linux/Mac Dec 10, 2024
@bbx0
Copy link

bbx0 commented Dec 10, 2024

The davfs2 issue can be mitigated by setting use_locks 0 in /etc/davfs2/davfs2.conf, see docs. I tried disabling LOCK support completely within wsgidav to test if it helps Windows as well. Unfortunately this seems not to be the case.

Here is what I tried:

# mount this file as volume into the seafile container at /opt/seafile/seafile-server-11.0.13/wsgidav.yaml
# -v ./wsgidav.yaml:/opt/seafile/seafile-server-11.0.13/wsgidav.yaml

# disable LOCK support
lock_storage: null

While this makes davfs2 work without changes in /etc/davfs2/davfs2.conf, it does not help with Windows. It seems Windows requires LOCK support to function. There are plenty options for wsgidav in sample_wsgidav.yaml. I played with a few (property_manager, mutable_live_props, hotfixes) but to no avail.

I see an empty PUT before LOCK followed by a PATCH to upload the content. Presumably this is why we see the zero byte files as the PATCH is what fails.
With lock_storage: true (the default), PATCH fails due a precondition (but the LOCK appears successful?).

15:28:36.614 - INFO    : 127.0.0.1 - [email protected] - [2024-12-10 14:28:36] "PROPFIND /test1/test2.txt" length=0, depth=0, connection="close", agent="Microsoft-WebDAV-MiniRedir/10.0.19045", elap=0.007sec -> 404 Not Found
15:28:36.624 - DEBUG   : check_write_permission(/seafdav/test1/, 0, [], [email protected])
15:28:36.624 - DEBUG   :   checking /seafdav/test1/
15:28:36.624 - DEBUG   :   checking /seafdav/
15:28:36.624 - DEBUG   :   checking /
15:28:36.640 - INFO    : 127.0.0.1 - [email protected] - [2024-12-10 14:28:36] "PUT /test1/test2.txt" length=0, connection="close", agent="Microsoft-WebDAV-MiniRedir/10.0.19045", elap=0.024sec -> 201 Created
15:28:36.648 - DEBUG   : checkLockPermission(/seafdav/test1/test2.txt, exclusive, infinity, [email protected])
15:28:36.649 - DEBUG   : LockStorageDict.set('/seafdav/test1/test2.txt'): Lock(<78ab..>, '/seafdav/test1/test2.txt', [email protected], exclusive, depth-infinity, until 2024-12-10 15:28:36 (in 3599.999990463257 seconds)
15:28:36.650 - INFO    : 127.0.0.1 - [email protected] - [2024-12-10 14:28:36] "LOCK /test1/test2.txt" length=205, depth=infinity, connection="close", agent="Microsoft-WebDAV-MiniRedir/10.0.19045", elap=0.008sec -> 200 OK
15:28:36.659 - DEBUG   : parse_if_header_dict
{'*': [[(True,
         'locktoken',
         'opaquelocktoken:0x78abb7bc37b2cdfc766f98f7e147d94635a7510a01880c81dfe7b38bbaa87bfc')]]}
15:28:36.659 - DEBUG   : test_if_header_dict(/seafdav/test1/test2.txt, [], 0000000000000000000000000000000000000000)
15:28:36.659 - DEBUG   :   -> FAILED
15:28:36.659 - DEBUG   : Raising DAVError 412 Precondition Failed: 'If' header condition failed.
15:28:36.659 - DEBUG   : Caught (412, "'If' header condition failed.")
15:28:36.660 - INFO    : 127.0.0.1 - [email protected] - [2024-12-10 14:28:36] "PROPPATCH /test1/test2.txt" length=443, depth=0, connection="close", agent="Microsoft-WebDAV-MiniRedir/10.0.19045", elap=0.007sec -> 412 Precondition Failed

With lock_storage: null, no PATCH is attempted after LOCK fails.

15:16:19.734 - INFO    : 127.0.0.1 - [email protected] - [2024-12-10 14:16:19] "PUT /test1/test1.txt" length=0, connection="close", agent="Microsoft-WebDAV-MiniRedir/10.0.19045", elap=0.029sec -> 201 Created
15:16:19.741 - ERROR   : Invalid HTTP method {requestmethod!r}
15:16:19.741 - DEBUG   : Raising DAVError 405 Method Not Allowed
15:16:19.741 - DEBUG   : Caught (405, None)
15:16:19.741 - INFO    : 127.0.0.1 - [email protected] - [2024-12-10 14:16:19] "LOCK /test1/test1.txt" length=205, connection="close", agent="Microsoft-WebDAV-MiniRedir/10.0.19045", elap=0.005sec -> 405 Method Not Allowed
15:16:19.750 - DEBUG   : get_properties(/seafdav/test1/test1.txt)
15:16:19.750 - INFO    : 127.0.0.1 - [email protected] - [2024-12-10 14:16:19] "PROPFIND /test1/test1.txt" length=0, depth=0, connection="close", agent="Microsoft-WebDAV-MiniRedir/10.0.19045", elap=0.007sec -> 207 Multi-Status
15:16:19.759 - DEBUG   : get_properties(/seafdav/test1/test1.txt)

@nobe80
Copy link
Author

nobe80 commented Dec 10, 2024

The davfs2 issue can be mitigated by setting use_locks 0 in /etc/davfs2/davfs2.conf, see docs. I tried disabling LOCK support completely within wsgidav to test if it helps Windows as well. Unfortunately this seems not to be the case.

Here is what I tried:

# mount this file as volume into the seafile container at /opt/seafile/seafile-server-11.0.13/wsgidav.yaml
# -v ./wsgidav.yaml:/opt/seafile/seafile-server-11.0.13/wsgidav.yaml

# disable LOCK support
lock_storage: null

While this makes davfs2 work without changes in /etc/davfs2/davfs2.conf, it does not help with Windows. It seems Windows requires LOCK support to function. There are plenty options for wsgidav in sample_wsgidav.yaml. I played with a few (property_manager, mutable_live_props, hotfixes) but to no avail.

I see an empty PUT before LOCK followed by a PATCH to upload the content. Presumably this is why we see the zero byte files as the PATCH is what fails. With lock_storage: true (the default), PATCH fails due a precondition (but the LOCK appears successful?).

15:28:36.614 - INFO    : 127.0.0.1 - [email protected] - [2024-12-10 14:28:36] "PROPFIND /test1/test2.txt" length=0, depth=0, connection="close", agent="Microsoft-WebDAV-MiniRedir/10.0.19045", elap=0.007sec -> 404 Not Found
15:28:36.624 - DEBUG   : check_write_permission(/seafdav/test1/, 0, [], [email protected])
15:28:36.624 - DEBUG   :   checking /seafdav/test1/
15:28:36.624 - DEBUG   :   checking /seafdav/
15:28:36.624 - DEBUG   :   checking /
15:28:36.640 - INFO    : 127.0.0.1 - [email protected] - [2024-12-10 14:28:36] "PUT /test1/test2.txt" length=0, connection="close", agent="Microsoft-WebDAV-MiniRedir/10.0.19045", elap=0.024sec -> 201 Created
15:28:36.648 - DEBUG   : checkLockPermission(/seafdav/test1/test2.txt, exclusive, infinity, [email protected])
15:28:36.649 - DEBUG   : LockStorageDict.set('/seafdav/test1/test2.txt'): Lock(<78ab..>, '/seafdav/test1/test2.txt', [email protected], exclusive, depth-infinity, until 2024-12-10 15:28:36 (in 3599.999990463257 seconds)
15:28:36.650 - INFO    : 127.0.0.1 - [email protected] - [2024-12-10 14:28:36] "LOCK /test1/test2.txt" length=205, depth=infinity, connection="close", agent="Microsoft-WebDAV-MiniRedir/10.0.19045", elap=0.008sec -> 200 OK
15:28:36.659 - DEBUG   : parse_if_header_dict
{'*': [[(True,
         'locktoken',
         'opaquelocktoken:0x78abb7bc37b2cdfc766f98f7e147d94635a7510a01880c81dfe7b38bbaa87bfc')]]}
15:28:36.659 - DEBUG   : test_if_header_dict(/seafdav/test1/test2.txt, [], 0000000000000000000000000000000000000000)
15:28:36.659 - DEBUG   :   -> FAILED
15:28:36.659 - DEBUG   : Raising DAVError 412 Precondition Failed: 'If' header condition failed.
15:28:36.659 - DEBUG   : Caught (412, "'If' header condition failed.")
15:28:36.660 - INFO    : 127.0.0.1 - [email protected] - [2024-12-10 14:28:36] "PROPPATCH /test1/test2.txt" length=443, depth=0, connection="close", agent="Microsoft-WebDAV-MiniRedir/10.0.19045", elap=0.007sec -> 412 Precondition Failed

With lock_storage: null, no PATCH is attempted after LOCK fails.

15:16:19.734 - INFO    : 127.0.0.1 - [email protected] - [2024-12-10 14:16:19] "PUT /test1/test1.txt" length=0, connection="close", agent="Microsoft-WebDAV-MiniRedir/10.0.19045", elap=0.029sec -> 201 Created
15:16:19.741 - ERROR   : Invalid HTTP method {requestmethod!r}
15:16:19.741 - DEBUG   : Raising DAVError 405 Method Not Allowed
15:16:19.741 - DEBUG   : Caught (405, None)
15:16:19.741 - INFO    : 127.0.0.1 - [email protected] - [2024-12-10 14:16:19] "LOCK /test1/test1.txt" length=205, connection="close", agent="Microsoft-WebDAV-MiniRedir/10.0.19045", elap=0.005sec -> 405 Method Not Allowed
15:16:19.750 - DEBUG   : get_properties(/seafdav/test1/test1.txt)
15:16:19.750 - INFO    : 127.0.0.1 - [email protected] - [2024-12-10 14:16:19] "PROPFIND /test1/test1.txt" length=0, depth=0, connection="close", agent="Microsoft-WebDAV-MiniRedir/10.0.19045", elap=0.007sec -> 207 Multi-Status
15:16:19.759 - DEBUG   : get_properties(/seafdav/test1/test1.txt)

The Lock Support is absolutley required and useful to prevent inconsistent data. Simply if 2 user open a document at the same time.

This bug exist since beginning of release of Seafile 11...

@bbx0
Copy link

bbx0 commented Dec 10, 2024

The Lock Support is absolutley required and useful to prevent inconsistent data. Simply if 2 user open a document at the same time.

This bug exist since beginning of release of Seafile 11...

You misread my comment. I'm clear about the need for LOCK support. davfs2 does not work well with Seafile 10 already. Since davfs2 was brought into picture now, I was curious if the same problem causes issues on Windows and started looking into it. So far no log messages or anything have be shared. To me, it's not obvious that the davfs2 and Windows issue is caused by the same.

I'm stalling a Seafile 10 upgrade, same as you are… 😉 We all need a solution.

@bbx0
Copy link

bbx0 commented Dec 10, 2024

Finally, I think I got something! There is an issue with gunicorn. When running seafdav under cheroot, Windows starts working again. (cheroot is the wsgidav default, so this might be an upstream issue with gunicorn but we will need a seafdav-independent reproducer to get this addressed.)

Please, can someone confirm my findings seafdav first:

# disable the seafdav autostart
$ cat seafile-data/seafile/conf/seafdav.conf
[WEBDAV]
enabled    = false
debug      = true
port       = 8080
share_name = /seafdav

# start Seafile
$ docker compose up

# docker exec into the container
$ docker exec -ti seafile bash

## change the WORKDIR
cd seafile-server-11.0.13/

## setup the ENV (double-check the DB_ROOT_PASSWD value)
export DB_HOST=db
export DB_ROOT_PASSWD=db_dev
export PYTHONPATH=/opt/seafile/seafile-server-11.0.13/seafile/lib/python3/site-packages:/opt/seafile/seafile-server-11.0.13/seafile/lib64/python3/site-packages:/opt/seafile/seafile-server-11.0.13/seahub/thirdpart::/opt/seafile/seafile-server-11.0.13/pro/python:/opt/seafile/conf:/opt/seafile/seafile-server-11.0.13/seahub:/opt/seafile/seafile-server-11.0.13/seahub/thirdpart:/opt/seafile/seafile-server-11.0.13/seahub/seahub-extra:/opt/seafile/seafile-server-11.0.13/seahub/seahub-extra/thirdparts:/opt/seafile/seafile-server-11.0.13/seafile/lib/python3/site-packages:/opt/seafile/seafile-server-11.0.13/seafile/lib64/python3/site-packages
export CCNET_CONF_DIR=/opt/seafile/ccnet
export SEAFILE_CONF_DIR=/opt/seafile/seafile-data
export SEAFILE_CENTRAL_CONF_DIR=/opt/seafile/conf
export SEAFILE_RPC_PIPE_PATH=/opt/seafile/seafile-server-11.0.13/runtime
export SEAHUB_DIR=/opt/seafile/seafile-server-11.0.13/seahub
export SEAFDAV_CONF=/opt/seafile/conf/seafdav.conf
export SEAFILE_LD_LIBRARY_PATH=/opt/seafile/seafile-server-11.0.13/seafile/lib/:/opt/seafile/seafile-server-11.0.13/seafile/lib64:

## spawn seafdav with gunicorn - this is what the `seafile-controller.c` does and will produce the zero byte files
/usr/bin/python3 -m wsgidav.server.server_cli --server gunicorn --root / --log-file /opt/seafile/logs/seafdav.log --pid /opt/seafile/pids/seafdav.pid --port 8080 --host 0.0.0.0 -vvv

## exit via CTRL^C + CTRL^C

## spawn seafdav with cheroot - this will make the windows clients work again (but `davfs2` will still fail)
pip install cheroot
/usr/bin/python3 -m wsgidav.server.server_cli --server cheroot --root / --log-file /opt/seafile/logs/seafdav.log --pid /opt/seafile/pids/seafdav.pid --port 8080 --host 0.0.0.0 -vvv

@nobe80
Copy link
Author

nobe80 commented Dec 11, 2024

Thanks @bbx0 !

i will check that i our testlab today or tomorrow

@bbx0
Copy link

bbx0 commented Dec 11, 2024

The issue is triggered, when gunicorn runs with more than 1 worker. Seafile sets a default of 5 workers. Reducing it to 1 prevents the issue.

# seafile-data/seafile/conf/seafdav.conf
[WEBDAV]
enabled    = true
port       = 8080
share_name = /seafdav
workers    = 1
  • I can also not trigger it with a value of 2, but this might be a fluke.
  • A number of 3 or 4 workers does trigger it.
  • The issue also occurs with and without nginx as reverse proxy.
  • davfs2 still does not work with use_lock 1 (same as with Seafile 10)

Here is a Dockerfile with vanilla wsgidav, which mimics the seafdav setup. It has the same issue.

@bbx0
Copy link

bbx0 commented Dec 14, 2024

Short summary in my assessment. Would be nice to get a review on this and of course a fix. 😉

  • The issue is caused by haiwen/seafdav@9dff6bc. By setting the workers parameter instead of threads, gunicorn runs in sync worker mode instead of gthread. (see settings.html#threads)
  • wsgidav requires a shared-memory LockManager to function properly but with gunicorn in sync mode each worker runs isolated causing issues when acquiring a LOCK during file upload (mar10/wsgidav#332). This results in a 0 byte file as only the initial PUT request is issued without a LOCK. The following PROPPATCH and the attempted cleanup DELETE fail due to lack of LOCK and leave a 0 byte file behind.

To fix this:

  • Seafile can hard-code workers to 1 and allow threads to be adjusted for scaling. This will make gunicorn run in gthread mode and restores the old behavior.
  • Seafile enrolls something like Redis and uses LockStorageRedis in wsgidav to allow cross-worker locking with gunicorn in sync mode, see discussion in mar10/wsgidav#332. This seems overkill.
  • In general it would be good to just use the wsgidav.yaml config file for seafdav, so the admin can decide which option to choose and ship a save default like workers: 1 threads: 5.

A workaround for Seafile 11.0.13 is to set workers: 1.

# seafile-data/seafile/conf/seafdav.conf
[WEBDAV]
enabled    = true
port       = 8080
share_name = /seafdav
workers    = 1

@mh-muc
Copy link

mh-muc commented Dec 14, 2024

seafile-data/seafile/conf/seafdav.conf

[WEBDAV]
enabled = true
port = 8080
share_name = /seafdav
workers = 1

Does not work for me, still 0 byte upload via webdav (Seafile 12.0.4, Docker)

@bbx0
Copy link

bbx0 commented Dec 14, 2024

seafile-data/seafile/conf/seafdav.conf

[WEBDAV] enabled = true port = 8080 share_name = /seafdav workers = 1

Does not work for me, still 0 byte upload via webdav (Seafile 12.0.4, Docker)

Interesting, I've not checked Seafile 12. Can you show which worker is used by wsgidav in seafile-data/seafile/logs/controller.log? You may need to add debug = true in seafdav.conf to get this printed. It should look somewhat like this:

2024-12-14 12:28:15 seafile-controller.c(82): spawn_process: /usr/bin/python3 -m wsgidav.server.server_cli --server gunicorn --root / --log-file /opt/seafile/logs/seafdav.log --pid /opt/seafile/pids/seafda
v.pid --port 8080 --host 0.0.0.0 -v
2024-12-14 12:28:15 seafile-controller.c(116): spawned /usr/bin/python3, pid 226
2024-12-14 12:28:16 seafile-controller.c(124): [2024-12-14 12:28:16 +0100] [226] [INFO] Starting gunicorn 20.1.0
[2024-12-14 12:28:16 +0100] [226] [INFO] Listening at: http://0.0.0.0:8080 (226)
[2024-12-14 12:28:16 +0100] [226] [INFO] Using worker: gthread

@bbx0
Copy link

bbx0 commented Dec 14, 2024

Okay, the controller.log does not exist anymore with Seafile 12 but a seafile-monitor.log. I can confirm there is a 0 byte file issue with Seafile 12, not solved by the workaround above. It yields a slightly different error message, though. DENIED due to locked parent Lock, this may or may not be caused by the same issue.

With drop-in config for wsgidav, I was able to switch to gthread in Seafile 12 but it does not solve the issue here.

# seafile-server.yml (snippet)
configs:
  wsgidav.yaml:
    content: |
      verbose: 6
      server: gunicorn
      server_args:
        workers: 1
        threads: 5
        timeout: 1200
services:
  seafile:
    image: ${SEAFILE_IMAGE:-seafileltd/seafile-mc:12.0.4}
    configs:
      - source: wsgidav.yaml
        target: /opt/seafile/seafile-server-12.0.4/wsgidav.yaml
[WEBDAV]
enabled    = true
debug      = true
port       = 8080
share_name = /seafdav
workers    = 1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants