007revad / Synology_app_mover

Easily move Synology packages from 1 volume to another volume
MIT License
327 stars 25 forks source link

Container Manager Move failed - No more containers #46

Closed Sir-Bacon closed 5 months ago

Sir-Bacon commented 6 months ago

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 commented 6 months ago

@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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 (https://github.com/eclipse/mosquitto/issues/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 commented 5 months ago

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