How to give non-root user in Docker container access to a volume mounted on the host

Question

I am running my application in a Docker container as a non-root user. I did this since it is one of the best practices. However, while running the container I mount a host volume to it -v /some/folder:/some/folder . I am doing this because my application running inside the docker container needs to write files to the mounted host folder. But since I am running my application as a non-root user, it doesn't have permission to write to that folder

Question

Is it possible to give a nonroot user in a docker container access to the hosted volume?

If not, is my only option to run the process in docker container as root?

Ingroup

Answer 1

There's no magic solution here: permissions inside docker are managed the same as permissions without docker. You need to run the appropriate chown and chmod commands to change the permissions of the directory.

One solution is to have your container run as root and use an ENTRYPOINT script to make the appropriate permission changes, and then your CMD as an unprivileged user. For example, put the following in entrypoint.sh:

#!/bin/sh

chown -R appuser:appgroup /path/to/volume
exec runuser -u appuser "$@"

This assumes you have the runuser command available. You can accomplish pretty much the same thing using sudo instead.

Use the above script by including an ENTRYPOINT directive in your Dockerfile:

FROM baseimage

COPY entrypoint.sh /entrypoint.sh
ENTRYPOINT ["/bin/sh", "entrypoint.sh"]
CMD ["/usr/bin/myapp"]

This will start the container with:

/bin/sh entrypoint.sh /usr/bin/myapp

The entrypoint script will make the required permissions changes, then run /usr/bin/myapp as appuser.

Macroscopic

I think this would work. To make this more general, is there a way to replace /path/to/volume with the parameters given to -v command when running the container? For example if container is run with -v /some/path:/some/path then the chown command in entrypoint.sh becomes chown -R appeaser:appuser /some/path. Rather than hardcoding a volume name in entrypoint.sh – Ingroup

There's no way within the container to introspect available volume paths, but you could pass in an environment variable (docker run -v /some/path:/some/path -e MYVOLUME=/some/path ...), and then use $MYVOLUME in your ENTRYPOINT script. – Macroscopic

ugh. I am getting an error runuser not found. How can I get that command? I am using ubuntu image.. – Ingroup

Like I said, you can instead use sudo. As in sudo -u appuser somecommand. Or with a little work you could just use su, although I find the syntax less useful. – Macroscopic

@Macroscopic "have your container run as root" defies the purpose of a non-root container. – Gargantua

@Gargantua I disagree. I think starting your container as root and then switching to a non-root user in your ENTRYPOINT script gets you exactly the same level of security. In either case, your service is not running as the root user. – Macroscopic

This is great, but can you still pass in argument to your app in run-time? – Bingo

If you design your entrypoint script appropriately, sure. Nothing here changes the way Docker works. – Macroscopic

@Macroscopic - I must (politely) disagree with your disagreement. I'm no expert here but a quick Google turned up (pythonspeed.com/articles/root-capabilities-docker-security for details) which explains why starting as root and then de-escalating inside the container does not give the same level of security as you'd get by specifying a non-root user via the USER keyword in a Dockerfile. – Miscalculate

FYI: I turned this security discussion to another question: ( #65574834 ). So far the answers seem to suggest that while it isn't the same level of security, it is an accepted approach. – Guinea

Answer 2

There will throw error if host env don't have appuser or appgroup, so better to use a User ID instead of user name:

inside your container, run

appuser$ id

This will show:

uid=1000(appuser) gid=1000(appuser) groups=1000(appuser)

From host env, run:

mkdir -p /some/folder
chown -R 1000:1000 /some/folder
docker run -v /some/folder:/some/folder [your_container]

inside your container, check

ls -lh

to see the user and group name, if it's not root, then it's should worked.

Glynisglynn

Is there something we can do if appuser is not installed? – Gwendolyn

@Gwendolyn appuser is not a tool, but some username, like admin etc., decided by your container's USER admin instruction. – Glynisglynn

Oh I’m dumb —I didn’t make the distinction it was app” “user” and not the new word “appuser” – Gwendolyn

@Gwendolyn it's alright, I've made the same mistake – Kuching

Is this really possible even if on the host there is no user / group with this ID? Sounds strange – Thalia

This doesn't work for me using "Docker version 20.10.21, build 20.10.21-0ubuntu1~20.04.2". I can see that the mount point folder gest created and gets the correct user and permissions, if I start the image without "-v". But as soon as I run the image and mount a volume on the folder, it gets the uid:gid combination of the folder on the host machine. – Corazoncorban

Answer 3

In the specific situation of using an image built from a custom Dockerfile, you can do the following (using example commands for a debian image):

    FROM baseimage
    ...
    RUN useradd --create-home appuser
    USER appuser
    RUN mkdir /home/appuser/my_volume
    ...

Then mount the volume using

-v /some/folder:/home/appuser/my_volume

Now appuser has write permissions to the volume as it's in their home directory. If the volume has to be mounted outside of their home directory, you can create it and assign appuser write permissions as an extra step within the Dockerfile.

Photosynthesis

Thank you that is a very good answer. The best. – Bifrost

Answer 4

I found it easiest to recursively apply Linux ACL (Access Control Lists) permissions on the host directory so the non root host user can access volume contents.

sudo setfacl -m u:$(id -u):rwx -R /some/folder

To check who has access to the folder:

getfacl /some/folder

Writing to the volume will create files and directories with host user id which might not be desirable for host -> container transfer. Writing can be disabled with just giving :rx permission instead of :rwx.

To enable writing, add a mirror ACL policy in a container allowing container user id full access to volume parent path.

Peroxy

Answer 5

For a comprehensive analysis and a SOLUTION that works with Docker in rootless mode (or Podman, to be more specific), see here:

https://github.com/mamba-org/micromamba-docker/issues/407#issuecomment-2088523507

Countrybred