Make uid & gid configurable for shared volumes

[digital-wonderland]

Please provide an option to make ownership of shared volumes configurable.

For example my current use case is to have logstash-forwarder running within a container, that has /var/lib/docker shared read-only as volume from the host.

Since /var/lib/docker is set to 0700 root:root on the host I can't access the volume as non root user.

What I would like to have is something like with NFS where one can map uid & gid from the host to users & groups on the client.

I.e. docker run -v /var/lib/docker:/var/lib/docker:ro:$user:$group would make the volume available in the container as read only, belonging to $user:$group.

[thaJeztah]

I don't know how they implemented this, and if a comparable feature exists on Linux, but on OS X, a feature exists to 'ignore ownership' on a volume. Effectively this will make any user see the files/directories as if they were the owner.

Although this won't serve all cases, it may be a nice addition

[elgalu]

+1

Related: http://stackoverflow.com/questions/23544282/what-is-the-best-way-to-manage-permissions-for-docker-shared-volumes

[cpuguy83]

gh#5910 kind of handles this from the SELinux side.

[riaanvddool]

link: #5910 ;)

[rhatdan]

The SELinux change is actually changing the labels on the content. Potentially you could do the change on the host. I know of no other way to do this for UID/GID. But doing a chown -R $UID:$GID on the mount point.

Or you could add this type of access using ACLs. But I think you will need to change every INODE on the mount point.

[nazar-pc]

I also need this feature.

For example, I want to create web container, and attach volumes with websites and configurations to it, so that container will be completely universal for any number of websites.

However, I need git access for pushing code to website repository. Since I want to have my apps to be isolated - I want to have each website directory to be owned by separate user/group, and it would be great if files written by Docker container into volume will be owned by that separate user/group.

[OlivierA]

+1 for this feature.
I don't understand how read/write volumes can work without it. Expecting the guid/uid to be the same on the image and the host is a strong requirement incompatible with Docker's isolation principles.

I'm personally working around this with ugly and slow useradd/groupadd commands for my Dockerized development tools: https://github.com/ndless-nspire/Ndless/blob/master/ndless-sdk/bin-docker/nspire-docker

[ajrouvoet]

I might be completely missing the point. But I was struggling with a similar issue where i want to ensure that the http user has write permissions on /var/log, which is a volume and is likely from the host with root:root as owner.

I solved it by setting an entrypoint that ensures that the logdirectories are created and have the right permissions. I guess this works because the entrypoint script runs as root.

[smyrman]

(removed comment -- wrong tab, sorry)

[jjrv]

I hacked around this in Ubuntu outside Docker. Install package bindfs and bind the directory with volume contents to another path while mapping UID and GID to ones used inside the container:

sudo bindfs -u UID -g GID oldpath newpath

Then use newpath as a docker volume. Oldpath still shows ownership correct for the host, newpath for the guest.

[cpuguy83]

@jjv the problem is bindfs is REALLY REALLY slow.

[jjrv]

@cpuguy83 yes it's far from optimal but maybe helps someone in a similar situation. This was to get things working inside a development virtual machine (vmhgfs doesn't allow setting UID/GID) while in production the UID and GID still have to match between host and guest...

[jsternberg]

It would actually be nice if a type of bindfs functionality was used when docker implements this, assuming it doesn't cause too much of a performance hit. That way, you wouldn't have to make sure the container was being run as the correct user. It should also be possible to use logical names instead of the literal uid/gid.

[cpuguy83]

@jsternberg It is a TREMENDOUS performance hit. Pretty much akin to using vbox shared folders.

[cynipe]

+1

for the local development use-cases, I think Docker definitely need this feature. And in such case, I want this feature to support the both Windows and OSX.

Vagrant seems to support this by mapping host user's UID/PID to vagrant user's though. But for the developing purpose, I really want to use Docker instead of Vagrant, since it's much lightweight than Vagrant to running multi-host applications.

[krisgraham]

Please tell me what I'm missing here (I don't have any experience with Go), but doesn't the Go Mount() function accept flags? Couldn't we allow for a command like
-v host/folder:container/folder -mount-as user:group
Couldn't you just get the uid/gid with lookup (https://golang.org/src/os/user/lookup_unix.go)
and then pass them (uid=1,gid=1) as flags into Mount()? (https://golang.org/src/syscall/syscall_linux.go?s=19154:19249#L754)

[cpuguy83]

@krisgraham bind mounts don't supprt setting uid/gid like that.

[rhatdan]

Also separating the -v option from the --mount-as option causes confusion when there are multiple -v option

[berfarah]

What's a good workaround for this? I'd love to use Docker for active development, and not having a mounted volume of some sort isn't really an option as I'd have to rebuild every time I make a change in my code.

The reason I want to use Docker for active development is so that it's consistent with my production environment.

[cpuguy83]

@berfarah I use docker for active development every day.
There is rarely the case when I need to mess around with perms.
If you are using boot2docker on OSX, then make sure your working dir lives within /Users and you should be fine.

[berfarah]

@cpuguy83 Thanks for the quick reply. I'm having permissions issues with a rails environment where logs can't be written, and there are occasionally points of failure because of permissions. This is due to my services having a different UID to the one of the files.

[ryneeverett]

@berfarah My workaround is to write my dockerfiles such that the container-users/groups that own the code have the same UID/GUID as my host user. E.g., since my host user UID is 1000:

RUN \
    groupadd code_executor_group && \
    useradd code_executor_user -g code_executor_group -u 1000

[cpuguy83]

@berfarah Have logs to go stdout/stderr for RAILS_ENV=development?

[ncjones]

@cpuguy83 This issue does not affect OSX; thaJeztah commented on 24 Jul 2014:

on OS X, a feature exists to 'ignore ownership' on a volume. Effectively this will make any user see the files/directories as if they were the owner.

[thaJeztah]

@ncjones actually, the same applies to OS X. The "volumes" I was talking about there, are the harddisks / partitions (volumes) used on OS X itself. I doubt that makes a difference for working with Boot2Docker, but I'm not sure.

My comment was meant to inform if something similar was possible in Linux (thus inside the Boot2Docker VM)

Sorry for the confusion there.

[BoilingSoup]

still the most annoying docker problem to this day

[nmsobri]

still no update on this? this is real sad

[con-f-use]

... 😠

[duhon]

why docker team don't want to solve this problem?

[terrisgit]

why docker team don't want to solve this problem?

Because it's how POSIX filesystems work. Today, if you want shared volumes to work, you must assign gid and uid values that exist in both the host and the container. The real issue is that the Dockerfile documentation doesn't cover this important topic nearly enough. It's brushed over (which is a nice way to say omitted completely) and newbies don't discover that their Dockerfiles should be parameterized with uid and gid until they run into this problem. Most never figure it out. Let's hope GPT4 knows.

[con-f-use]

I'm sure after almost 10 years someone could have come up with a better-than-nothing solution. Be it having the docker daemon creating a mount group on the host and then injecting that into the container when an rw mount is requested (not saying that is good), but something...

[neersighted]

This is a duplicate of #2259; and ultimately depends on #28593.