Library should have 8.9GB Data, but all files are empty, seaf-fsck fails

Hello guys,

I have a server running with a lot of working libraries. But one library should have 8.9GB according to the library overview, but every file is 0 Bytes.

When trying to repair/export the Files the seaf-fsck tool delivers the following error messages:

[2025-05-26 11:13:11] [WARNING] Failed to inflate.
[2025-05-26 11:13:11] [WARNING] ../../common/fs-mgr.c(2877): Failed to decompress fs object e2201da8e4d3f035585353970185a21c6f96a415.

(a lot of these, i guess one per file)

[2025-05-26 11:13:11] [WARNING] fsck.c(1054): No available commits for repo 6647195d, export failed.

At the end.

Anything i can do here? I have tried to search for the “objects”, but did not find anything.

Thanks!

Hey guys,

any idea on this? Got several libraries with this issue, would like to recover my files as those are pretty old files i don’t have a backup from.

I suggest you check the history of the library and click into some snapshots. And check if there are some snapshots with files that not corrupted.

No luck, @daniel.pan :frowning:

Also every file 0 byte. Uploaded those files 10-15 years ago (that’s how long i am using Seafile, basicly from day 1 on) and never changed anything. Any other idea or trick i can try?

Can you check the block objects for these libraries on the disk? Are they all 0 bytes?

You can find more information at Data Model - Seafile Admin Manual

Do you have a backup?

Hello @daniel.pan - sorry for the late response. Actually there are no 0 byte files at all, these are the smallest file in my /blocks/ folder:

-rw-rw-r-- 2 root root 1 Dec 17 2012 ./ad/c83b19e793491b1c6ea0fd8b46cd9f32e592fc
-rw-rw-r-- 2 root root 1 Dec 17 2012 ./bf/8b4530d8d246dd74ac53a13471bba17941dff7
-rw-rw-r-- 2 root root 1 Dec 17 2012 ./c4/ea21bb365bbeeaf5f2c654883e56d11e43c44e
-rw-rw-r-- 2 root root 2 Dec 17 2012 ./b6/abd567fa79cbe0196d093a067271361dc6ca8b
-rw-rw-r-- 2 root root 2 May 15 2013 ./d8/456c6820fd89df552aa7e19b1b2b4337eeab87
-rw-rw-r-- 2 root root 3 Dec 17 2012 ./33/51d58b1d3bf73122c431502fc94a77abba1edc
-rw-rw-r-- 2 root root 3 Dec 17 2012 ./77/ce5f28aca6c1d3d0506f4124c446009ba65f16
-rw-rw-r-- 2 root root 3 Mar 26 2013 ./47/8330af84ea74932db60e35533215de649a06c4
-rw-rw-r-- 2 root root 3 Mar 26 2013 ./c7/e80dc713c241193f886165d0c126d4e5bd4fd5
-rw-rw-r-- 2 root root 4 Apr 5 2013 ./66/519ee0e5d7b33e7f681edfc5adcf05a3a1f2ef
-rw-rw-r-- 2 root root 4 Apr 5 2013 ./6e/231665daf32cb324835c1c436c8d839a82ef10
-rw-rw-r-- 2 root root 4 Apr 5 2013 ./e6/c165fed82750c95837aa5c8b3932e36f3d9b9f

No I don’t have a backup, actually I used the Seafile as long term storage…..

Hello @Bucklew ,

Files showing a size of 0 bytes on the server are usually caused by running fsck with the -r option to repair them. In this case, fsck resets corrupted files to 0-byte files but does not change the size of the library itself. You can check whether fsck was used for repairs.

File corruption is typically caused by missing blocks or a damaged fs object associated with the file. Based on your earlier fsck output, it appears that the file’s fs object was corrupted and the file was then repaired to a 0-byte file using fsck -r.

In this situation, if you have not run GC, you may be able to check historical snapshots from before the fsck repair to see whether there is a usable version of the file that can be restored.