Moved Docker from /volume1 to /volume2

Currently reading
Moved Docker from /volume1 to /volume2

12
0
NAS
920+ and 216+
Operating system
  1. Linux
  2. Windows
Mobile operating system
  1. Android
920+ running DSM 6.2.4-25556
I added 1xSSD (/volume2) to my existing 2xHDD (/volume1) this week. I moved my docker setup from /volume1/docker (HDD) to /volume2/docker (SSD) by following these steps:

- Stopped all my docker containers
- Stopped docker in Package Manager
- Backed up /volume1/docker via HyperBackup
- In Shared Folder I changed volume from /volume1/docker to /volume2/docker
- So far, so good...
- Once move was complete, I started docker and then went into the UI and modified Portainer to use /volume2/docker
- The Syno Docker UI complained ports 8000/9000 were already in use despite no other containers running at all
- When I encountered this port issue I reverted back to /volume1/docker and Portainer started without complaint
- I then repeated the steps above and the Syno Docker UI complained again when I tried bringing up Portainer
- I changed the Portainer ports to 8001:8000 and 9001:9000 and the container started with no issue.

Question 1:
Any idea why Portainer in this case is complaining about the ports already being in use?

Question 2:
I edited all the docker-compose files to point to /volume2/docker/container_name and that seems to all be fine. I noticed my containers still refer back to the original /volume1/@docker directory. Is there any way to have this point to /volume2 instead?

Here is an example from Portainer:
HostConfig section:
HostnamePath /volume1/@docker/containers/6dcb772373346d89fc627feaa73bc6b133e21aec1c0e84773518faa2dcbda90e/hostname
HostsPath /volume1/@docker/containers/6dcb772373346d89fc627feaa73bc6b133e21aec1c0e84773518faa2dcbda90e/hosts
Id 6dcb772373346d89fc627feaa73bc6b133e21aec1c0e84773518faa2dcbda90e
Image sha256:8377e6877145988a508c616a6cbf1f9659ab6093da69f74179c5e01581d8b8b1
LogPath /volume1/@docker/containers/6dcb772373346d89fc627feaa73bc6b133e21aec1c0e84773518faa2dcbda90e/log.db

Mount section:
Destination /config
Mode rw
Propagation rprivate
RW true
Source /volume2/docker/prowlarr
Type bind

Any insight would be greatly appreciated, thank you.
 
You can not just copy the content of whatever docker info --format '{{.DockerRootDir}}' returns, without actualy chanfing docker's data-root dir to the new location.

On Synology instead of /etc/docker/daemon.json, the file /var/packages/Docker/etc/dockerd.json is used to define docker configurations. The data-root is typicaly set to /var/packages/Docker/target/docker, which itself is a symlink to /volume?/@docker (where ? is the volume number the data root is placed on). By default the symlink points to the volume the docker package was
installed on.

Check where the symlink points to:
Code:
ls -l /var/packages/Docker/target/docker

Modify the symlink to point to the new location (make sure to replace ? with the correct number:
Code:
ln -sf /volume?/@docker  /var/packages/Docker/target/docker

After writing my response, I feel this topic has discussed here already and a search should have brought up usefull informations.
 
You can not just copy the content of whatever docker info --format '{{.DockerRootDir}}' returns, without actualy chanfing docker's data-root dir to the new location.

On Synology instead of /etc/docker/daemon.json, the file /var/packages/Docker/etc/dockerd.json is used to define docker configurations. The data-root is typicaly set to /var/packages/Docker/target/docker, which itself is a symlink to /volume?/@docker (where ? is the volume number the data root is placed on). By default the symlink points to the volume the docker package was
installed on.

Check where the symlink points to:
Code:
ls -l /var/packages/Docker/target/docker

Modify the symlink to point to the new location (make sure to replace ? with the correct number:
Code:
ln -sf /volume?/@docker  /var/packages/Docker/target/docker

After writing my response, I feel this topic has discussed here already and a search should have brought up usefull informations.
Thank you for this.
ls -l /var/packages/Docker/target/docker returns:
/var/packages/Docker/target/docker -> /volume1/@docker

Presumably I need to stop my docker instance prior to changing the symlink to point to my new volume?
 
I am surprised by the question.

Do you think it's a good idea to replace docker's core data folder while it's running? Of course it needs to be stopped. Obviosuly the previously created copy must have been made from docker's data root folder while docker was stopped as well, otherwise the copy will be inconsistant.
 
I am surprised by the question.

Do you think it's a good idea to replace docker's core data folder while it's running? Of course it needs to be stopped. Obviosuly the previously created copy must have been made from docker's data root folder while docker was stopped as well, otherwise the copy will be inconsistant.
Thanks for the guidance.
The volume move was done while docker was stopped. What you are saying makes sense, I just am a novice when it comes to this, hence my question.
Once the symlink points to the SSD, aside from a container accessing, say media files on the old HDD volume, is there any reason the containers would access the old HDD volume?
 
Moving the data-root ensures that all the meta data, images, name volumes (!="volumes" from Syno'S docker ui are NOT volumes, they are binds), network configuration and containers will work from the new location.

But if a container configuration comes with existing binds (=such as the volumes configured in the ui), then those will still point to the old location.

If you have a specifc error message, please share
 
No errors, I just noticed that the core of the containers were still pointed to the spinners. When I did the initial data move, I had changed all my binds to point to the new ssd/volume2.

I just shutdown all my containers and stopped the docker package and performed the following:

NAS920:/$ ls -l /var/packages/Docker/target/docker
lrwxrwxrwx 1 root root 16 Aug 15 10:06 /var/packages/Docker/target/docker -> /volume1/@docker
NAS920:/$ ln -sf /volume2/@docker /var/packages/Docker/target/docker
ln: failed to create symbolic link ‘/var/packages/Docker/target/docker/@docker’: Permission denied
NAS920:/$ sudo ln -sf /volume2/@docker /var/packages/Docker/target/docker
Password:
NAS920:/$ ls -l /var/packages/Docker/target/docker
lrwxrwxrwx 1 root root 16 Aug 15 10:06 /var/packages/Docker/target/docker -> /volume1/@docker
NAS920:/$ sudo ln -sf /volume2/@docker /var/packages/Docker/target/docker
NAS920:/$ ls -l /var/packages/Docker/target/docker
lrwxrwxrwx 1 root root 16 Aug 15 10:06 /var/packages/Docker/target/docker -> /volume1/@docker

It would appear that the symlink is still pointed to /volume1. Any ideas? Thank you.
edit: I just noticed in the Syno UI in the Docker package it says Installed Volume: Volume 1
 
Thanks for all your help. I had to do the unlinking followed by "ln -sf" and that created the symlink to /volume2.
That said, docker would not start again, I think it said failed API so I un-installed and reinstalled the package. I was given the choice of volume1 or volume 2 this time around so I selected /volume2.
Any previous containers were gone, so I deployed portainer via command line and built stacks/docker-compose for ones that did not previously have them and for the others I merely started the stacks.
All good now, Docker says it is deployed on volume 2 now, Portainer shows the core as being in volume 2 as well.
Most importantly, the constant disk access from my various containers is now on the ssd so the noise from the spinners is down considerably.
Thanks again for the help, I appreciate it.
 
Hmm, I wonder why bending the symlink to the other location didn't work. It should have, as long as both volumes have the same filesystem. On normal linux the process would be as simple as stop the docker service, move content of data-root to a new location, configure the new location in /etc/docker/daemon.json (which was not required on Syno, because of the symlink) then start the docker service again.

To summ up things: the migration from volume1 to volume2 failed and you had to start from scratch...

Even though the "rescue" mission itself failed, I am glad you have a clean working solution now!
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

For the heck of it, I just checked again in docker container, and it announced an update was available. I...
Replies
4
Views
669
  • Question
Do realize, that enabling any user to run docker containers is largely the same as giving that user full...
Replies
6
Views
1,269
Hello, I already have it configured perfectly with wireguard. I was looking at the Gluetun configuration...
Replies
4
Views
948
Thanks... I tried something similar with rsync. The docker volume lived in...
Replies
7
Views
960
I can’t find any option to restore just the settings. 1710356648 Phew, managed to fix it. Within the...
Replies
4
Views
736
Good to hear. Deluge has not been updated for almost two years now as an app, nevertheless. But it gives...
Replies
12
Views
1,430

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Trending threads

Back
Top