same update to ubuntu 18.04 on the client pc (from 17.10 working fine)
same reinstallation of seafile client that was uninstalled durinf the system update process
same result to “apt policy libsearpc1 liccnet0 libseafile0 seafile-gui”
I upgraded the server to 6.2.5 (i386 on centos in my case) without solving the problem.
Few notable things:
1 of the libraries is working fine, most notably the last one I created on the server.
creating a new library (by dropping a directory in the client bottom area) is working fine also when using encryption
seaf-fsck or seaf-gc on the server are not helping
my gues, this has to do with some library version on the server but I’m not able to find a way to fix it at the moment
the only option is to delete the libraries from the server and then recreate them all, (which worked for a small one) but I do not want to go through this for all my libraries
Have you checked the permissions on the old libraries? Linux OS upgrades have a tendency to screw some up.
Additionally, during the upgrade, did Ubuntu ask you if you wanted to “use the new config file” or the “existing config file” here and there? I find that to be one of the most annoying things about Linux upgrades, and I’ve made some mistakes with the answers from time to time that required me to reconfigure and/or reinstall something after an upgrade.
Hi wthess, thanks for the answer.
during the upgrade on the client system I did not get any question asked.
Seafile client was listed as software to be removed and if fact it was removed during the upgrade process.
I reinstalled the new client as instructed on the website and I found all server and libraries already setup in the client.
The only problem was that most of them are not syncing any more.
I’m not able to check permission right now but as soon as I can I’ll update on this topic as well.
Although it is missing form the changelog I think I’ve seen somewhere that the support has actually been fully removed from the client. It would of course be better to show a hint and link some page where it is explained.
@daniel.pan has support for old libraries been removed from the client?
I don’t remember being asked questions during update. However, in order to check your hypothesis about old config files, I created on the client laptop a new user with a new home directory. But still I cannot sync any of my libraries, I keep receiving the “old version library” error.
I just find it odd that it worked on 6.0.8 and an OS upgrade to the server now causes Seafile to state that there are old versions of the libraries. To my knowledge, the library version has not been updated for some time now, so I’m not certain exactly what’s going on here.
But, because you asked… Someone did write a script, and last I saw, it still worked back in 2017. If you decide to try it, back up your repositories first, as it was not a Seafile developer that wrote it. You can find the details here:
Correct. I misstated. however, the seaf-gc you ran on the server is showing those libraries to be older versions. (version 0). I was under the understanding that older versions were not compatible with later versions of the client… Also, if Im not mistaken, version 0 was prior to version 3.0 of Seafile Server.
Although I’m curious as to what happened, we are more interested in helping you get back in operation, which is why we are here.
OK, I went thru the script documentation today only and I realized that it only applies to unencrypted libraries.
Unfortunately all my libraries are encrypted so I’m back to the only option to re-import them all, which is what I’m going to do.
If I understand it correctly, the new client does not support the old server library, which is quite an unusual thing to happen. With server-client applications the network protocol usually hides the concrete implementation on the server.
Also, the support for the old libraries is obviously removed only in the latest linux client, but not for windows and android.
So, the solution is, to migrate the server libs to the most recent version. There is no officially supported way but someone mentioned a script which would do the job.
If this doesn’t work, the only way would be to export the library and to re-import it. I am wondering if this keeps the history intact…
This is wrong. It is either removed from all clients (Windows, Mac, Linux) or none.
The Android client never support the old library format but uses the Web API instead. This works because it does not use/support the synchronization mechanism.
Unless you have the folder and libraries saved to a hard drive somewhere, then exporting would be the only way. Due to the way encrypted libraries work, I always keep a synced copy somewhere on another machine. That way, if the unencrypted library has a problem, I can simply delete it from Seafile and sync it back via a client. Do you have a backup copy by any chance?
Thanks for your answers. My libraries are unencrypted and I do have plenty of backups, this is not what I am worrying about. It is more the process of converting, which seems very tedious. I have many large libraries (>300G) and many users. This makes it complicated due to 3 main reasons: First, exporting and re-importing takes time and effort. Second, I guess the users have to (re)sync after the re-import again, which needs to be communicated and supported. Third, I don’t want to lose the history of files and directories.
Totally understandable with that many users. Those older libraries will eventually need to be converted anyway. Version 0 libraries are pre-version 3.0, and usually due to being encrypted at the time 3.0 was released. I find it strange that you have unencrypted libraries still on version 0.
I don’t know if I mentioned it in this thread or another, but I think I saw where someone wrote a script to convert the libraries. I don’t know if it preserves history or not, though.
Hi,
I’m wondering if there is any kind of official statement to this?
Reading this it seems nobody is expected to have version 0 libraries anymore, so was everyone who started with 2.x or earlier expected to wander of to some other tool or what?
I’m really taken aback by this approach, it’s quite unusual to just abandon backwards-compatibility without any official migration path.
To me it seems the easiest to keep using older client versions until there is a solution for this. However, that does not help with the problem that version 0 libraries are also not supported by seadrive.
Only migration path to solve this is to upload the data to a new library. I’m also pretty sure that this won’t change as v3 has already been released more than 4 years ago.
