Hi
I have a big issue here - first time that this happens to me in 12 years.
I have an account that has a library - let’s call this admin account.
Inside that Library there are/were several folders.
I am sharing those folder with other accounts - user accounts.
These folders somehow now got lost on the admin account.
It still states a specific size though:
On the user accounts I can still see the shared folders that are inside the library.
I can create for example a text file through the web interface or through the ipad-App.
But the sync client doesn’t work anymore.
The sync client tries to upload/download files but keeps starting over once at 100%.
This is how fart my testing came so far.
There was an irregularity yesterday and somehow my server was unavailable and I couldn’t ping it.
I did a reboot on the server and it seems that since then these folders are missing.
Does anyone know what I can do to fix this error?
I already rebooted the server anothet time.
Thanks a lot in advance of any help
I did some additional tests
in General seafile works fine.
But I can’t delete the recently shared folders.
They are accessible but not managable from the sharing side.
Some help would be really appreciated.
@daniel.pan do you have an idea what I could do?
Can you try these steps:
1. Run the Seafile FSCK Tool
The first step is to run a file system integrity check. This tool can often repair corrupted library metadata and restore missing root directories.
- Stop the Seafile server before running the repair.
- Locate the Library ID (you can find this in the URL when clicking the library in the web interface).
- Run the following command from your Seafile installation directory:
./seaf-fsck.sh --repair [Library-ID]
- If you want to check all libraries, you can omit the ID. After the process completes, restart Seafile and check if the folders reappeared for the admin account.
2. Check Server-Side Error Logs
Please also check the following logs on your server (located in the logs directory of your Seafile installation):
- seafile.log: Look for errors related to the specific Library ID, especially “database is locked,” “failed to get commit,” or “repo is corrupted.”
- seahub.log: Check this for errors that occur when you try to manage or delete the shared folders via the web interface.
Specifically, look for any “Internal Server Error (500)” traces in seahub.log that happen at the exact time you try to access the sharing settings.
1 Like
Thanks you @daniel.pan
The fsck worked and the libraries are back
Please let me say again many thanks for your help - I am glad that in general this fixed the issue - Seafile is great !!
Hi @daniel.pan
Unfortunately it didn;t completely solved it.
One of the 3 shared libraries that came back can’t be downloaded.
At about 11:20 am below you can see the rror message.
Is there something else I can do?
The Library is called “Project Team”.
The seafile.log file shows the below. The FSCK happened on 27/03 in the morning (10am).
2026-03-26 20:31:59 ../common/fs-mgr.c(2662): Failed to get dir for .
2026-03-26 20:31:59 virtual-repo.c(846): Failed to get seafdir id by path in origin repo 66a8472c-4: directory is missing.
2026-03-26 20:33:39 Empty input for zlib, invalid.
2026-03-26 20:33:39 ../common/fs-mgr.c(1707): Failed to decompress dir object 972b3a13238cec975053b58e3316ee16510685f2.
2026-03-26 20:33:39 ../common/fs-mgr.c(2662): Failed to get dir for .
2026-03-26 20:33:39 virtual-repo.c(846): Failed to get seafdir id by path in origin repo 66a8472c-4: directory is missing.
2026-03-26 20:33:42 Empty input for zlib, invalid.
2026-03-26 20:33:42 ../common/fs-mgr.c(1707): Failed to decompress dir object 972b3a13238cec975053b58e3316ee16510685f2.
2026-03-26 20:33:42 ../common/fs-mgr.c(2662): Failed to get dir for .
2026-03-26 20:33:42 virtual-repo.c(846): Failed to get seafdir id by path in origin repo 66a8472c-4: directory is missing.
2026-03-26 20:39:30 start to serve on pipe client
2026-03-27 08:56:24 Empty input for zlib, invalid.
2026-03-27 08:56:24 ../common/fs-mgr.c(1707): Failed to decompress dir object 972b3a13238cec975053b58e3316ee16510685f2.
2026-03-27 09:41:21 Empty input for zlib, invalid.
2026-03-27 09:41:21 ../common/fs-mgr.c(1707): Failed to decompress dir object 972b3a13238cec975053b58e3316ee16510685f2.
2026-03-27 10:03:53 seafile-session.c(65): fileserver: web_token_expire_time = 3600
2026-03-27 10:03:53 seafile-session.c(77): fileserver: max_index_processing_threads= 3
2026-03-27 10:03:53 seafile-session.c(90): fileserver: fixed_block_size = 8388608
2026-03-27 10:03:53 seafile-session.c(102): fileserver: max_indexing_threads = 1
2026-03-27 10:03:53 ../common/seaf-utils.c(359): Use database Mysql
2026-03-27 10:03:53 http-server.c(195): fileserver: worker_threads = 10
2026-03-27 10:03:53 http-server.c(217): fileserver: cluster_shared_temp_file_mode = 600
2026-03-27 10:03:54 socket file exists, delete it anyway
2026-03-27 10:04:00 start to serve on pipe client
2026-03-27 10:04:00 start to serve on pipe client
2026-03-27 10:04:00 start to serve on pipe client
2026-03-27 10:04:02 start to serve on pipe client
2026-03-27 10:04:09 start to serve on pipe client
2026-03-27 10:04:09 start to serve on pipe client
2026-03-27 10:04:10 start to serve on pipe client
2026-03-27 10:04:15 start to serve on pipe client
2026-03-27 10:04:16 start to serve on pipe client
2026-03-27 11:20:01 ../common/fs-mgr.c(1895): [fs mgr] Failed to read dir 972b3a13238cec975053b58e3316ee16510685f2.
2026-03-27 11:20:01 ../common/diff-simple.c(244): Failed to find dir 66a8472c-496f-4036-b85b-dcb6d81825b9:972b3a13238cec975053b58e3316ee16510685f2.
2026-03-27 11:20:02 ../common/fs-mgr.c(1895): [fs mgr] Failed to read dir 972b3a13238cec975053b58e3316ee16510685f2.
2026-03-27 11:20:02 ../common/fs-mgr.c(2662): Failed to get dir for .
2026-03-27 11:20:02 virtual-repo.c(890): Cannot find seafdir for repo 66a8472c-4 path /Project Team.
2026-03-27 11:20:25 ../common/fs-mgr.c(1895): [fs mgr] Failed to read dir 972b3a13238cec975053b58e3316ee16510685f2.
2026-03-27 11:20:25 ../common/fs-mgr.c(2662): Failed to get dir for .
2026-03-27 11:20:25 virtual-repo.c(890): Cannot find seafdir for repo 66a8472c-4 path /Project Team.
2026-03-27 11:22:08 start to serve on pipe client
2026-03-27 11:31:10 zip-download-mgr.c(462): Total download size 56764318737, exceed max download dir size 10485760000.
2026-03-27 11:34:02 start to serve on pipe client
2026-03-27 12:04:02 start to serve on pipe client
You can try to “resync the library” at the client side after you fix the library at the server side by seaf-fsck.
Thanks Daniel
This time this didn’t work - it wouldn’t download anymore.
It stayed for 12 hours at 0% (58GB Library).
We of course had a backup and created a new Library that we will now share.
Something went awfully wrong during the server crash as it seems.
Thanks a lot again for your super quick help, though!!
