Error when trying to sync libraries: 'Argument can't be NULL'

Hi there!

I am using seafile for some time now and all of a sudden I can’t sync libraries any more. I can’t exactly say when it happened and I did upgrades in the meantime and also reconfigured seafile to run behind nginx :frowning:

Well, all goes well except for syncing of libraries. When trying to set up sync for a library I get the error message ‘Argument can’t be null’. I search the internet and this forum but there were no conclusive answers.

The logs do not say anything at all. The only thing that happens when trying to sync a library is this log entry in nginx access-log:

...ip... - - [14/Mar/2018:20:34:19 +0100] "GET /api2/repos/...hash.../download-info/ HTTP/1.1" 200 642 "-" "Mozilla/5.0"

Any ideas how to find the error? Here’s my configuration:




# Set maximum upload file size to 4G.

# Set maximum download directory size to 4G.

# bind address for fileserver
# default to, if deployed without proxy: no access restriction
# set to, if used with local proxy: only access by local
host =


ID = ...
NAME = ...

PORT = 10001

PORT = 13418

nginx config

server {
    listen ...:80;
    server_name ...name1...
    rewrite ^ https://$http_host$request_uri? permanent;    # force redirect http to https
    server_tokens off;

server {
    listen ...ip...:443 http2;
    server_name ...name1...

    ssl on;
    ssl_certificate /etc/letsencrypt/live/.../fullchain.pem;     # path to your cacert.pem
    ssl_certificate_key  /etc/letsencrypt/live/.../privkey.pem;  # path to your privkey.pem
    ssl_session_timeout 5m;
    ssl_session_cache shared:SSL:5m;

    # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
    ssl_dhparam /etc/nginx/dhparam.pem;

    # secure settings (A+ at SSL Labs ssltest at time of writing)
    # see
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;

    proxy_set_header X-Forwarded-For $remote_addr;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
    server_tokens off;

    location / {
         proxy_set_header   Host $host;
         proxy_set_header   X-Real-IP $remote_addr;
         proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header   X-Forwarded-Host $server_name;
         proxy_set_header   X-Forwarded-Proto https;
         proxy_read_timeout  1200s;

         # used for view/edit office file via Office Online Server
         client_max_body_size 0;

         access_log      /var/log/nginx/seahub.access.log;
         error_log       /var/log/nginx/seahub.error.log;

    location /seafhttp {
        rewrite ^/seafhttp(.*)$ $1 break;
        client_max_body_size 0;

        proxy_connect_timeout  36000s;
        proxy_read_timeout  36000s;
        proxy_send_timeout  36000s;

        send_timeout  36000s;
        proxy_request_buffering off;
    location /media {
        root /.../seafile/seafile-server-latest/seahub;

Edit: Deleted ‘http2’ from server config for port 80 to reflect current settings.

What throws the error message? The Seafile client?

Yeah, sorry, I thought it was obvious but obviously it wasn’t. :wink:

What version of the client and the server are you running? Do you have a firewall in the mix somewhere?

Just had a thought… What happens when you try to create a new library? IE, you create a new and blank folder on your computer, and then go into Seafile client and then click “Select or Folder to Sync” button?

The latest, i.e. Client 6.1.6 and also 6.0.7 on Win10 and Win7; Server 6.2.5 64bit

There is a hardware firewall but all ports should be open (deactivated for this ip).

The same :frowning:

What’s possibly notable to mention:
The machine has two IP addresses, only one of them is used for seafile. Two DNS hostnames resolve to this ip address and seafile is configured for both of them. The https-certificate contains both hostnames. The problem exists when using either of the hostnames.

Here’s what nmap shows from the outside world:

80/tcp    open  http?
222/tcp   open  ssh         (protocol 2.0)
443/tcp   open  http        nginx
|_http-methods: No Allow or Public header in OPTIONS response (status code 400)
|_http-title: 400 The plain HTTP request was sent to HTTPS port
8000/tcp  open  http-alt?
|_http-methods: No Allow or Public header in OPTIONS response (status code 302)
| http-robots.txt: 1 disallowed entry 
|_http-title: Requested resource was http://...hostname...:8000/accounts/login?next=/ and no page was returned.
|_http-open-proxy: Proxy might be redirecting requests
10001/tcp open  scp-config?

This is what sudo netstat -tulpen gives me on the server side (I left out things running on the other IP address):

Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode       PID/Program name
tcp        0      0*               LISTEN      102        2530717     22576/mysqld
tcp        0      0 *               LISTEN      0          2530821     806/sendmail: MTA:
tcp        0      0 .......ip.....:80*               LISTEN      0          70840       7157/nginx -g daemo
tcp        0      0 *               LISTEN      1000       6132452     29246/ccnet-server
tcp        0      0*               LISTEN      1000       6132472     29249/seaf-server
tcp        0      0  *               LISTEN      0          2530820     806/sendmail: MTA:
tcp        0      0 .......ip.....:443*               LISTEN      0          70841       7157/nginx -g daemo
tcp        0      0   *               LISTEN      0          872416      25587/sshd
tcp        0      0  *               LISTEN      1000       6132637     29280/python2.7
tcp        0      0 *               LISTEN      1000       6132468     29249/seaf-server
tcp6       0      0 :::222                  :::*                    LISTEN      0          872418      25587/sshd
udp        0      0 .......ip.....:123*                           0          2972353     21972/ntpd
udp        0      0 *                           0          2972349     21972/ntpd
udp        0      0   *                           0          2972345     21972/ntpd
udp6       0      0 ............ip6........ :::*                                0          2972357     21972/ntpd
udp6       0      0 ::1:123                 :::*                                0          2972355     21972/ntpd
udp6       0      0 :::123                  :::*                                0          2972342     21972/ntpd

Although you see mysql here I don’t use it for seafile. Seafile currently runs on sqlite.

I also had a look at the logs of seafile client.

I also set the system wide variable SEAFILE_DEBUG to get a more verbose log and restarted the client like described here:

To see if the variable is set I testet it in a command line:

The log of seafile client reveals NOTHING except the startup of seafile:

[03/16/18 17:01:59] seaf-daemon.c(558): starting seafile client 6.1.6
[03/16/18 17:01:59] seaf-daemon.c(560): seafile source code version 48addfe8ae85ae816978db00e6402a30d3f964fe
[03/16/18 17:01:59] ../common/mq-mgr.c(60): [mq client] mq cilent is started
[03/16/18 17:01:59] ../common/mq-mgr.c(106): [mq mgr] publish to heartbeat mq: seafile.heartbeat
[03/16/18 17:01:59] wt-monitor(361): Done: add_all_to_iocp

Should there be more log entries with verbose logging? Why can’t I see them?

I’m afraid I was wrong. The (empty) library is being created and shown in the client and also in the web interface. The client however states that the library has never been downloaded (or uploaded in this case). Sync is not set up either. So creating a library works but setting up sync during the process fails.

I did another test: I added a file via seafile file browser (or whatever it’s called in English; I mean the file browser integrated into the sync client) and it worked fine. Also downloading from the file browser works fine.

Based on your last comment, I’m thinking it has something to do with port 8082, which handles file transfers, if I’m not mistaken. I’m also going to assume that this started when you upgraded from an earlier version of Seafile Server, prior to 6.2.X. I have an ongoing issue with the webui in 6.2.X not working on an alternate port, but it’s a little different than your problem. So, if the library does get created but not synced, I’m thinking it’s got to do with port 8082.

Try this… Log into the webui and try to manually upload a file into the new library from there. Does that work or give you an error?

Oh and one other thing… There are two other logs for the client… ccnet.log and applet.log. In your particular case, the ccnet log would probably be the one where the error would be logged. The applet log may reveal some info too.

You have a misstake at the part with the redirection. You can’t use http/2 without TLS. Maybe browsers can handle with it, but it seems the api doesn’t.

This works fine. Downloading and uploading via Seafile File Browser and any browser to/from any library work fine.

ccnet.log shows nothing relevant (‘local peer down’ is all over the log, even from other years where everything worked fine).

[03/16/18 17:01:58] ccnet-daemon.c(193): starting ccnet client 6.1.6
[03/16/18 17:01:58] ccnet-daemon.c(195): ccnet source code version     
[03/16/18 17:01:58] ../common/session.c(132): using config file C:/Users/...user.../ccnet\ccnet.conf
[03/16/18 17:01:58] ../common/session.c(418): Listen on 13419
[03/16/18 17:01:58] ../common/session.c(290): Update pubinfo file
[03/16/18 17:01:59] ../common/session.c(398): Accepted a local client
[03/16/18 17:01:59] ../common/session.c(398): Accepted a local client
[03/16/18 17:01:59] ../common/session.c(398): Accepted a local client
[03/16/18 17:01:59] ../common/session.c(398): Accepted a local client
[03/16/18 17:02:00] ../common/session.c(398): Accepted a local client
[03/16/18 17:02:00] ../common/session.c(398): Accepted a local client
[03/16/18 17:02:00] ../common/peer.c(943): Local peer down
[03/16/18 17:02:00] ../common/peer.c(943): Local peer down
[03/16/18 17:02:00] ../common/session.c(398): Accepted a local client
[03/16/18 17:02:00] ../common/session.c(398): Accepted a local client
[03/16/18 17:02:00] ../common/session.c(398): Accepted a local client
[03/16/18 17:02:02] ../common/session.c(398): Accepted a local client
[03/16/18 17:02:02] ../common/session.c(398): Accepted a local client
[03/16/18 17:02:02] ../common/session.c(398): Accepted a local client
[03/16/18 17:02:02] ../common/session.c(398): Accepted a local client

applet.log has this to say:

[03/16/18 17:01:58]QObject::connect: No such slot AccountManager::reloginAccount(const Account &)
[03/16/18 17:01:58]starting ccnet:  ("-c", "C:/Users/...user.../ccnet")
[03/16/18 17:01:59]trying to connect to ccnet daemon...
[03/16/18 17:01:59]connected to ccnet daemon
[03/16/18 17:01:59]starting seaf-daemon:  ("-c", "C:/Users/...user.../ccnet", "-d", "E:/Temp/Seafile/seafile-data", "-w", "E:/Temp/Seafile")
[03/16/18 17:02:00][Rpc Client] connected to daemon
[03/16/18 17:02:00][Rpc Client] connected to daemon
[03/16/18 17:02:00][MessageListener] connected to daemon
[03/16/18 17:02:02]Starting the network status detector
[03/16/18 17:02:02][Rpc Client] connected to daemon
[03/16/18 17:02:02][Rpc Client] connected to daemon
[03/16/18 17:02:49]Download konnte nicht eingerichtet werden:
Argument can't be NULL

You are right, I edited nginx config, 2nd line, to listen ...:80; and restarted nginx. Makes no difference.

BTW: Thank you all so much for your help. I really appreciate it. I hope we can pinpoint the problem.

I’m still looking into this. I understand the error, but since it does not specify which argument is not being passed, I flying in the dark. However, I did find this post from last year:

Would it be possible for you to try installing the client on a PC that has never had Seafile on it before and trying it? I’m beginning to wonder if it doesn’t have something to do with the updates you did. If it doesn’t or does work on a PC that has never had Seafile on it before, then that may help narrow this down some. I’m inclined to believe that it’s a server issue, https issue, or nginx, but I want to be certain.

I saw that post from last year, too. The solution back then was to reinstall everything. :wink:

I Installed the client on a computer yesterday that never had the seafile client installed before because I wanted to make sure that it wasn’t something with the computer/client. Same behaviour. :frowning:

@wthess Would it help if I gave you an account on my seafile to be able to test things? If so, how can I give you the login credentials?

Hmmmm… Nearly all my computers have Seafile on them… I think I may have an old laptop around here somewhere that I can use. You’ll just need to create me an account and password on your server, and then give me the domain name to use. I will PM you so that we can exchange information.

Did you guys get any further with this issue? I’m experiencing the same problem on two new computers, client version 6.1.6 (and at least one or two earlier versions as well). A client with an older install is still working fine. And the machines with the non-working client can use the web interface and “open cloud file browser” works just fine - they just can’t sync.

Hi, unfortunately we did not find an answer or even some more clues. We cleaned up the configuration and things but nothing popped up. I went a little through the code and the error message seems to come from here: seafile-server/common/rpc-service.c, lines 308 or more likely 359. It would surely help to know which of the arguments (token, peer_addr, peer_port or email) is NULL. @wthess guessed it is the token.

This is very interesting! Can you tell me more about that client that’s working fine? Which client version exactly is it? On what operating system and which detailed version? (E.g. for Windows type winver at a command prompt.) Maybe also have a look at the versions and operating system versions where the client is working.

Argument can’t be NULL messages are commonalities in the programming world. They are usually due to using outdated libraries and/or programs. For example, if a program expects a certain library file to be version 3.2 and 2.4 is installed, you could get this error message. It’s usually a matter of tracking down which of your dependencies is the wrong version.

As an example, the first time I tried installing Seafile on a Linux distro, it wouldn’t work. That was years ago, so I don’t remember the error I got. But, what happened was a newer version of Python was installed on the server. I had to go out and grab the proper version of Python and it started working.

If an older version is working for you, then there is a dependency problem somewhere, most likely a version mismatch of a dependency library.