add additional volume map to docker container

    • OMV 4.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • You cannot attach volumes to running containers. The “modify” button is not modify perse, it just parses the curent relevant parameters and deletes the running container and creates a new one with the same params plus the ones you add.
      Make sure the image provides a configuration volume you can map to the host so whenever the container gets destroyed creating it again with same volume can have the configuration “restored”.
      New wiki
      chat support at #openmediavault@freenode IRC | Spanish & English | GMT+10
      telegram.me/openmediavault broadcast channel
      openmediavault discord server
    • subzero79 wrote:

      You cannot attach volumes to running containers. The “modify” button is not modify perse, it just parses the curent relevant parameters and deletes the running container and creates a new one with the same params plus the ones you add.
      Make sure the image provides a configuration volume you can map to the host so whenever the container gets destroyed creating it again with same volume can have the configuration “restored”.
      This. +1

      A container has an ephemeral life. It can be deleted et recreated as much as you want. If you bind mount your config/data to host (or use volumes) you will never lose your conf.
      I'm a Docker Technical Sales Professional.

      1 NAS OMV 4 (Intel Pentium G4560 3.5 GHz, Asrock H110M-ITX, 24 Gb DDR4, 2*4 To Seagate Ironwolf Nas, 4*4 To WD red) -> Power consumption: 4 euros/month.
      1 Backup Server omv 4 (Intel G3930, 8 Gb DDR4, 6*4To WD blue)
      1 RPI 3 seedbox with omv 3.X
    • RPMan wrote:

      subzero79 wrote:

      You cannot attach volumes to running containers. The “modify” button is not modify perse, it just parses the curent relevant parameters and deletes the running container and creates a new one with the same params plus the ones you add.
      Make sure the image provides a configuration volume you can map to the host so whenever the container gets destroyed creating it again with same volume can have the configuration “restored”.
      This. +1
      A container has an ephemeral life. It can be deleted et recreated as much as you want. If you bind mount your config/data to host (or use volumes) you will never lose your conf.

      Is there a simple way for me to figure out where the config/data is for the container so I can rebuild it?
    • The question has been asked - what docker are you trying to configure?

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
    • Looking to revive this old thread, when I created my docker containers such as sabnzdb or sonarr i did not give a host path for the /config for any of these containers. In the settings for the docker plugin, I have it set to use my docker shared folder as the docker base path so I would assume that is where the configuration for all the containers are. My question is, is there a way to figure out where these configurations were placed by default on this shared folder so I can move them to a permenant location which would allow me to modify the container and have it come back to life with its settings.
    • chuckado wrote:

      I have it set to use my docker shared folder as the docker base path so I would assume that is where the configuration for all the containers are. My question is, is there a way to figure out where these configurations were placed by default on this shared folder so I can move them to a permenant location which would allow me to modify the container and have it come back to life with its settings.
      I think I understand what you're getting at - you want certain configuration files that would normally reside in a docker container, to be mapped to the outside so that these settings survive a reboot (which is a container reset).

      Wanting something similar, I tried to map a container config file to the the outside and the container consistently crashed. (I changed nothing in the file and I didn't move it from it's default location inside. I simply mapped it out.)
      If the author of the Docker doesn't design for files/configurations to be mapped outside of the container, it may not work. (I didn't test this extensively because there are too many variables "AND" each Docker would be a unique test case.)

      While it's speculation, I believe the issues of mapping files/folders in and out of a container are related to permissions problems. Keep in mind, the root account on the outside (OMV) is NOT the same as the root account on the inside of the container (the containers root). Given that examining the inside of a container, on the CLI, is a manual process, and virtually none of the tools one normally uses with Linux are there, it would be a PITA to run down details.
      ___________________________________

      So, if you want a particular Docker to do something that it's not specifically designed for, you'd need to consult with the Author.

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
    • If you have the default Docker setup, OMV is storing the Docker images and containers on the boot drive. This is no big deal. Dockers are so small (most of them), they don't take up much space on the boot drive. ((If it's a downloader or something else like Plex, it makes sense to relocate their data directories to a data drive, but they're designed to allow that.))

      Without knowing how you have Docker setup;

      A "container" is in several locations, under the folder where they're stored. That's another aspect of Docker that makes dealing with a specific problem, very abstract. Docker uses "overlays" to assemble a container from different directory locations. It works very much like UnionFS works, where UnionFS will merge separate hard drives together and present the user with a unified root directory, that "appears" to be a single directory tree.

      You can figure it out. I mapped out the rough overlay layout in times past, but it was just a passing curiosity. I came to the conclusion that, if I want to preserve my Docker setups, "Backup" of the boot drive is crucial.

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk