Moving Docker base location - the saf(er) way??

  • Hello,


    [Context]
    Long time lurker, first time poster. I've been using OMV for about 18 months.


    I came from Synology, and WAS running OMV 3 (with my RAID5 / BTRFS array I brought across from the Synology platform - guess what happened after I replaced a dead disk in my array... :thumbdown: )


    So I've been building a new OMV4.X based system with UnionFS and SnapRAID, restored my data from backup, started adding in my docker containers, and am now having some issues. My old OMV 3 platform was on an 8GB USB drive with the flash memory plugin, with 21 containers running, and everything was fine.


    [Problem] I''ve only got 7 containers, and I'm already running out of space on my 8GB system drive. I have a seperate drive, outside of my UnionFS pool, which holds all my Docker volumes (/config etc). The /var/lib/docker directory is consuming almost all of the available free space.


    (I've tried MULTIPLE times to expand this - I'veu sed cloneZilla to migrate this to a brand new 32GB USB drive, but GPARTED simply refuses to expand the existing partitions X( ...a seperate thread for another time pehaps).


    So I'm looking to change the Docker Base Path, and have read both of the following posts


    Move docker /var/lib/docker folder on external drive
    docker base path


    What is my best approach? Should I simply change the path in the webui, or edit the daemon.json code?


    My requirements is that this be as simple as possible, and would like for this to persist beyond upgrades, and not rely on my remembering to change something etc.


    Really appreciate any assistance or advice you can provide.


    Thanks.

  • but GPARTED simply refuses to expand the existing partitions

    ?( That's odd I have done this myself when I noticed that my 32GB USB Flash Drive was not showing all the available space you have to do this using gparted live, there is an option for that in OMV-Extras -> Kernel.


    Option 2 for your docker move seems to be the obvious, make they working before deleting the old location, as in that thread if one fails to move but the rest work redeploy that container.

  • Thanks for the feedback...turns out neither way was successful :(


    I tried the following for using the WebUI
    1) stopping all running containers (using the web ui to stop each container)
    2) stopping the service via SSH (service docker stop)
    3) changing the docker base path in Settings in the UI
    4) ran rsync to copy all of my files from /var/lib/docker to my new mount point
    5) file permissions looked good (ran ls -al at both /var/lib/docker and at my mountpoint - permissions looked identical)
    6) then brought up the service via SSH (service docker start)
    7) at this point in the webui, all focker images and containers had disappeared...I tried rebooting too, but there was no difference
    8) by reversing the setps (i.e. stop docker service, change path, then start docker service) all of my iages and containers cam back instantly


    But I am stil stuck with space contraints...OMV4 has been abysmal for me where I was deliriously happy with OMV3.


    I'm seriously considering reverting back, even though it's old and deprecated - for me, at least it worked...My last option is trying (another) manual rebuild natively on the 32GB drive..but I don't think my patience will stand it...

  • 4) ran rsync to copy all of my files from /var/lib/docker to my new mount point

    Why did you do that? It is mentioned in this post that the files are copied by the plug in. You just need to confirm that the files have been copied and delete the old ones.
    docker base path


    Maybe you mixed it with the other proposed solution: rsync and then create a symlink. But for that option you must not change the path in the GUI.

  • i did the rsync because the information in the post was not correct for me - the files did NOT copy across, so I had to copy them manually.


    It didn't work anyway, so once I'm confident that my docker-compose.yml entries will re-build the containers I'm going to blow all of it away and just rebuild on OMV3...at leas it was stable.

  • It didn't work anyway, so once I'm confident that my docker-compose.yml entries will re-build the containers I'm going to blow all of it away and just rebuild on OMV3...at leas it was stable.

    OMV4 is stable for me.


    What you propose can also be done on OMV4 if you are prepared to. Just remove all the images and containers, remove the docker-gui-plugin and install the plugin again. Change the docker base path before setting up any new container.


    Do you have other issues with OMV4?

  • My issues with OMV 4 are as follows


    1) I am unable to resize my System disk - 8GB partition on a 32GB USB drive. (I originally installed it on an 8GB USB drive - I really like being able to simply clone the USB disk as a system backup)
    2) NFS shares aren't available upon reboot. After the system has rebooted, I need to manually turn off NFS, then turn it back on again

  • 1) I am unable to resize my System disk - 8GB partition on a 32GB USB drive. (I originally installed it on an 8GB USB drive - I really like being able to simply clone the USB disk as a system backup)

    8GB should be enough if you don't put docker images, databases etc. on that drive. Otherwise it should be also possible to resize with OMV4. In the end OMV4 is just an application installed on Debian.

    2) NFS shares aren't available upon reboot. After the system has rebooted, I need to manually turn off NFS, then turn it back on again

    You should open a new thread with this issue.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!