Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Container Manager Move failed - No more containers #46

Closed
Sir-Bacon opened this issue Apr 9, 2024 · 14 comments
Closed

Container Manager Move failed - No more containers #46

Sir-Bacon opened this issue Apr 9, 2024 · 14 comments

Comments

@Sir-Bacon
Copy link

Sir-Bacon commented Apr 9, 2024

Script version: 3.0.45
NAS model: DS918+ with 16 GB RAM
DSM version: DSM 7.2-64570 Update 3

First, thanks for the script, I moved almost all packages, excluding 1, from volume1 to volume2. When I tried to move Container Manager it failed to do so. Screenshots below.
After failing I restarted CM in the DSM webpage and it showed no containers. I have the dockers already on volume2, the data is still there. Furthermore, on volume1 there is both an @docker as well as an @docker_backup folder.

Any tips on how I can get my containers back up and running?

image
image
image

@007revad
Copy link
Owner

@Sir-Bacon

Sorry, I came here to reply to you 4 days ago but got side-tracked and forgot to come back and reply. Did you sort it out?

@Sir-Bacon
Copy link
Author

I did not have time to sort it out yet. Just checked the container manager, but this is completely empty. For information, the following 4 containers were running: MQTT (Mosquitto), Grafana, InfluxDB and Home Assistant.
As I see it, there might be 2 options:

  1. Using the backup in @docker_backup, can I use the Restore option in the script to restore the containers directly to Volume2?
  2. Manually copy in SSH either @docker or @docker_backup from Volume1 to Volume2. (Or can I do this as well via WinSCP?)
    Or should I first check in SSH if there is anything already in @docker on Volume2?
    And if there is anything copied to Volume2, would Container Manager pick that up?

Alternatively (as the contents of the containers are still there) I can try to recreate the containers. the only caveat I have is that I am unsure what folders I mapped.

@007revad
Copy link
Owner

007revad commented Apr 15, 2024

The Restore option only works if you previously used the Backup option to backup the package.

You could stop Container Manager then copy the contents of @docker_backup from Volume1 to @docker on Volume2. You want to keep their permissions so it's better to do it via SSH. And copying is safer than moving, so you still have the backup.

sudo -i cp -prf "/volume1/@docker_backup" "/volume2/@docker"

You also want to check that all the Container Manager symlinks point to volume 2. You can view, and edit, them in WinSCP.

symlinks-1

There's also these other 2 symlinks you should check:

/usr/syno/etc/packages/ContainerManager  ->  /volume2/@appconf/ContainerManager
/var/packages/ContainerManager/var/docker  ->  /volume2/@docker

I just noticed on my DS1821+ that /var/packages/ContainerManager/var/docker is no longer a symlink pointing to /volume2/@docker. Instead it's now a folder that contains what is normally in @docker. I don't know if I've broken it or if DSM 7.2.1 Update 4 changed it.

I much must uninstall Container Manager and reinstall it and check /var/packages/ContainerManager/var/docker again.

@Sir-Bacon
Copy link
Author

Sir-Bacon commented Apr 15, 2024

The Restore option only works if you previously used the Backup option to backup the package.

A backup was performed as part of the moving process, not as a separate task (see 2nd screenshot).

You could stop Container Manager then copy the contents of @docker_backup from Volume1 to @docker on Volume2. You want to keep their permissions so it's better to do it via SSH. And copying is safer than moving, so you still have the backup.

sudo -i cp -prf "/volume1/@docker_backup" "/volume2/@docker"

I will try the copying you suggested tonight, thanks for the total command

You also want to check that all the Container Manager symlinks point to volume 2. You can view, and edit, them in WinSCP.

symlinks-1

There's also these other 2 symlinks you should check:

/usr/syno/etc/packages/ContainerManager  ->  /volume2/@appconf/ContainerManager
/var/packages/ContainerManager/var/docker  ->  /volume2/@docker

Will do that as well, after the copying

I just noticed on my DS1821+ that /var/packages/ContainerManager/var/docker is no longer a symlink pointing to /volume2/@docker. Instead it's now a folder that contains what is normally in @docker. I don't know if I've broken it or if DSM 7.2.1 Update 4 changed it.

I believe I am still on Update 3, but will check tonight

I much uninstall Container Manager and reinstall it and check /var/packages/ContainerManager/var/docker again.

@Sir-Bacon
Copy link
Author

OK, some results.

  1. The copy worked, I estimate it took around half an hour
  2. I checked the symlinks (In SSH, could not get WinSCP to show all files) and these are all ok, see screenshot below
  3. I checked the symlink for ContainerManager, that is ok, see 2nd screenshot below
  4. I checked the symlink for docker, that was still pointing to volume 1. I removed it and tried to get a new in, but got an error message, see screenshot 3 and 4 below

My DSM version is 7.2-64750 Update 3, telling me I am up-to-date.

In /usr/syno/etc/packages/ I also found a symlink for Docker which was still pointing to volume1, see screen shot 5 below.

At this point I have not restarted ContainerManager as 1 symlink is not pointing to volume2. How to get that in place?

image

image

image

image

image

@007revad
Copy link
Owner

007revad commented Apr 15, 2024

You can edit symlinks in /var with WinSCP if you are connected as root.

Otherwise you need to delete the symlink and then create a new symlink via SSH.

sudo -i
rm /var/packages/ContainerManager/var/docker/
ln -s /volume2/@docker /var/packages/ContainerManager/var/docker/

@007revad
Copy link
Owner

I'm not sure where you saw what's in your last sceenshot?

You need to move the Docker shared folder in Control Panel.

  1. Stop Container Manager.
  2. Go to 'Control Panel > Shared Folders'.
  3. Select your Docker shared folder and click Edit.
  4. Change Location to volume 2.
  5. Click on Advanced and check that 'Enable data checksums' is selected. 'Enable data checksums' is only available if moving to a Btrfs volume.
  6. Click Save.

@Sir-Bacon
Copy link
Author

Sir-Bacon commented Apr 16, 2024

I retried WinSCP to work as root, using https://emby.media/community/index.php?/topic/103636-how-to-access-synology-nas-as-admin-or-superuser-using-winscp/, but got an error message back. Must be something I did wrong.
Anyway, I then tried via SSH. This seems to work fine, I recreated the symlink. I did have to change the create command slightly:
ln -s /volume2/@docker /var/packages/ContainerManager/var/
image
Note: it seems the symlink is now called '@docker', whereas before it was called 'docker'. This must affect behaviour. How can I remove the @?

I checked the location of the Shared Docker folders. That is already on Volume2, with 'Enable data checksums' already checked.

Then I restarted ContainerManager, but no luck. Still completely empty. 'No Containers'.
Perhaps you have another idea. Otherwise I will simply create new containers. First trying to reuse the old data, otehrwise I'll start from scratch.

@007revad
Copy link
Owner

I just uninstalled Container Manager, but did NOT tick the option to delete containers, images or my docker shared folder. I then checked that all the @ folders were gone. Then I reinstalled Container Manager and it again has a folder named /var/packages/ContainerManager/var/docker/ instead of a symlink pointing to /volume#/@docker.

/var/packages/ContainerManager/var/docker/ contains all the folders and files that /volume#/@docker used to contain.

I've got to work if this changed with a DSM update or a Container Manager update.

I would suggest uninstalling Container Manager, but don't tick the box to delete everything, then reinstall Container Manager on volume 2.

@Sir-Bacon
Copy link
Author

I just uninstalled and re-installed ContainerManager, but still no containers in sight.

For me, the next step will be to start creating the same containers as I had, pointing to the shared docker directory. (I will make a backup of that directory first) Hopefully the containers should then spring back to life. This I will do in the weekend, no time to do it before then.

@Sir-Bacon
Copy link
Author

I tried to re-install a single container, Eclipse-Mosquitto. This turned out to be drama. Several non-specific failure messages, including 'port already in use'. I removed and re-installed Container Manager, restarted the NAS, all without success. So, still no running containers.
The next step is a bit unsure, resetting completely the NAS? Seems a bit over-the-top to get CM running again.
If I remove CM, are there any specific folders I need to delete as well?

@007revad
Copy link
Owner

Backup the contents of your docker shared folder. Then when you uninstall Container Manager tick the box to "Delete the items listed above when uninstalling the package". This will not only uninstall Container Manager but also delete all the Images, Containers and docker shared folder.

Then recreate your docker shared folder and restore it's files. Then install Container Manager.

@Sir-Bacon
Copy link
Author

Well, did all that and got a container running. Home-Assistant started completely normally.
Eclipse-Mosquitto not, still complaining about a port in use, but it seems there may be something else going on (eclipse/mosquitto#2866). So perhaps all my complaints were simply the result of another error.
For now it seems resolved.
Thanks for all the help!

@Sir-Bacon
Copy link
Author

Closed as for me issue is resolved. In the end I made new containers.
Mosquitto is also up and running, see issue there.

If this issue is resolved with the app mover script, I leave that to @007revad

@007revad 007revad mentioned this issue Jun 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants