Hello,
I was wondering if there is a command I can run to map an additonal folder to a running container so I do not have to edit it and lose all of the configuration settings of the container.
Hello,
I was wondering if there is a command I can run to map an additonal folder to a running container so I do not have to edit it and lose all of the configuration settings of the container.
What makes you think that modifying a container (using the OMV Docker page) causes the existing configuration to get lost?
the warning when you click modify that says all non persistent data will be deleted and in the past i have done this and had to reconfigure what I have done in the container.
What docker are you using that does this? Rebooting the machine would also do this, no?
its very strange, it does not happen if i reboot the container. I have had it happen with sab. I will test again to confirm it is not something i am doing.
I just tested it with mylar, i did a bit of the configuration and then saved it. Then i modified the container and made no changes to it and then when it came back up the configurations were gone.
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?
The question has been asked - what docker are you trying to configure?
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.
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.
Is there a way to find where omv is storing my containers on the shared folder?
Sent from my Pixel 3 XL using Tapatalk
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.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!