How to change the owner of VOLUME directory in Dockerfile?

Question

I've got the following Dockerfile:

FROM ubuntu:xenial
RUN useradd -d /home/ubuntu -ms /bin/bash -g root -G sudo -p ubuntu ubuntu
WORKDIR /home/ubuntu
USER ubuntu
VOLUME /opt/myvolume

Which I built it:

$ docker build -t vol-test .
Sending build context to Docker daemon  2.048kB
Step 1/5 : FROM ubuntu:xenial
 ---> 0b1edfbffd27
Step 2/5 : RUN useradd -d /home/ubuntu -ms /bin/bash -g root -G sudo -p ubuntu ubuntu
 ---> Using cache
 ---> d82e3ecc5fe8
Step 3/5 : WORKDIR /home/ubuntu
 ---> Using cache
 ---> ab1db29ee8bf
Step 4/5 : USER ubuntu
 ---> Using cache
 ---> 129393a35d9e
Step 5/5 : VOLUME /opt/myvolume
 ---> Running in 691a4cbd077e
Removing intermediate container 691a4cbd077e
 ---> 11bc9e9db9d3
Successfully built 11bc9e9db9d3
Successfully tagged vol-test:latest

However, when run, the /opt/myvolume directory is owned by root, not ubuntu:

$ docker run vol-test id
uid=1000(ubuntu) gid=0(root) groups=0(root),27(sudo)
$ docker run vol-test find /opt/myvolume -ls
    66659      4 drwxr-xr-x   2 root     root         4096 Jul 18 23:02 /opt/myvolume
$ docker run -u ubuntu vol-test find /opt/myvolume -ls
    66940      4 drwxr-xr-x   2 root     root         4096 Jul 18 23:12 /opt/myvolume

because it's created during the run.

Is it possible to define or change the default owner of VOLUME directory in Dockerfile?

I'm running it on macOS and Linux.

Solution 1

As stated in the documentation, VOLUME instruction inherits the directory content and permissions existing in the container, so you can workaround the problem with a dockerfile like this:

FROM ubuntu:xenial
RUN useradd -d /home/ubuntu -ms /bin/bash -g root -G sudo -p ubuntu ubuntu
RUN mkdir /opt/myvolume  && chown ubuntu /opt/myvolume
WORKDIR /home/ubuntu
VOLUME /opt/myvolume

The creation of the directory has to be done as root (to be able to write within /opt).

Solution 2

I had a similar problem, this worked for me:

1. Write Docker file with:

   # Create app layer:
   FROM python:3.4
   # Create app user & group "testuser" with IDs:
   RUN groupadd -r testuser --gid 1234 && useradd -d /home/testuser -ms /bin/bash -r -g testuser testuser --uid 1234
   # Create "testuser" working dir:
   WORKDIR /home/testuser
   # Make working dir known to Python    
   ENV PYTHONPATH "${PYTHONPATH}:/home/testuser"
   # Create & mount shared storage:
   RUN mkdir /var/run/testuser-storage
   VOLUME ["/var/run/testuser-storage"]
   # Start container as "testuser":
   ENV NAME testuser
   ENV HOME /home/testuser
   USER testuser
   

2. Run these bash commands:

   # Create the same user & group "testuser" with IDs on host:
   getent group testuser > /dev/null || /usr/sbin/groupadd -r testuser --gid 1234
   getent passwd testuser > /dev/null || /usr/sbin/useradd -r -g testuser -d /var/lib/testuser -s /bin/nologin testuser --uid 1234
   # Create shared storage dirs on host:
   mkdir /var/run/testuser-storage
   chown -R testuser.testuser /var/run/testuser-storage
   # Build and run "testuser" Docker image:
   docker build . -t testuser
   docker run --net host --name testuser -v /var/run/testuser-storage:/var/run/testuser-storage -d testuser
   # Change ownership of shared volume dir to the be the GID of "testuser"
   chown -R 1234:1234 /var/run/testuser-storage
   

Note the names, UID's ,GID's must be the same for the Docker user and the host user. The last bash command tells the Docker image that that host user is the same as the Docker shared volume dir user, so that file dir then becomes owned by the "testuser" in the Docker container.

Comments

[Admin]

Related: Sharing volumes to Docker as the right user.

[Admin]

Related: How to manage volume permissions to share data between host and container?

[CubeBot88]

ALSO, in some environments, SELinux can prevent file access. This can be resolved by either temporarily or permanently disabling SELinux (though I strongly advised against permanent disabling). A guide on this can be found here: tecmint.com/…

[Tensibai]

The dir creation is unrelated, a volume will be mounted out of the container so anything done within the container before mount (container launched) will be discarded. I don't really understand your comment