Docker：具有 --volume 绑定挂载的文件权限

Question

I'm following the guidelines from: https://denibertovic.com/posts/handling-permissions-with-docker-volumes/ to setup a --volume bind mount in my container and creating a user in the guest container with the same UID as my host user - the theory being that my container user should be able to access the mount. It's not working for me and I'm looking for some pointers to try next.

More background details:

My Dockerfile starts from an alpine base and adds python dev packages. It copies across an entrypoint.sh script per guidelines from denibertovic. It then jumps to the entrpoint.sh script.

FROM alpine

RUN apk update
RUN apk add bash
RUN apk add python3
RUN apk add python3-dev
RUN apk add su-exec

COPY entrypoint.sh /usr/local/bin/entrypoint.sh
RUN chmod +x  /usr/local/bin/entrypoint.sh

ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]

The entrpoint.sh script adds a user to the container with the UID passed in as an environment variable.

#!/bin/bash

# Add local user
# Either use the LOCAL_USER_ID if passed in at runtime or
# fallback

USER_ID=${LOCAL_USER_ID:-9001}

echo "Starting with UID : $USER_ID"
adduser -s /bin/bash -u $USER_ID -H -D user
export HOME=/home/user

su-exec user "$@"

The container builds no problem. I then run it with the following command line:

sudo docker run -it -e LOCAL_USER_ID=`id -u` -v `realpath ../..`:/ws django-runtime /bin/bash

You'll see that I'm passing in my host UID to be mapped to the container user's UID and I'm asking for a volume bind mount from my local working directory to the /ws mountpoint in the container.

From the bash shell inside the container I can see that /ws is owned by the 'user' UID matching my own 'id'. However, when I go to list the contents of /ws I get a Permission Denied error as follows:

[dleclair@localhost runtime]$ sudo docker run -it -e LOCAL_USER_ID=`id -u` -v `realpath ../..`:/ws django-runtime /bin/bash
[sudo] password for dleclair:
Starting with UID : 1000
bash-5.0$ id
uid=1000(user) gid=1000(user) groups=1000(user)
bash-5.0$ ls -la .
total 0
drwxr-xr-x    1 root     root            27 Feb  8 09:15 .
drwxr-xr-x    1 root     root            27 Feb  8 09:15 ..
-rwxr-xr-x    1 root     root             0 Feb  8 09:15 .dockerenv
drwxr-xr-x    1 root     root            18 Feb  8 07:44 bin
drwxr-xr-x    5 root     root           360 Feb  8 09:15 dev
drwxr-xr-x    1 root     root            91 Feb  8 09:15 etc
drwxr-xr-x    2 root     root             6 Jan 16 21:52 home
drwxr-xr-x    1 root     root            17 Jan 16 21:52 lib
drwxr-xr-x    5 root     root            44 Jan 16 21:52 media
drwxr-xr-x    2 root     root             6 Jan 16 21:52 mnt
drwxr-xr-x    2 root     root             6 Jan 16 21:52 opt
dr-xr-xr-x  119 root     root             0 Feb  8 09:15 proc
drwx------    2 root     root             6 Jan 16 21:52 root
drwxr-xr-x    1 root     root            21 Feb  8 07:44 run
drwxr-xr-x    1 root     root            21 Feb  8 08:22 sbin
drwxr-xr-x    2 root     root             6 Jan 16 21:52 srv
dr-xr-xr-x   13 root     root             0 Feb  8 01:58 sys
drwxrwxrwt    2 root     root             6 Jan 16 21:52 tmp
drwxr-xr-x    1 root     root            19 Feb  8 07:44 usr
drwxr-xr-x    1 root     root            19 Jan 16 21:52 var
drwxrwxr-x    5 user     user           111 Feb  8 02:15 ws
bash-5.0$
bash-5.0$
bash-5.0$ cd /ws
bash-5.0$ ls -la
ls: can't open '.': Permission denied
total 0
bash-5.0$

Appreciate any pointers anyone can offer. Thanks!

Answer 1

After more searching I found the answer to my problem here: Permission denied on accessing host directory in Docker and here: http://www.projectatomic.io/blog/2015/06/using-volumes-with-docker-can-cause-problems-with-selinux/ .

In short, the problem was with the SELinux default labels for the volume mount blocking access to the mounted files. The solution was to add a ':Z' trailer to the -v command line argument to force docker to set the appropriate flags against the mounted files to allow access.

The command line therefore became:

sudo docker run -it -e LOCAL_USER_ID=`id -u` -v `realpath ../..`:/ws:Z django-runtime /bin/bash

Worked like a charm.