I’m not sure we 100% understand what you’re saying but I believe what you want to achieve is to give your application team access a specific folder in the container without them having to launch an interactive shell on the conainer.
Personally I would achieve this using a bind mount:
After this I would make the folder on the host a network share and adjust the permissions accordingly.
Nobody should be logging in to the host unless they are managing containers, and nobody should ever be logging in to the containers.
I’m saying this is the only way, or even the right way, but having just heard the problem, this is my first thought. If it were me, and it was a production environment, then I’d actually be looking at some external/shared storage which is attached to the docker host and then mounted to the container like this.
If I get it right, the OP wants a container folder, with prexisting data from the image, to be available on the host.
sikotic’s approach to use a named volume baked by a bind is already the best option there is, but it still has caveats.
Named volumes provide a copy-on-first-use mechanism, where the content of a container folder is copied back into the named volume. Then the named volume will be mounted on top of the container folder, thus making the content inherited by the image invisible.
So whenever you change content in the image path, create a container from it and use an already existing named volume, the container path will use whatever state the volume has. The changes of the images would never been seen by the container. Unless the volume and it’s content get deleted and the container re-created.
Overall depening on the volumes copy-on-first-use mechanism is usualy not the most reliable thing to do.
You might want to modify your image, so that the content of the folder is stored in a different folder, then let your entryoint script take care to copy the files to the final location (where you mount the volume) or migrate files or how ever your conflict resolution strategy will look like.
I was under the impression that bind mounts didn’t copy data. Are you saying that, if you create a volume which is a bind mount, and then reference it by name in your compose file, it still copies the data?
The `nocopy` mode is used to disable automatically copying the requested volume
path in the container to the volume storage location.
For named volumes, `copy` is the default mode. Copy modes are not supported
for bind-mounted volumes.
I am unclear, do I need to set the nocopy option? I originally took this to mean that, because it was a bind-mounted volume, it would not copy the data. @srinvas, the answer to this will affect the -v command I gave earlier, but not the --mount command.
A bind mount as in “-v /host/path:/container/path” indeed does not, but a volume baked by a bind should. If you use the nocopy mode, of couse a volume baked by a bind will behave like a normal bind-mount (those not listed in docker volume ls).
This should be shouted from the mountains. I’ve been searching for this for ages as I can bake my python dependencies into the image and then use this to expose the files locally so neovim can jump to definition for the code that is inside the container. There are so many open issues with this scattered on the internet that I thought there was no way. Thank you!