Possibly a named_pipe error in seaf-cli

I have been getting errors while trying to set up a VM that syncs files with seafile-cli for a project. I have simplified the steps to reproduce the error a lot from what the actual project is, but hopefully this will help with troubleshooting.

Starting with a new VM with a minimal Debian 13 installation:

  • Install AppImage dependencies: apt install fuse libfuse2t64
  • Download the latest seafile-cli appImage client (version 9.0.15), from https://s3.eu-central-1.amazonaws.com/download.seadrive.org/Seafile-cli-x86_64-9.0.15.AppImage
  • Copy that to /usr/local/bin/seaf-cli.
  • Make that executable: chmod +x /usr/local/bin/seaf-cli
  • As a normal user, create directory for seafile client’s files: mkdir ~/seafile-client
  • Init the client: /usr/local/bin/seaf-cli init -d ~/seafile-client
  • Download library: /usr/local/bin/seaf-cli download -l ‘4f94f85a-e9e9-4806-b61d-67b447629aae’ -s https://my.seafile.server.com -d ~/shared -u my_account_email -p the_user_password

This gives a long error:

Starting to download ...
Library 4f94f85a-e9e9-4806-b61d-67b447629aae will be downloaded to /home/user/shared
Traceback (most recent call last):
  File "/tmp/.mount_seaf-ccHN2Oi/usr/lib/python3.9/site-packages/pysearpc/named_pipe.py", line 85, in _get_transport
    transport = self._pool.get(False)
  File "/usr/lib/python3.13/queue.py", line 199, in get
    raise Empty
_queue.Empty

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/tmp/.mount_seaf-ccHN2Oi/usr/bin/seaf-cli", line 1052, in <module>
    main()
    ~~~~^^
  File "/tmp/.mount_seaf-ccHN2Oi/usr/bin/seaf-cli", line 1048, in main
    args.func(args)
    ~~~~~~~~~^^^^^^
  File "/tmp/.mount_seaf-ccHN2Oi/usr/bin/seaf-cli", line 601, in seaf_download
    seafile_rpc.download(repo,
    ~~~~~~~~~~~~~~~~~~~~^^^^^^
                         version,
                         ^^^^^^^^
    ...<3 lines>...
                         repo_passwd, magic,
                         ^^^^^^^^^^^^^^^^^^^
                         email, random_key, enc_version, more_info)
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/.mount_seaf-ccHN2Oi/usr/lib/python3.9/site-packages/pysearpc/client.py", line 125, in newfunc
    ret_str = self.call_remote_func_sync(fcall_str)
  File "/tmp/.mount_seaf-ccHN2Oi/usr/lib/python3.9/site-packages/pysearpc/named_pipe.py", line 97, in call_remote_func_sync
    transport = self._get_transport()
  File "/tmp/.mount_seaf-ccHN2Oi/usr/lib/python3.9/site-packages/pysearpc/named_pipe.py", line 87, in _get_transport
    transport = self._create_transport()
  File "/tmp/.mount_seaf-ccHN2Oi/usr/lib/python3.9/site-packages/pysearpc/named_pipe.py", line 80, in _create_transport
    transport.connect()
    ~~~~~~~~~~~~~~~~~^^
  File "/tmp/.mount_seaf-ccHN2Oi/usr/lib/python3.9/site-packages/pysearpc/named_pipe.py", line 44, in connect
    self.pipe.connect(self.socket_path)
    ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory

This same error also happens with seaf-cli status. I’m not a good python developer, but it looks like some bug is keeping it from making a socket, or named-pipe.

I have a similar VM already set up and working with this same version of seaf-cli. The only differences I can think of between these VMs are:

  • The new VM is using a new seafile user I just created
  • They are trying to use different libraries (but downloading them the same way, just different UUID, email address, and password in the command line)
  • And the old one was already working before I upgraded the server to version 13, and is still working now.

I haven’t messed with the working VM much because I need it to keep working, but I can deploy new VMs for testing pretty easily.

I figured it out. That error just means that seaf-cli start didn’t work. I had that scripted, and a bug caused the script to claim that it had started when it actually had not. It would be nice if instead of a screen full of vague errors it would instead say something like “Cannot communicate with seaf-cli daemon, did you run seaf-cli start?”

The other problem was that “seaf-cli start” was failing because it depends on libgpg-error0. That library apparently isn’t included in the AppImage with the other libraries, and it isn’t mentioned in the documentation anywhere I can find. Once I installed libgpg-error0 it all started working again.

We’ll look into the issue.

Hello @tomservo

We tested running seaf-cli on Debian 13 but did not encounter the missing libgpg-error0 issue, so it should only be a problem with your current system.

Before running seaf-cli start, performing other operations will result in errors related to named pipe, because the client is not actually started yet. Therefore, such errors are expected. We will consider adding a check for whether the daemon is running, so that users can be reminded to execute start.

To clarify, I tried a debian netinstall disk with only the “SSH Server” and “standard system utilities” selected. I also checked the proxmox debian 13 LXC template. Neither have libgpg-error0 installed already and needed it to be manually installed before seaf-cli start would work.

I don’t think it’s a big deal. If I hadn’t screwed up the script I made for setting up the system it would only have taken minutes to get it all running. Sorry to have wasted your time.

I also face in this error… Just wanting to sync my scanner samba folder with my scanner library… On my old server it worked perfectly…

I use Debian 13