Seafile-cli stopped working after installing updates

Hi all,

since installing updates on our Seafile linux server, seaf-cli stopped working. When you try to use the cli, the following errors are thrown:

/opt/seafile_cli/current/seaf-cli status
Traceback (most recent call last):
File “/opt/seafile_cli/seafile-cli-4.0.4/bin/”, line 791, in
File “/opt/seafile_cli/seafile-cli-4.0.4/bin/”, line 787, in main
File “/opt/seafile_cli/seafile-cli-4.0.4/bin/”, line 603, in seaf_status
tasks = seafile_rpc.get_clone_tasks()
File “/opt/seafile_cli/seafile-cli-4.0.4/lib64/python2.6/site-packages/pysearpc/”, line 110, in newfunc
ret_str = self.call_remote_func_sync(fcall_str)
File “/opt/seafile_cli/seafile-cli-4.0.4/lib64/python2.6/site-packages/ccnet/”, line 71, in call_remote_func_sync
client = self.pool.get_client()
File “/opt/seafile_cli/seafile-cli-4.0.4/lib64/python2.6/site-packages/ccnet/”, line 27, in get_client
client = self._create_client()
File “/opt/seafile_cli/seafile-cli-4.0.4/lib64/python2.6/site-packages/ccnet/”, line 19, in _create_client
File “/opt/seafile_cli/seafile-cli-4.0.4/lib64/python2.6/site-packages/ccnet/”, line 120, in connect_daemon
return self.connect_daemon_with_pipe()
File “/opt/seafile_cli/seafile-cli-4.0.4/lib64/python2.6/site-packages/ccnet/”, line 102, in connect_daemon_with_pipe
raise NetworkError(“Can’t connect to daemon”)
ccnet.errors.NetworkError: Can’t connect to daemon

The seaf-cli daemon itself can also not be started, so this might be the main reason.

I suspect the culprit to be an update to python 2.7 although it should work with that version from what I see in the scripts.

Here’s the environment:
CentOS Linux release 7.5.1804 (Core)
Seafile Server Version: 6.2.5
Seafile-cli version: 4.0.4

Any hints and tips appreciated

I encountered some funny things after upgrading to 7.5.1804. All Clients are version 4.3.2. Most of the clients stopped working just like yours. One client survived the upgrade of the CentOS without any problem. One client synced one library from one server and five libraries from a second server. That client stopped working, too. But I tried to set it up again. The first library from the first server went well, adding the first library from the second server caused the client to fail.

I upgraded almost all clients to version 6.1.6 using this repository:

The client with the two seafile servers and six libraries isn’t upgraded yet. This one uses one server and one library at the moment, all others work well with the client from pkerling.


Hi Wolle,

that sounds promising :slight_smile:

Back in the days when there was the standalone client, that we have currently installed, it was just basically extracting the archive and you were good to go.
So when you say you upgraded your clients, did you just use “yum install seafile” and that’s it? Or did you also have to adjust configuration files etc.?

Thanks in advance

I had the old client installed under /opt/Seafile/Client/... and a link in /usr/local/bin/seaf-cli, the new one installs as /usr/bin/seaf-cli. I adjusted the startup-scripts.

I think, the configuration files survived the upgrade. I’m not 100% sure because I don’t have any problem to desync and resync or restart with a clean configuration. I just needed some trials to get the stuff working again. The data at least did not reload in any direction.

I tried to manually start the seaf-cli daemon, which worked. But then all libraries that have been previously synced correctly, are now in the “waiting for sync” status.

I desynced and sycned again a library but it did not use the existing folder but created a new one. Not what I expected

OK seems to be a Layer8 problem. I didn’t use “seaf-cli sync” but “seaf-cli download”.
Now as it looks I have to bring every library of our 70+ back into sync. Hmpf

The magic words for such an accident are “Restore Backup” :wink:

If you can tell me which files to restore so that seaf-cli plays along, I will gladly do that :slight_smile:

I mean the config, created with seaf-cli init -d ~/.seafile-client or however you’ve done that. The config in this case is the stuff in ~/.seafile-client.

I just had a look at the last two seafile clients I upgraded. One was that one, which survived the CentOS upgrade, the other one did not. Both did definitely not need a desync/sync. But this does not necessarily be the same for your installation.