I have a docker image which contains an eclipse. I run the eclipse in the image under an account named eclipse. I want to start the image with my workspace directory form the host machine bind-mounted into the container. Unfortunately the owner of the mounted volume inside the container is not eclipse. The mounted volume just preserves the UID and GID from the host.
Is there a way to control under which UID and GID is the volume mounted in the container?
Though both methods are similar, there is a slight difference. Docker manages Volumes and is usually not affected by other processes running on the same host. In contrast, Bind Mounts are just directories on the host file system and may be modified by other processes other than docker.
Bind mounts have been around since the early days of Docker. Bind mounts have limited functionality compared to volumes. When you use a bind mount, a file or directory on the host machine is mounted into a container. The file or directory is referenced by its absolute path on the host machine.
Bind mounts will mount a file or directory on to your container from your host machine, which you can then reference via its absolute path. To use bind mounts, the file or directory does not need to exist on your Docker host already. If it doesn't exist, it will be created on demand.
This command removes the container and any volumes associated with it. Note that if a volume was specified with a name, it will not be removed.
I believe at this point there is no way to set the UID and GID as a mount option in docker. But there are at least two ways of getting around this:
Match UID and GID of the owner/user in the host and container. In your case, if the owner ID and GID on the host is say 1000, make sure the uid/gid of the owning user in the container has the same UID and GID, in this case 1000.
Use the file access control list command getfacl
- get the uid/gid of the workspace directory owner on the container, and use setfacl
command to grant this id read/write permission at the host. You have to run setfacl on the host. This way the acl rights will propagate to the container. I would not recommend making any ownership changes at the container level, as that will mess up the owership on the host and it won't be preserved the next time you launch a container from an image.
Remember, when it comes to file permissions only the numeric id
matters.
Helpful links - permission inside containers
Is it acceptable to make the workspace world-writable? I believe there is no way to change the uid/gid of the mounted directory so the only alternative is matching uid/gid between host and container (nasty :( )
See https://github.com/docker/docker/issues/7198 for info on uid/gid
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With