-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Comments
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. |
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. Thanks and please keep me updated |
@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. |
@imwhatiam Thanks for that info. Do you know how long Seafile 10 will work further? regards |
@imwhatiam Any news regarding this issue? |
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! thanky & regards |
Are you sure about this? I see the same misbehaviour using
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! |
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:
Alpine:
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! |
Hi @harenber thanks for that informations! So that means Webdav does not work generally in Seafile? Not only in Windows! regards |
@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. |
@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" |
The 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 I see an empty
With
|
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 I'm stalling a Seafile 10 upgrade, same as you are… 😉 We all need a solution. |
Finally, I think I got something! There is an issue with Please, can someone confirm my findings # 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 |
Thanks @bbx0 ! i will check that i our testlab today or tomorrow |
The issue is triggered, when # seafile-data/seafile/conf/seafdav.conf
[WEBDAV]
enabled = true
port = 8080
share_name = /seafdav
workers = 1
Here is a Dockerfile with vanilla |
Short summary in my assessment. Would be nice to get a review on this and of course a fix. 😉
To fix this:
A workaround for Seafile # seafile-data/seafile/conf/seafdav.conf
[WEBDAV]
enabled = true
port = 8080
share_name = /seafdav
workers = 1 |
seafile-data/seafile/conf/seafdav.conf[WEBDAV] 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
|
Okay, the With drop-in config for # 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 |
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?
The text was updated successfully, but these errors were encountered: