Syncing Client won't unpause after resources become available again


  • Windows 10
  • Server 7.1 CE & Pro latest
  • Syncing Client 7.0.10
  • Syncing Client is on autostart
  • Both “Do not automatically unsync” in the Syncing Client settings are enabled

I have two types of resources which won’t be synced directly after a system (re-)start. At the time the OS starts the Syncing Client, the resources are not yet accessible and the client sets them automatically on hold/pause. After they come available, they won’t automatically unpause. I can unpause every single library manually or restart the Syncing Client to force a (re-)check on the resources - and hence a succesful sync -, but this is not very convenient for an average user.

The resource types are

  1. A local Veracrypt container. Veracrypt is also on autostart, but the container typically opened after the Syncing Client starts.
  2. A windows network share which needs some time after the system start to become available.

The Syncing Client log at system start:

[11/09/20 17:44:54] seaf-daemon.c(504): starting seafile client 7.0.10
[11/09/20 17:44:54] seaf-daemon.c(506): seafile source code version 626f561b52a21dea80f02e7b061fe848e1596c81
[11/09/20 17:44:54] seafile-session.c(382): client id = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, client_name = SYSTEM-153
[11/09/20 17:44:54] repo-mgr.c(861): Failed to access worktree T:\Test for repo 'Test'(e52ba6a9)
[11/09/20 17:44:54] repo-mgr.c(6533): Worktree for repo "Test" is invalid, but still keep it.
[11/09/20 17:44:54] repo-mgr.c(861): Failed to access worktree //SYSTEM-100/sharetest for repo 'sharetest'(14e72564)
[11/09/20 17:44:54] repo-mgr.c(6533): Worktree for repo "sharetest" is invalid, but still keep it.
[11/09/20 17:44:54] seaf-daemon.c(531): rpc server started.
[11/09/20 17:44:55] start to serve on pipe client
[11/09/20 17:44:55] start to serve on pipe client

Is there a way that the Syncing Client rechecks the availability of the resources from time to time and automatically unpause the syncing process again?

Is this a bug or a feature request?

At the moment we just start the client manually to ensure the availability of the resources. But as you can guess, users just forget about that and then call for support when then sync magic doesn’t happen.

1 Like

It’s a behavioral change in 7.0.10 version. We’ll change back to the old behavior in 7.0.11.


Thanks for your feedback. Much appreciated.

@Jonathan Could you please release 7.0.11 or an intermediate version. It’s super annoying to manually resync all the librarys every time you reconnect the encrypted partition.

@H4m0n You can use 8.0.1 version. It should also include the fix.

1 Like


I tried the 8.0.1 seafile-client on Linux, but the behavior does not seem to be fixed. When a partition or folder get dismounted and then become available again, the client does not continue syncing the libraries. Syncing is on pause and you manually need to enable auto sync for every library again.

We haven’t officially updated the Linux version to 8.0.1. Where do you install it?

I compiled it from github on Arch Linux.

Have you also used the v8.0.1 tag from ?

1 Like

Hey, sorry for the late answer.

Indeed I forgot to also compile v8.0.1 of the seafile daemon. When using and together I can confirm that the bug is gone and seafile automatically restarts syncing the library once the folder becomes available again locally.