Are you saying from a working server to the non-working server? Also, did you sync seafile-data folder on the client or the server?
Sorry I wasn’t clear before - I didn’t do anything on the server. I entirely replaced the non-working client’s .seafile-data with the working client’s. But like I said, this only let me sync already-existing libraries that were copied to the new computer; the new machine still can’t sync other libraries or create new libraries.
Just because it’s working for other people doesn’t mean it’s not a bug. As software engineers, I suspect we both know this all too well.
So the problem I’m experiencing is a little different from deryo’s. Still the same error message, so it seems likely they’re still in some way related.
Deryo, if you want to try what I did, I’d be very curious so know the outcome. Make backups first…
Bad code falls under the category of bugs, but not all bugs are due to bad code. In this case, my statement was that it wasn’t bad code. It could still be a bug due to corruption, a version mismatch, etc.
Deryo’s problem… We tried installing Seafile client to a machine that had never had it before. Same problem. He created me an account to log into his server, which I did successfully. I was able to download and upload from the WebUI.
However, from a machine that works fine in my environment and syncs perfectly with my server, I got the same issue as did he when I tried to sync to his, and that’s even trying to create a new folder and sync it as a new library.
What happens with Deryo is it creates the library perfectly. However, when it then checks for files to sync, the error is thrown, even if the folder is completely empty.
So, the problem appears to lie within the clone or download section of Seafile. The Seafile client code slings one error while the server logs another. So, if I had those error logs from the server and the client, I may be able to track down the issue at hand by looking at the code.
Oh, also in Deryo’s case, he stated that he did upgrades and switched over to NGinx. So, it’s really hard to track it down, but I’m almost certain it’s not NGinx.
So, did you do upgrades or anything before it started happening to you?
Oh, and if I’m understanding you correctly, you copied the seafile-data folder from a working client that syncs with another server, and it works syncing with the working server and the seafile data you copied which is compatible with the working server.
If that’s the case, it certainly sounds like a versioning issue, possibly with the commits/repos, or even one of the db files on the server that needs to be upgraded.
And, the only thing I have as far as errors go when I tried it is the applet.log on my client computer. Unfortunately, I don’t have other log files, such as the system log, seafile logs, etc in order to track it down. So, when mine failed on Deryo’s server, here is what I got: (I changed the name of his domain to protect it from the public eye)
[03/18/18 11:22:19]ServerStatusService: ignore request for host “seafile.deryosserver.com”
[03/18/18 11:24:32]Failed to add download task: Argument can’t be NULL
[03/18/18 11:29:26]Failed to add download task: Argument can’t be NULL
[03/18/18 11:37:00]Failed to add download task: Argument can’t be NULL
By the way, thanks for continuing to think about this weird issue. I’m glad someone is interested!
The server has gone through two or three upgrades since this error has occurred. In the past I was too busy to actively try to diagnose this issue and was able to make do with just one client, but now I really need multiple clients.
This problem exists on (at least) client versions 6.1.4 and 6.1.6 on the “bad” machines. The “good” machine is still on 6.1.4, and I’m not especially really inclined to upgrade, lest it break. The “good” machine has also had its client upgraded several times without incident since I started using Seafile a few years ago.
And here’s where it gets weirder…
I decided to run seaf-fsck.sh. One library had three or four damaged files, so I repaired that library.
Block 5786389b78bf829710272aac438a91f6887c8c6b is damaged, remove it.
File /path/to/some/file(62273884) is damaged, recreate an empty file.
After the repair, the good client now can no longer sync that library; it said to resync it. So I rescyned it, and guess what? Our favorite “argument can’t be NULL” message!
Other libraries on the good client continue to sync correctly. This is kind of driving me nuts but at this point it’s in for a penny, in for a pound.
My next idea, and I’m bummed it’s come to this, is to use seaf-fsck.sh to export all my libraries (~2 TB) and delete and reinstall a fresh Seafile server. Then re-import with seaf-import.sh. Finally, on the clients, sync their existing directories with the re-imported libraries on the server. Anyone have any thoughts about whether this is a bad idea?
If you could provide some error logs from the server, it would be helpful. So far, all I have is error logs from the client when I tried on Deryo’s machine. I’ve been through the code the best I could, and I know that the error is generated from the server side based on its location in the code.
The error logs I’m most interested in are the typical Seafile logs, but also any other logs that may be helpful, such as the systemd log.
I have noticed that during the upgrade path, especially when you are supposed to run several scripts during a major upgrade, that something will sometimes fail to update/install, and if you aren’t watching it during the upgrade, you could miss it. Back in the days of the 4.X to 5.X conversion, I did one, and accidentally missed one of the upgrade scripts. As a result, my seafile failed to sync, though the webui worked fine.
Also, as time goes one, some settings inside the config files are deprecated. Most people just leave them there, but eventually, they have caused problems for me in the past. Each time I do an upgrade, I check the manual to see what’s changed with the config files, and then change them accordingly.
One quick note - when seaf-fsck.sh exports, the files lose their original mtime/ctime and just have the date they were exported. So that’s pretty terrible (although I could script something to correct the file dates).
Another issue is seaf-import.sh is only shipped with the Pro edition.
Yeah, that pretty much happens to any exported file from any program. It’s an annoyance, for certain. My backup restores are that way. The date changes to the date I restore, rather than the date they were originally created. I also have that problem whenever I do a fresh install of Windows on my PC. The file dates change on the files I copy over.
All backup applications I’ve administered retain the dates when they’re restored. Amanda, BackupPC, Borgbackup, ShadowProtect, plain old rsync…
Try xcopy or robocopy to copy files from one Windows machine to another - one of those (with the correct flags) can definitely preserve file dates (I just forget which one).
I think I gave up about 15 years ago, lol… Back in the DOS days, it was more consistent than it is now… OS’s these days tag with metadata, complicating matters.
i have the same error for my seafile server. At this morning all was ok, but now all clients can’t sync new librarys. I’m upgrade server & clients, but i still getting error. There is no mention in logs for something linked with this events.
My actions with seafile today is tune server to work via nginx, but i rollbacked to old config and error still with me.
Hey. I’m made this work again!!
So, like i read above, @deryo have a problem happens while he config seafile running behind nginx. So am i. I’m digged out, what changes i made and one of it was modify SERVICE_URL & FILE_SERVER_ROOT.
Modify can be done both, via web interface (and it saves into mysql table and have higher priority against config files), and via config files.
Before changes there is no settings via sql table, but when i made changes, i did it via web interface. When problem happened, i changed back settings of directives, and i did it via webinterface too.
Now i truncate table where this settings stores (seahub-db/constance_config) and back settings in config files and librarys start syncing again.
So, problem was in settings that stored in mysql. May be it’s a bug, i opened it. Hope this will be helpful to somebody!
I did follow your steps and it (kind of) worked. After a few days wrong settings appeared in the admin page for file_server_root. I absolutely do not have any idea where the wrong settings came from. I changed the value to the values in ccnet.conf and now it (kind of) works again.
Why ‘kind of’? Some of my libraries just don’t sync. The client says “connecting server…” but nothing more. I found three threads regarding this issue here in the forum, none with a solution.
It seems that the relationship between seafile and me has a hard time…
