add additional volume map to docker container

  • What makes you think that modifying a container (using the OMV Docker page) causes the existing configuration to get lost?

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • What docker are you using that does this? Rebooting the machine would also do this, no?

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    • Official Post

    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”.

  • 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.

  • 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?

  • Is there a simple way for me to figure out where the config/data is for the container so I can rebuild it?

    Have you looked at the documentation for the image?

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • 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.

    • Official Post

    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.

    • Official Post

    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.

Participate now!

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