I have a question to the permissions of docker volumes.
I've now set up docker on multiple servers and for some containers I used bind mount points and for others I used named volumes, which for me seems like the same - the only difference I see is the directory (
/var/lib/docker/volumes/... or self-picked).
Now I have one questions concerning best-practices for docker deployments.
UIDs and GUIDs are shared with the host system. Let's assume container A has an application that runs as user db with UID being 800 and the corresponding volume has very important production data on it. On my host system UID 800 could be basically any service, let's assume it is an easy-to-take-over service. That service could potentially access the data of the container.
In this case it is desirable to use the named volumes, because they are in a directory that is protected against normal user access, or at least by not creating volumes in public locations (/, /srv, ...),
When I initially create a named volume, it gets created inside
/var/lib/docker/volumes/.... Most of the time this means that an application inside the container that doesn't run as root, cannot create any files on a volume. Consequently, every application that needs specific folders and permissions, has to set this in the ENTRYPOINT Script, before handing over to the application.
Is this intended behavior? And how do you now move a named volume? Docker doesn't seem to support this out of the box. I've seen lots of approches that use just tar or create a container that exports the volumes, but this seems very hard to automate. Is there an easier/official/scriptable approach to migrate (named) volumes, ideally by creating a tarball that is simple to import? Or am I miss-understanding something here?