Hi, I recently upgraded from Seafile 11 to 12. I like the new UI!
I have a folder containing lots of photos (3236 files) and trying to open it in the Web interface or on the Android client shows an Internal Server Error. This did not happen on Seafile 11 and does not happen for any other folder.
Nothing shows up on seafile.log. The only indication that something went wrong is in seahub.log:
2025-02-01 07:03:23,154 [ERROR] seahub.api2.endpoints.dir:321 get Failed to read from socket
2025-02-01 07:03:23,156 [ERROR] django.request:241 log_response Internal Server Error: /api/v2.1/repos/e9fc6779-54b2-401c-b519-f9e40e8b7617/dir/
seaf-fsck for the repo containing the folder passed, but didn’t fix the issue:
[seaf-fsck] [2025-02-01 06:49:19] [INFO] fsck.c(606): Running fsck for repo e9fc6779-54b2-401c-b519-f9e40e8b7617.
[seaf-fsck] [2025-02-01 06:49:19] [INFO] fsck.c(431): Checking file system integrity of repo Arquivos(e9fc6779)...
[seaf-fsck] [2025-02-01 06:54:04] [INFO] fsck.c(670): Fsck finished for repo e9fc6779.
I’m not sure how to troubleshoot this further.
Debian Testing, Docker 27.5.0 (build a187fa5), Seafile App 3.0.7
First step, make sure you have a backup. Preferably, the backup or snapshot you made before doing the upgrade, but if you don’t already have one (or have removed it), make one now.
I think I would then check that the files are at least accessible with seaf-fuse.sh. This should let you mount that library (read-only) and copy some files out to verify it works. If that’s good, then at least you know your data is ok, and the worst-case scenario would be that you copy it all out from there, delete and recreate the library, and then load the files back in. I wouldn’t immediately jump to doing that, but at least you will know you have the option.
https://manual.seafile.com/11.0/extension/fuse/
Assuming that’s all fine, then check the logs again. See if the SQL server log shows any errors. Are there errors from the nginx inside the seafile container? You could also try to bypass your reverse proxy and talk directly to the seafile container to see if that works.
Hi, thanks for the advice.
I still have a backup from before I upgraded. I also have the whole folder synced to my PC. The rest of the library is fine, it’s just this one folder.
Uploading the entire folder to a fresh library through Seadrive and opening it on Web shows the same error:
I tried starting seaf-fuse, but it always shows an “already running” warning, even though it doesn’t show up on docker compose top seafile:
root@00ba66cb61b5:/opt/seafile# cd seafile-server-latest
root@00ba66cb61b5:/opt/seafile/seafile-server-latest# ./seaf-fuse.sh start /seafile-fuse/
seaf-fuse is already running, pid 2073
2077
root@00ba66cb61b5:/opt/seafile/seafile-server-latest# ./seaf-fuse.sh start /seafile-fuse
seaf-fuse is already running, pid 2079
2083
root@00ba66cb61b5:/opt/seafile/seafile-server-latest# ./seaf-fuse.sh start /seafile-fuse
seaf-fuse is already running, pid 2087
2091
Stopping and starting seaf-fuse in one command doesn’t show the warning, but nothing is mounted:
root@00ba66cb61b5:/opt/seafile/seafile-server-latest# ./seaf-fuse.sh stop && ./seaf-fuse.sh start /seafile-fuse
Stopping seaf-fuse ...
Terminated
root@00ba66cb61b5:/opt/seafile/seafile-server-latest# ls -la /seafile-fuse/
total 8
drwxr-xr-x 2 root root 4096 Feb 4 04:42 .
drwxr-xr-x 1 root root 4096 Feb 4 04:47 ..
No errors appear on the MySQL container logs. Nothing from the container nginx (assuming they’re located at /var/log/nginx). Using the API directly inside the server also shows the Internal Server Error.
* Host localhost:6980 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
* Trying [::1]:6980...
* connect to ::1 port 6980 from ::1 port 51902 failed: ConexĂŁo recusada
* Trying 127.0.0.1:6980...
* Connected to localhost (127.0.0.1) port 6980
* using HTTP/1.x
> GET /api/v2.1/repos/e9fc6779-54b2-401c-b519-f9e40e8b7617/dir/?p=/big+folder+test HTTP/1.1
> Host: localhost:6980
> User-Agent: curl/8.11.1
> Accept: */*
> Cookie: ...
>
* Request completely sent off
< HTTP/1.1 500 Internal Server Error
< Server: nginx
< Date: Tue, 04 Feb 2025 07:55:53 GMT
< Content-Type: application/json
< Content-Length: 37
< Connection: keep-alive
< Allow: GET, POST, DELETE, HEAD, OPTIONS
< Vary: Accept-Language, Cookie
< Content-Language: en
<
* Connection #0 to host localhost left intact
{"error_msg":"Internal Server Error"}
I updated my server with docker compose pull && docker compose up -d and the large folder issue fixed itself. I’m not sure what changed, but it pulled something. I might’ve been using an old Seafile version from a few months ago when I tried upgrading to the beta even though I’m using the 12.0-latest tag.
The seaf-fuse.sh issue still happens - both on my personal instance and on a fresh VM I made specifically to test this issue. I’ll make a separate thread for it.
The seaf-fuse.sh has a function that’s supposed to keep you from running seaf-fuse twice. Unfortunately that detects the seaf-fuse.sh script running (the script see itself) and thinks it is an already running seaf-fuse. You can work around this by copying the script to a name that doesn’t match the check, and then run that:
cp seaf-fuse.sh fuse.sh
./fuse.sh start /shared/seafile/seafile-data/test
That might work for you as a work-around until seaf-fuse.sh is (hopefully) fixed in a future release. For me that let it get further to another error, but I suspect that error comes from changes I made to the way the seafile container runs to try to improve the security. Anyway, I would appreciate it if you would give it a try and confirm that it works. I haven’t ever needed it, but I like to know that I have seaf-fuse to fall back on if I do need it.
1 Like
Works for me!
root@24103c68e658:/opt/seafile# cd seafile-server-latest
root@24103c68e658:/opt/seafile/seafile-server-latest# cp seaf-fuse.sh fuse.sh
root@24103c68e658:/opt/seafile/seafile-server-latest# ./fuse.sh start /seafile-fuse
Starting seaf-fuse, please wait ...
seaf-fuse started
Done.
root@24103c68e658:/opt/seafile/seafile-server-latest# ls /seafile-fuse
ce5e428d73a14c4bb0860aab807378c9@auth.local me@my-domain.com
Awesome! Thanks for checking that. I think my problem is just that I am running the container without any root access, so if I ever need fuse I just need to run the container as root instead of running as the limited user.
