Single account corrupted - how to fix it?

Hello,

I have been using Seafile Server v6.02 on a physically existing Windows Server 2016 for several years now very successfully. There are about 15 different users.

Yesterday evening I was able to synchronize various files from a laptop to the server without any problems and there was no error message. When I got up this morning I noticed that the server was switched off. We’re supposed to have had a power cut. I restarted the server and also all virtual machines on it did not cause any problems during re-initialization. But when the Seafile Client v6.1.8 tried to connect to user XXX, the client only displayed the very informative message “Error” on different computers. After that I made a connection via the Seafile web interface and got the message “Error”. When I logged on to the web interface under a different user name, however, I was able to access their libraries without any problems. I can also regularly access other users’ libraries using the Seafile Client.

From these observations I conclude that only the account of user XXX probably did not survive the hard reset due to the power failure last night.

In the Seafile.log file of user XXX there is no helpful information what exactly the error is. Here are the last entries (see end of message) between the time I was able to use the account yesterday evening without any problems and this morning, since I only get the error message.

Question: What can I do to repair this corrupted account from user XXX? Are there any tools like checkdisk to repair a malfunctioning user account? I still have a two day old backup of my entire seafile-server folder, which is 180 GB in size.

hoping for quick help,

Hannes

[07/02/18 22:30:24] sync-mgr.c(739): Repo ‘Scans’ sync state transition from ‘downloading’ to ‘synchronized’.
[07/02/18 22:30:26] sync-mgr.c(739): Repo ‘Scans’ sync state transition from ‘synchronized’ to ‘committing’.
[07/02/18 22:30:26] repo-mgr.c(3741): All events are processed for repo 3ef898ca-4000-43d6-b17c-aa195a754f91.
[07/02/18 22:30:26] sync-mgr.c(739): Repo ‘Scans’ sync state transition from ‘committing’ to ‘synchronized’.
[07/02/18 22:30:57] [07/02/18 22:30:57] sync-mgr.c(739): Repo ‘Scans’ sync state transition from ‘initializing’ to ‘downloading’.
http-tx-mgr.c(1153): Transfer repo ‘3ef898ca’: (‘normal’, ‘init’) --> (‘normal’, ‘check’)
[07/02/18 22:30:58] http-tx-mgr.c(1153): Transfer repo ‘3ef898ca’: (‘normal’, ‘check’) --> (‘normal’, ‘commit’)
[07/02/18 22:30:58] http-tx-mgr.c(1153): Transfer repo ‘3ef898ca’: (‘normal’, ‘commit’) --> (‘normal’, ‘fs’)
[07/02/18 22:30:58] http-tx-mgr.c(1153): Transfer repo ‘3ef898ca’: (‘normal’, ‘fs’) --> (‘normal’, ‘data’)
[07/02/18 22:31:10] http-tx-mgr.c(1153): Transfer repo ‘3ef898ca’: (‘normal’, ‘data’) --> (‘finished’, ‘finished’)
[07/02/18 22:31:10] sync-mgr.c(739): Repo ‘Scans’ sync state transition from ‘downloading’ to ‘synchronized’.
[07/02/18 22:31:12] sync-mgr.c(739): Repo ‘Scans’ sync state transition from ‘synchronized’ to ‘committing’.
[07/02/18 22:31:12] repo-mgr.c(3741): All events are processed for repo 3ef898ca-4000-43d6-b17c-aa195a754f91.
[07/02/18 22:31:12] sync-mgr.c(739): Repo ‘Scans’ sync state transition from ‘committing’ to ‘synchronized’.
[07/02/18 22:31:43] sync-mgr.c(1553): Removing blocks for repo Scans(3ef898ca).
[07/03/18 07:36:31] seaf-daemon.c(558): starting seafile client 6.1.8
[07/03/18 07:36:31] seaf-daemon.c(560): seafile source code version 529172aa2ee41794299bc22289b555d391cf0beb
[07/03/18 07:36:31] …/common/mq-mgr.c(60): [mq client] mq cilent is started
[07/03/18 07:36:31] …/common/mq-mgr.c(106): [mq mgr] publish to heartbeat mq: seafile.heartbeat
[07/03/18 07:36:40] http-tx-mgr.c(1257): Bad response code for GET http://hanneshar.ddnss.de:8000/seafhttp/protocol-version: 404.
[07/03/18 07:36:40] sync-mgr.c(2236): File syncing protocol version on server http://hanneshar.ddnss.de:8082 is 1. Client file syncing protocol version is 2. Use version 1.
[07/03/18 07:36:40] sync-mgr.c(739): Repo ‘Bilder vom Handy’ sync state transition from ‘synchronized’ to ‘committing’.
[07/03/18 07:36:40] repo-mgr.c(3741): All events are processed for repo fbb05198-40c1-4708-9f2b-e413a4957081.
[07/03/18 07:36:40] sync-mgr.c(739): Repo ‘Bilder vom Handy’ sync state transition from ‘committing’ to ‘initializing’.
[07/03/18 07:36:41] sync-mgr.c(739): Repo ‘Scans’ sync state transition from ‘synchronized’ to ‘committing’.
[07/03/18 07:36:42] repo-mgr.c(3741): All events are processed for repo 3ef898ca-4000-43d6-b17c-aa195a754f91.
[07/03/18 07:36:42] sync-mgr.c(739): Repo ‘Scans’ sync state transition from ‘committing’ to ‘uploading’.
[07/03/18 07:36:42] http-tx-mgr.c(1153): Transfer repo ‘3ef898ca’: (‘normal’, ‘init’) --> (‘normal’, ‘check’)
[07/03/18 07:36:42] sync-mgr.c(739): Repo ‘eBooks’ sync state transition from ‘synchronized’ to ‘committing’.
[07/03/18 07:36:42] http-tx-mgr.c(1153): Transfer repo ‘3ef898ca’: (‘normal’, ‘check’) --> (‘normal’, ‘commit’)
[07/03/18 07:36:42] http-tx-mgr.c(1153): Transfer repo ‘3ef898ca’: (‘normal’, ‘commit’) --> (‘normal’, ‘fs’)
[07/03/18 07:36:43] http-tx-mgr.c(1153): Transfer repo ‘3ef898ca’: (‘normal’, ‘fs’) --> (‘normal’, ‘data’)
[07/03/18 07:36:43] repo-mgr.c(3741): All events are processed for repo 4599e78c-570e-4ee9-ba41-4128ff221afc.
[07/03/18 07:36:43] sync-mgr.c(739): Repo ‘eBooks’ sync state transition from ‘committing’ to ‘initializing’.
[07/03/18 07:36:43] http-tx-mgr.c(1153): Transfer repo ‘3ef898ca’: (‘normal’, ‘data’) --> (‘normal’, ‘update-branch’)
[07/03/18 07:36:43] http-tx-mgr.c(1153): Transfer repo ‘3ef898ca’: (‘normal’, ‘update-branch’) --> (‘finished’, ‘finished’)
[07/03/18 07:36:43] sync-mgr.c(739): Repo ‘Scans’ sync state transition from ‘uploading’ to ‘initializing’.
[07/03/18 07:36:43] sync-mgr.c(1553): Removing blocks for repo Scans(3ef898ca).
[07/03/18 07:36:43] sync-mgr.c(739): Repo ‘Meine Bibliothek’ sync state transition from ‘synchronized’ to ‘committing’.
[07/03/18 07:36:43] repo-mgr.c(3741): All events are processed for repo bc83f5eb-5269-45b9-bbcf-62d072b212ce.
[07/03/18 07:36:43] sync-mgr.c(739): Repo ‘Meine Bibliothek’ sync state transition from ‘committing’ to ‘initializing’.
[07/03/18 07:36:44] sync-mgr.c(739): Repo ‘CD Kataloge’ sync state transition from ‘synchronized’ to ‘committing’.
[07/03/18 07:36:44] repo-mgr.c(3741): All events are processed for repo cff06c4d-5cb7-409c-80d4-ddb701d9f4a2.
[07/03/18 07:36:44] sync-mgr.c(739): Repo ‘CD Kataloge’ sync state transition from ‘committing’ to ‘initializing’.
[07/03/18 07:36:45] sync-mgr.c(739): Repo ‘Hartmann on Adamo’ sync state transition from ‘synchronized’ to ‘committing’.
[07/03/18 07:36:49] repo-mgr.c(3741): All events are processed for repo f58cd0d9-03e1-4745-9a36-1e05ee0247e5.
[07/03/18 07:36:49] sync-mgr.c(739): Repo ‘Hartmann on Adamo’ sync state transition from ‘committing’ to ‘initializing’.
[07/03/18 07:48:15] sync-mgr.c(739): Repo ‘Scans’ sync state transition from ‘synchronized’ to ‘committing’.
[07/03/18 07:48:15] repo-mgr.c(3741): All events are processed for repo 3ef898ca-4000-43d6-b17c-aa195a754f91.
[07/03/18 07:48:15] sync-mgr.c(739): Repo ‘Scans’ sync state transition from ‘committing’ to ‘uploading’.
[07/03/18 07:48:15] http-tx-mgr.c(1153): Transfer repo ‘3ef898ca’: (‘normal’, ‘init’) --> (‘normal’, ‘check’)
[07/03/18 07:48:15] http-tx-mgr.c(1153): Transfer repo ‘3ef898ca’: (‘normal’, ‘check’) --> (‘normal’, ‘commit’)
[07/03/18 07:48:15] http-tx-mgr.c(1153): Transfer repo ‘3ef898ca’: (‘normal’, ‘commit’) --> (‘normal’, ‘fs’)
[07/03/18 07:48:15] http-tx-mgr.c(1153): Transfer repo ‘3ef898ca’: (‘normal’, ‘fs’) --> (‘normal’, ‘data’)
[07/03/18 07:48:15] http-tx-mgr.c(1153): Transfer repo ‘3ef898ca’: (‘normal’, ‘data’) --> (‘normal’, ‘update-branch’)
[07/03/18 07:48:15] http-tx-mgr.c(1153): Transfer repo ‘3ef898ca’: (‘normal’, ‘update-branch’) --> (‘finished’, ‘finished’)
[07/03/18 07:48:15] sync-mgr.c(739): Repo ‘Scans’ sync state transition from ‘uploading’ to ‘initializing’.

Update: unfortunately I had written my error description too fast. Now I had to realize that the user XXX cannot actually see his libraries in the Seafile Client or via the Seafile web interface after the hard crash last night, but that in fact the Seafile Client is still able to synchronize files on different computers.

So the error “only” seems to include the presentation of the libraries of user XXX. But also here the question: how can I get the user XXX to see his libraries again?

Hannes

Update 2: from another PC I tried to access the account of user XXX using SeaDrive v0.9.3. SeaDrive also can’t open files from user XXX’s account. So once again summarized the status of the errors of user XXX:

Seafile client:

  • Synchronization works
  • Libraries are not displayed in the main window
  • no access to libraries via the file browser

SeaDrive:

  • no access to libraries
  • no access to files

Seafile web interface:

  • Libraries are not displayed
  • Entries from the Wiki can be retrieved.

All other users have regular access to all resources without any error message or restriction. Accordingly, it can be assumed that something in the configuration of user XXX was damaged by the crash last night.

The simplest solution would be to simply delete user XXX and then synchronize all existing files again. Unfortunately, there is a library of which I have no backup and which has quite valuable files in it. Unfortunately I have not synchronized this library anywhere on another computer on a hard disk and can only access the content via the web interface, SeaDrive or the file browser from the Seafile client. Accordingly, I am still very interested in getting the account of user XXX back to a regular, functional state. Anybody have an idea here?

Hannes

Have you tried running seaf-fsck: https://manual.seafile.com/maintain/seafile_fsck.html

Great, thank you for the advice. Looks like that’s exactly the tool I’m looking for.

Now the only question for me is how to use it under Windows (and not under Linux). In the instructions you mentioned, a reference is made to the file seaf-fsck.sh. Under Windows I only find the file seaf-fsck.exe and assume that this program does the same job. If I start it in the Seafile Server folder without specifying any parameters, I get the error message:

[07/03/18 12:31:28] seafile-session.c(42): Config dir dir C:\Users\Administrator/ccnet\seafile-data does not exist
[07/03/18 12:31:28] seaf-fsck.c(163): Failed to create seafile session.

So seaf-fsck.exe obviously is missing the path where the seafile database is located. When I start seaf-fsck.exe -? the following parameters are presented to me for configuration:

seaf-fsck.exe: unknown option --?
usage: seaf-fsck[-r][-E exported_path] [-c config_dir] [-d seafile_dir] [repo_id_1[repo_id_2 …]]

But am I as smart as before - which parameters do I use to localize the Seafile database? My Seafile database is located in this folder:

c:\HDexpander3\seafile-server\

There I see the following entries:

2018-07-03 12:39 .
2018-07-03 12:39 …
11/10/2016 22:58 ccnet
04/11/2017 16:09 conf
11/10/2016 22:58 logs
2018-07-03 12:01 seafile-data
03.07.2018 12:39 445.440 seahub.db
03.07.2018 07:35 6 seahub.pid
2018-07-03 12:40 seahub_cache

The program code of the Seafile Server is located in this folder:

c:\Program Files (x86)\TCPIP\Tools\SeafileProgram\seafile-server-6.0.7\

Unfortunately, I can’t find a description online how to use seaf-fsck.exe under Windows - even if only plan to check the integrity of the Seafile database. Can anyone help me here?

Hannes

This is the one for windows: https://manual.seafile.com/deploy_windows/windows_fsck.html

Thank you for your spontaneous help. Unfortunately, I could not repair the Seafile database with the instructions for using seaf-fsck.exe. Fortunately, I had made a full backup of the database just two days earlier. With this backup I restored the Seafile database and let the Seafile clients synchronize the updates. This resulted in (as expected) some inconsistencies, which I quickly got repaired with regard to my own files. Unfortunately I don’t know if other users changed any files in this lost time window of two days using the Seafile web interface. These changes may have been lost when the backup was restored. At least so far, no one has complained. Probably I should not create weekly backups of the Seafile database in the future, but do this on a daily basis.

Thank you again for your constructive help,

Hannes

1 Like

Today I faced the same problem - one of the users complained about the fact that he did not have access to the library. Seafile 6.0.7 for windows.
At the moment I’m trying to solve this problem.

how to prevent this ?

also do i need to backup all files ? including user-generated files like pictures, etc, to be safe from corrupption like this?

Well corruption of files is nothing specific to Seafile, anything on a hard drive can be corrupted.

Backup is the first to do obviously, if data is crytical backup should be incremental and very frequent.

Another thing serious companies do against corruptions is to have a professional solutions that have correction algorithms. There are also many “simple” solutions without expensive enterprise hardware:

  • btrfs or ZFS on linux (i use btrfs in RAID 1 configuration)
  • ReFS on Windows