6

Versions

  • Host OS: Debian 4.9.110
  • Docker Version: 18.06.1-ce

Scenario

I have a directory where multiple users (user-a and user-b) have read/write access through a common group membership (shared), set up via chown:

/media/disk-a/shared/$ ls -la
drwxrwsr-x 4 user-a shared 4096 Oct  7 22:21 .
drwxrwxr-x 7 root   root   4096 Oct  1 19:58 ..
drwxrwsr-x 5 user-a shared 4096 Oct  7 22:10 folder-a
drwxrwsr-x 3 user-a shared 4096 Nov 10 22:10 folder-b

UIDs & GIDs are as following:

uid=1000(user-a) gid=1000(user-a) groups=1000(user-a),1003(shared)
uid=1002(user-b) gid=1002(user-b) groups=1002(user-b),1003(shared)

Relevant /etc/group looks like this:

shared:x:1003:user-a,user-b

When suing into both users, files can be created as expected within the shared directory.

The shared directory is attached to a Docker container via mount binds to /shared/. The Docker container runs as user-b (using the --user "1002:1002" parameter)

$ ps aux | grep user-b
user-b     1347  0.2  1.2 1579548 45740 ?       Ssl  17:47   0:02 entrypoint.sh

id from within the container prints the following, to me okay-looking result:

I have no name!@7a5d2cc27491:/$ id
uid=1002 gid=1002

Also ls -la mirrors its host system equivalent perfectly:

I have no name!@7a5d2cc27491:/shared ls -la
total 16
drwxrwsr-x 4 1000 1003 4096 Oct  7 20:21 .
drwxr-xr-x 1 root root 4096 Oct  8 07:58 ..
drwxrwsr-x 5 1000 1003 4096 Oct  7 20:10 folder-a
drwxrwsr-x 3 1000 1003 4096 Nov 10 20:10 folder-b

Problem

From within the container, I cannot write anything to the shared directory. For touch test I get the following i.e.:

I have no name!@7a5d2cc27491:/shared$ touch test
touch: cannot touch 'test': Permission denied

I can write to a directory which is directly owned by user-b (user & group) and mounted to the container... Simply the group membership seems somehow not to be respected at all.

I have looked into things like user namespace remapping and things, but these seemed to be solutions for something not applying here. What do I miss?

manu
  • 967
  • 1
  • 11
  • 28

1 Answers1

2

Your container user has gid=1002, but is not member of group shared with gid=1003.

Additionally to --user "1002:1002" you need --group-add 1003. Than the container user is allowed to access the shared folder with gid=1003.

id should show:

I have no name!@7a5d2cc27491:/$ id
uid=1002 gid=1002 groups=1003
mviereck
  • 1,309
  • 1
  • 12
  • 15
  • 1
    Indeed! This solves my problem. Since I use docker-compose though, I had to set the docker-compose file version to "2" because revision 3 does not support group_add anymore. Thanks a lot @mviereck! – manu Oct 09 '18 at 06:06
  • 1
    You're welcome! If you would need docker-compose 3 without group-add support, you can create custom `/etc/passwd` and `/etc/group`. As a quick'n'dirty test you can share the files from host. Nice side effect: your container user will have a name. – mviereck Oct 09 '18 at 07:35
  • I don't know a lot about the mounting operations, but seems that if you change mounting options in fstab, for example, you have to force the OS to recognize the changes. "mount -a" doesn't do it for me. You can use "systemctl daemon-reload" to get the system to see the changes. However it doesn't work in WSL since WSL uses init instead of systemctl. I had to kill wsl ("wsl --shutdown") and start it up again. Then had to restart docker to get it reconnected in WSL. A huge pain, but finally got the shared mount and group permissions all working. – callmejed Mar 22 '22 at 18:28