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
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:
Any ideas how to find the error? Here’s my configuration:
seafile.conf
[network]
port=12001
[httpserver]
host=127.0.0.1
port=8082
# Set maximum upload file size to 4G.
max_upload_size=4096
# Set maximum download directory size to 4G.
max_download_dir_size=4096
[fileserver]
# bind address for fileserver
# default to 0.0.0.0, if deployed without proxy: no access restriction
# set to 127.0.0.1, if used with local proxy: only access by local
host = 127.0.0.1
ccnet.conf
[General]
USER_NAME = ...
ID = ...
NAME = ...
[Network]
PORT = 10001
[Client]
PORT = 13418
nginx config
server {
listen ...:80;
server_name ...name1...
...name2...
...ip...
"";
rewrite ^ https://$http_host$request_uri? permanent; # force redirect http to https
server_tokens off;
}
server {
listen ...ip...:443 http2;
server_name ...name1...
...name2...
...ip...
"";
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 https://wiki.mozilla.org/Security/Server_Side_TLS#Nginx
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:HIGH:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS';
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_pass http://127.0.0.1:8000;
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;
proxy_pass http://127.0.0.1:8082;
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.
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
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:
PORT STATE SERVICE VERSION
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):
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
5b9f64c2438517e1c95b28678097419542d1d084
[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 127.0.0.1 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.
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.
@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.
