Docker migration from 10 to 11 fails on migration script

Seafile Server
, ,
1

Hi!

At long last I migrated my server from v9 running franchetti’s docker image and using sqlite, to v10 using the official docker image and mysql + memcached. It was a lot of work bringing the data and configuration back to the correct setup, but v10 is now working. I did not take any particular steps to migrate the data after following the sqlite migration instructions to fill the Mysql database (I had to trop previous sessions and login logs due to hacking attempts resulting in corrupted SQL scripts). I simply ran v10 directly, connecting it to the populated Mysql. It worked, if any migration happened it seems to have done so silently and successfully. I do have some errors in the seahub log but this could be related to my reverse proxy not forwarding some of the newer things like notifications etc., I’m not sure. The functionality I’m used to is there.

But now I thought I’m ready to simply stop the Docker container, replace the version number and relaunch. However this fails. The logs of the docker container say:

2024-05-14T18:13:58.831542215Z *** Running /etc/my_init.d/01_create_data_links.sh...
2024-05-14T18:13:58.928023433Z *** Booting runit daemon...
2024-05-14T18:13:58.928071609Z *** Runit started as PID 25
2024-05-14T18:13:58.928465435Z *** Running /scripts/enterpoint.sh...
2024-05-14T18:13:59.007091183Z 2024-05-14 20:13:59 Nginx ready 
2024-05-14T18:13:59.069816784Z 2024-05-14 20:13:59 This is an idle script (infinite loop) to keep container running. 
2024-05-14T18:13:59.501629845Z [2024-05-14 20:13:59] Skip running setup-seafile-mysql.py because there is existing seafile-data folder.
2024-05-14T18:13:59.502328846Z [05/14/2024 20:13:59][upgrade]: The container was recreated, start fix the media symlinks
2024-05-14T18:13:59.507076735Z mv: cannot stat '/opt/seafile/seafile-server-10.0.1/seahub/media/avatars/*': No such file or directory
2024-05-14T18:13:59.507866416Z Traceback (most recent call last):
2024-05-14T18:13:59.507904620Z   File "/scripts/start.py", line 95, in <module>
2024-05-14T18:13:59.508214288Z     main()
2024-05-14T18:13:59.508232673Z   File "/scripts/start.py", line 61, in main
2024-05-14T18:13:59.508413200Z     check_upgrade()
2024-05-14T18:13:59.508429702Z   File "/scripts/upgrade.py", line 120, in check_upgrade
2024-05-14T18:13:59.508709310Z     fix_media_symlinks()
2024-05-14T18:13:59.508727631Z   File "/scripts/upgrade.py", line 104, in fix_media_symlinks
2024-05-14T18:13:59.508920138Z     call('mv -n %s/* %s' % (avatars_dir, dst_avatars_dir))
2024-05-14T18:13:59.508937203Z   File "/scripts/utils.py", line 70, in call
2024-05-14T18:13:59.509198182Z     return subprocess.check_call(*a, **kw)
2024-05-14T18:13:59.509217175Z   File "/usr/lib/python3.10/subprocess.py", line 369, in check_call
2024-05-14T18:13:59.509583923Z     raise CalledProcessError(retcode, cmd)
2024-05-14T18:13:59.509616856Z subprocess.CalledProcessError: Command 'mv -n /opt/seafile/seafile-server-10.0.1/seahub/media/avatars/* /shared/seafile/seahub-data/avatars' returned non-zero exit status 1.

To me this seems like it was obviously going to fail, since the new image contains:

  • the seafile-server-11.0.8 directory
  • the seafile-server-latest symlink which points to seafile-server-10.0.1
  • but no seafile-server-10.0.1 folder anymore, it was in the previous image I guess

What have I done wrong and what should I do now? Would running upgrade_10.0_11.0.sh manually from within the container help? I prefer to ask before attempting…

Fortunately for now, going back to version 10 still works so I can wait a few days without losing my data. But I’d be keen on moving to the latest version!

Thanks in advance for your insights,
P.

1 Like
2

Hi,
I’m still hoping to get some help here…

I tried to copy the seafile-server-10.0.1 folder from the old image to the host and then binding that folder to /opt/seafile/seafile-server-10.0.1 when starting the 11.0-latest image to see if that would solve the error above, however it only brought me to another error. The docker log when starting the image becomes:

*** Running /etc/my_init.d/01_create_data_links.sh...
*** Booting runit daemon...
*** Runit started as PID 24
*** Running /scripts/enterpoint.sh...
2024-06-09 11:50:22 Waiting Nginx 
2024-06-09 11:50:22 Nginx ready 
2024-06-09 11:50:22 This is an idle script (infinite loop) to keep container running. 
[2024-06-09 11:50:23] Skip running setup-seafile-mysql.py because there is existing seafile-data folder.
Starting seafile server, please wait ...
** Message: 11:50:23.358: seafile-controller.c(621): No seafevents.
seaf-server: error while loading shared libraries: libldap_r-2.4.so.2: cannot open shared object file: No such file or directory
Seafile server started
Done.
Starting seahub at port 8000 ...
Error happened during creating seafile admin.
Seahub is started
Done.

And all I get from seahub is an error 502.

Please help!

3

I finally got it to work. If it helps anyone in the future, the key problem was that my docker image somehow had an environment variable SEAFILE_VERSION set to 10.0.1. I believe this was added by seafile itself while running version 10, or by Portainer detecting the environment variable and “keeping it” when recreating the container with the new image. This caused the upgrade script to consider it did not need to upgrade, and got lost in some symlinks fixing process I don’t understand but which didn’t work under the circumstances. Removing that variable allowed me to progress further. I’ve since noticed that it was automatically recreated and it’s now showing a version 11. This may be something seafile does, or it may be a side effect of using Portainer to recreate the container with a new image - I would advise against doing this!

I then had 2 more minor issues to fix (still more than the upgrade instructions would have led me to believe):

  • the CSRF_ALLOWED_ORIGINS was set to include ‘my.domain.com’ which worked up to version 10, but from version 11 I needed to change this to include ‘https://my.domain.com’
  • I had changed the root MySQL password manually after first deploying the containers while on version 10. This did not cause issues at the time because I think seafile does not need the root user once the initial setup is node (it creates its own user). However when moving to version 11, seahub would not start after the upgrade because it could not connect to MySQL (it didn’t give any explicit reason though). It turns out I had changed the password from within mysql by targetting ‘root@localhost’ instead of root@‘%’ which is required since the database and seafile run on separate containers. This one is on me for playing with the passwords manually after setup and not knowing better.

I love seafile for the speed it brings, even on small hardware, once it’s running, but the installation, at least of the community edition, is really not straightforward. Both the docs and the scripts could be more verbose as to what needs to happen and what is going wrong.