Docker Volume Mount Permission Denied 2018


Docker and permissions management. Set up a reverse proxy with Nginx and Docker-gen (Bonus: Let's Encrypt) Tips and reminders for using Docker daily. In this first post, I will show how you can deal with file permissions when a container is using root and you want to keep access to the files as an unprivileged host user. Mount error(13): Permission denied Refer to the mount.cifs(8) manual page (e.g. Man mount.cifs) How to Proceed / Suggestions? So that’s where I’m at. As you can see, I’m not asking out of the blue and have invested tons of time researching and testing. Any suggestions you have would be greatly appreciated. Thank You & Happy Holidays! Dry storage racks.

Docker requires root escalation in order to execute an image, that crates some problem with files creation. Let’s say that we share a volume from host to docker and we create a file structure from inside docker.

This can be illustrated by an code snippet

Why this is even an issue? I’ve found this problem mostly annoying on local setup, as I need to use sudo for simple hause-keeping tasks. Another case when it’s very problematic is to use docker on Jenkins – as this prevents to remove workspace after a job is done.

#1 – Run docker as a specific user

#1.1 Simple case

Docker can be run with -u switch that enables user mapping, which is kind of cool as we can basically access mounted volumes as ourselves.

Looks like everything works. Right? There is some caveat, as we use hosts UID and GID, that might be not reflected inside docker image, we’re loosing $HOME folder

#1.2 Case of missing HOME

This issue is problematic, because if we’ll run for the instance npm install command, then npm will try to create a file inside ~/.npm path, which effectively is ${HOME}/.npm and because HOME is empty as there might be no user with requested id, it will be resolved to /.npm which eventually leads to permission denied error.

Docker Mount Permission Denied

Even the official node image has this problem driven by an assumption that every base linux user is 1000:1000

And it can be reproduced simply with following script

And output is:

Where if we use -u 1000:1000 it works as expected:

This solution adds some extra work on maintainer:
* A user has to be created by Dockerfile (i.e. touch ~/.test doesn’t work on debian image with -u 1000:1000 as no user is created
* Every folder that possible can be used to write information, has to be non-root friendly. One example what I faced was that Emscripten was using a cache folder inside installation of Emscripten.

#1.3 Making a fake home

This can be achieved simply by setting -e HOME=/tmp for running container. Then following example will work even if your local userId isn’t 1000

Other test case which will work now

#2 – Use umask

This is slightly more intrusive, as either requires to prepend commands that run in docker, create custom image (that derives from an original image).
What’s needed is to add umask 0000

#2.1 Prepend executed command

#2.2 Create custom Dockerimage

Content of

Content of Dockerfile

Although it looks fairly simple, it doesn’t cover all cases. umask works only for newly created file, if a file has been copied/moved then we have to support it in a different way.


#2.3 Ugly case of copying folders

The base issue is that cp command preserves access mask but changes owner to the current user. Effectively what it does mean is that files copied while being a docker inside mounted volume getting root as an owner. For files it might be not a big issue as we might still be able to modify / remove such files if other permission mask is allows us.

Unfortunately this is not a case for copied folders.

Here is an example that illustrates this issue:

Result from running it:

Docker Volume Mount Permission Denied

It is possible to make it run of course, simple chmod -R 777 solves it. But this hack can’t be used everywhere as it might significantly impact performance in case of large volumes mounted. Which is a case of mine, where I use Docker for compilation of large C++ projects.


Making Docker container to produce files inside mounted volume that don’t require root for removing isn’t easy task and frequently requires that wanted Docker image needs to be constructed in such a way that allows to use it as non-root user.

Docker Volume Mount Permission Denied 2018

Frequently Dockerfiles don’t create a standard user, and even if they do, we shouldn’t assume that created user inside Docker Image has the same UID and GID like user on host machine. If they don’t, it’s possible to override HOME environment variable to trick applications that use ~ for storing some cache/settings files.

Running Docker Image as root but setting umask isn’t a perfect solution as when copying of folders inside mounted volume is performed by an operation inside running docker, then root becomes an owner of it, which will cause permission denied, when trying to remove it as a local non-root user.