Docker with '--user' can not write to volu

Question

I've played a lot with any rights combinations to make docker to work, but... at first my environment:

Ubuntu linux 15.04 and Docker version 1.5.0, build a8a31ef.

I have a directory '/test/dockervolume' and two users user1 and user2 in a group users

chown user1.users /test/dockervolume
chmod 775 /test/dockervolume
ls -la
drwxrwxr-x  2 user1 users 4096 Oct 11 11:57 dockervolume

Either user1 and user2 can write delete files in this directory. I use standard docker ubuntu:15.04 image. user1 has id 1000 and user2 has id 1002.

I run docker with next command:

docker run -it --volume=/test/dcokervolume:/tmp/job_output --user=1000 --workdir=/tmp/job_output ubuntu:15.04 

Within docker I just do simple 'touch test' and it works for user1 with id 1000. When I run docker with --user 1002 I can't write to that directory:

I have no name!@6c5e03f4b3a3:/tmp/job_output$ touch test2
touch: cannot touch 'test2': Permission denied
I have no name!@6c5e03f4b3a3:/tmp/job_output$ 

Just to be clear both users can write to that directory if not in docker.

So my question is this behavior by docker design or it is a bug or I missed something in the manual?

Answer 1

For both correct uid and gid mapping try: docker run --user=$(id -u):$(id -g)

Answer 2

Avoid use another use, because the UID is different and you can't sure about the user name. You can use root without problem inside container.

Answer 3

docker's --user parameter changes just id not a group id within a docker. So, within a docker I have:

id
uid=1002 gid=0(root) groups=0(root)

and it is not like in original system where I have groups=1000(users)

So, one workaround might be mapping passwd and group files into a docker.

-v /etc/docker/passwd:/etc/passwd:ro -v /etc/docker/group:/etc/group:ro

The other idea is to map a tmp directory owned by running --user and when docker's work is complete copy files to a final location

 TMPFILE=`mktemp`; docker run -v $TMPFILE:/working_dir/ --user=$(id -u); cp $TMPDIR $NEWDIR

This discussion Understanding user file ownership in docker: how to avoid changing permissions of linked volumes brings some light to my question.