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.
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?
All machines run Arch Linux, fully up-to-date. The working client is version 6.1.4. The non-working clients are 6.1.6. Unfortunately the AUR doesn’t seem to retain old versions, so I can’t easily try 6.1.4 on the non-working machines. Server is 6.2.5 but I’d be very surprised if it’s a server issue.
I’ve tried a whole bunch of things - uninstalling/reinstalling the client, deleting my config and .seafile-data, disabling 2FA… all to no avail. The logs aren’t useful; they just say the same thing (“Failed to add download task: Argument can’t be NULL”).
I’m a software engineer / devops kind of person so I’m happy to try anything (except hacking the code, my C is super rusty).
I’m running 6.1.6 client and have no issues with any of my libraries. I’m on Debian behind NGinx. We went through the code and found that the error is thrown by the rpc shell script in Seafile Server. It happens when all the arguments passed are non-existent. Now, whether the client is not sending it, or there is a version mismatch somewhere, we have not yet identified.
Yeah there’s gotta be something different. I was able to install 6.1.4 on a machine on which Seafile never worked, and interestingly, the problem persists, so it doesn’t seem like the issue is only present in specific versions.
I compared the packages on the working vs non-working machines; there are many more packages installed on the working machine, but all the common libraries to all machines (working and not working) are on the same (most recent) versions.
I set SEAFILE_DEBUG=all, but the logs didn’t include any extra information.
I don’t think it’s necessarily a Seafile issue. There could be a corrupt file, a wrong version, or even a permissions problem with something. As quickly as it happens, almost instantaneously, something is not passing the arguments from the clients to the server. Unfortunately, I don’t know enough about how the client interacts with the server and the dependencies the information runs through in order to give an objective answer. I got to thinking about the django logs, but I doubt that would have anything to do with it. You may want to check that log.
The server logs are not helpful in this case; I guess the client doesn’t get far enough for much to show on the server. Anyway since one client works fine, it doesn’t seem likely that it’s a server issue.
Even if the root cause is not Seafile itself, Seafile’s entirely unhelpful error message makes diagnosing this problem pretty much impossible.
Update:
I ended up installing every single package that is present on the working client to a not-working client; cleared out Seafile configs and reinstalled the client, but unfortunately I still get the same message.
It won’t hurt to open it as a bug, but this morning I updated to 6.2.5 from 6.2.4. I don’t have the issue. I have clients using 6.0.X and two or three using 6.1.6, on Win 7, Win 8, and Win 10, and it’s working fine on all of them. I am on Debian 9 with NGinx. Also, remember that when I tried it on your server, I got the same error you did on one of my clients, and that client is working fine with my setup. That client was 6.1.6, btw.
I wish I knew more about what happens between the client and the server, and the processes that communicate between the two, but I don’t.
