In Docker for Windows, permissions denied for mkdir/chown

I’m working on developing a ghost blog and deploying it as a docker container. Since one of the goals of my project is to develop themes and other things with live data, I’ve created a volume mount for the /var/lib/ghost directory as suggested by the ghost docker image.

The ghost docker image mounts the drive fine, but when it tries to chown the file, it gets a permission denied error. I’m running the Creator update of Windows 10, and the latest Docker for Windows (ie, Windows 10 Pro versin 1703, and Docker version 17.03.1-ce-win5)

As a test, I followed this procedure, at both home and work (where I’m on the previous version of windows 10):

1. Create a Project\site directory in C:\users\joe\
2. Place the docker-compose.yml file below the directory:
3. Run docker-compose up

On my work machine, it creates the blog directory, and populates it with the themes and content as expected from a ghost blog.

On my home machine, I get this error:

ERROR: for blog Cannot start service blog: error while creating mount source path ‘/C/Users/joe/Projects/site/blog’: mkdir /C/Users/joe/Projects/site/blog: permission denied ERROR: Encountered errors while bringing up the project.

if I make the directory myself, and run docker-compose.yml again, I get this error:

blog_1 | chown: changing ownership of ‘/var/lib/ghost’: Permission denied

site_blog_1 exited with code 1

Mounting directories definitely works, I’ve run the alpine ls /data example shown on the settings for shared drives in Docker for Windows.

I’ve compared the settings in docker, on the virtual networks, on the directories between home and work — the only differences I can find are because work is on a Domain, and has a different username, and that my version of windows is 1607.

I don’t know if this is a bug, a bad interaction between current windows && docker, or something I’ve done wrong locally. I admit I’m leaning toward the latter because I can find no documentation about this anywhere.

3 Answers 3

answers the question.

I unshared C, reshared it and still had the problem. I clicked «reset credentials» and then reshared it (entering my password) and it worked.

I struggled with this issue on Windows 10 for quite some time. The solution was a combination of suggestions I found on the internet — given that the directory you want to share is below your user directory:

How to fix docker: Got permission denied issue

I installed Docker in my machine where I have Ubuntu OS.
When I run:

All is ok, but I want to hide the word sudo to make more short the command.
If I write the command without the word sudo

That displays the following:

docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.35/containers/create: dial unix /var/run/docker.sock: connect: permission denied. See ‘docker run —help’.

It has happened the same when I try to make:

How can I resolve this?

26 Answers 26

If you want to run docker as non-root user then you need to add it to the docker group.

1. Create the docker group if it does not exist

1. Add your user to the docker group.

1. Run the following command or Logout and login again and run (that doesn’t work you may need to reboot your machine first)

1. Check if docker can be run without root

Reboot if still got error

Taken from the docker official documentation: manage-docker-as-a-non-root-user

After an upgrade I got the permission denied. Doing the steps of ‘mkb’ post install steps don’t have change anything because my user was already in the ‘docker’ group; I retry-it twice any way without success.

After an search hour this following solution finaly worked :

Solution came from Olshansk.

Look like the upgrade have recreate the socket without enough permission for the ‘docker’ group.

Problems

This hard chmod open security hole and after each reboot, this error start again and again and you have to re-execute the above command each time. I want a solution once and for all. For that you have two problems :

1) Problem with SystemD : The socket will be create only with owner ‘root’ and group ‘root’.

You can check this first problem with this command :

If every this is good, you should see ‘ root/docker ‘ not ‘ root/root ‘.

You can check this second problem with this command :

If everything is correct you should see the docker group in the list. If not try the command

if you see then the docker group it is because of the bug.

Solutions

If you manage to to get a workaround for the graphical login, this should do the job :

But If you can’t manage this bug, a not so bad solution could be this :

This work because you are in a graphical environnement and probably the only user on your computer. In both case you need a reboot (or an sudo chmod 666 /var/run/docker.sock )

1. Add docker group

1. Add your current user to docker group

1. Switch session to docker group

1. Run an example to test

1. Add current user to docker group

1. Change the permissions of docker socket to be able to connect to the docker daemon /var/run/docker.sock

I solve this error with the command :

You can always try Manage Docker as a non-root user paragraph in the https://docs.docker.com/install/linux/linux-postinstall/ docs.

After doing this also if the problem persists then you can run the following command to solve it:

Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.40/images/json: dial unix /var/run/docker.sock: connect: permission denied

This fix my problem.

To fix that issue, I searched where is my docker and docker-compose installed. In my case, docker was installed in /usr/bin/docker and docker-compose was installed in /usr/local/bin/docker-compose path. Then, I write this in my terminal:

Now I don’t need write in my commands docker the word sudo

The best solution of this issue was commented by @mkasberg. I quote comment:

That might work, you might run into issues down the road. Also, it’s a security vulnerability. You’d be better off just adding yourself to the docker group, as the docs say. sudo groupadd docker, sudo usermod -aG docker $USER. Docs: https://docs.docker.com/install/linux/linux-postinstall/

Seriously guys. Do not add Docker in your groups or modifies the socket posix (without a hardening SELinux), it’s a simple way to make a root privesc. Just add an alias in your .bashrc, it’s simpler and safer as : alias dc=’sudo docker’.

Rebooting the machine worked for me.

lightdm and kwallet ship with a bug that seems to not pass the supplementary groups at login. To solve this, I also, beside sudo usermod -aG docker $USER , had to comment out

in /etc/pam.d/lightdm before rebooting, for the docker-group to actually have effect.

you can follow these steps and this will work for you:

1. create a docker group sudo groupadd docker
2. add your user to this group sudo usermod -aG docker $USER
3. list the groups to make sure that docker group created successfully by running this command groups
4. run the following command also to change the session for docker group newgrp docker
5. change the group ownership for file docker.sock sudo chown root:docker /var/run/docker.sock
6. change the ownership for .docker directory sudo chown «$USER»:»$USER» /home/»$USER»/.docker -R
7. finally sudo chmod g+rwx «$HOME/.docker» -R

After that test you can run docker ps -a

It only requires the changes in permission of sock file.

this will work definately.

use this command

then restart your computer this worked for me.

This work for me:

Get inside the container and modify the file’s ACL

It’s a better solution than use chmod.

We always forget about ACLs . See setfacl .

sudo setfacl -m user:$USER:rw /var/run/docker.sock

i try this commend with sudo commend and it was ok. sudo docker pull hello-world or sudo docker run hello-world

After Docker Installation on Centos. While running below command I got below error.

Change Group and Permission for docker.socket

Verify by using below docker command

After you installed docker, created ‘docker’ group and added user to it, edit docker service unit file:

Add two lines into the section [Service]:

Save the file (Ctrl-X, y, Enter)

Run and enable the Docker service:

I ran into a similar problem as well, but where the container I wanted to create needed to mount /var/run/docker.sock as a volume (Portainer Agent), while running it all under a different namespace. Normally a container does not care about which namespace it is started in — that is sort of the point — but since access was made from a different namespace, this had to be circumvented.

Adding —userns=host to the run command for the container enabled it to use the attain the correct permissions.

Quite a specific use case, but after more research hours than I want to admit I just thought I should share it with the world if someone else ends up in this situation 🙂

It is definitely not the case the question was about, but as it is the first search result while googling the error message, I’ll leave it here.

First of all, check if docker service is running using the following command:

systemctl status docker.service

If it is not running, try starting it:

sudo systemctl start docker.service

. and check the status again:

systemctl status docker.service

If it has not started, investigate the reason. Probably, you have modified a config file and made an error (like I did while modifying /etc/docker/daemon.json )

In Linux environment, after installing docker and docker-compose reboot is required for work docker better.

OR restart the docker

The Docker daemon binds to a Unix socket instead of a TCP port. By default that Unix socket is owned by the user root and other users can only access it using sudo. The Docker daemon always runs as the root user.

If you don’t want to preface the docker command with sudo, create a Unix group called docker and add users to it. When the Docker daemon starts, it creates a Unix socket accessible by members of the docker group.

To create the docker group and add your user:

Create the docker group

Add your user to the docker group

Log out and log back in so that your group membership is re-evaluated.

If testing on a virtual machine, it may be necessary to restart the virtual machine for changes to take effect.

On a desktop Linux environment such as X Windows, log out of your session completely and then log back in.

On Linux, you can also run the following command to activate the changes to groups:

Verify that you can run docker commands without sudo. The below command downloads a test image and runs it in a container. When the container runs, it prints an informational message and exits

If you initially ran Docker CLI commands using sudo before adding your user to the docker group, you may see the following error, which indicates that your

/.docker/ directory was created with incorrect permissions due to the sudo commands.

To fix this problem, either remove the

/.docker/ directory (it is recreated automatically, but any custom settings are lost), or change its ownership and permissions using the following commands:

Why does docker container prompt “Permission denied”?

I use following command to run a docker container, and map a directory from host( /root/database ) to container( /tmp/install/database ):

But in container, I find I can’t use ls to list contents in /tmp/install/database/ though I am root and have all privileges:

I check /root/database in host, and all things seem OK:

Why does docker container prompt «Permission denied»?

Update:
The root cause is related to SELinux . Actually, I met similar issue last year.

4 Answers 4

A permission denied within a container for a shared directory could be due to the fact that this shared directory is stored on a device. By default containers cannot access any devices. Adding the option $docker run —privileged allows the container to access all devices and performs Kernel calls. This is not considered as secure.

A cleaner way to share device is to use the option docker run —device=/dev/sdb (if /dev/sdb is the device you want to share).

From the man page:

I had a similar issue when sharing an nfs mount point as a volume using docker-compose. I was able to resolve the issue with:

Eventhough you found the issue, this may help someone else.

Another reason is a mismatch with the UID/GID. This often shows up as being able to modify a mount as root but not as the containers user

You can set the UID, so for an ubuntu container running as ubuntu you may need to append :uid=1000 (check with id -u ) or set the UID locally depending on your use case.

Set the owner and group of the files in the filesystem (default: uid=gid=0)

There is a good blog about it here with this tmpfs example

man docker-run gives the proper answer:

Labeling systems like SELinux require that proper labels are placed on volume content mounted into a container. Without a label, the security system might prevent the processes running inside the container from using the content. By default, Docker does not change the labels set by the OS.

To change a label in the container context, you can add either of two suffixes :z or :Z to the volume mount. These suffixes tell Docker to relabel file objects on the shared volumes. The z option tells Docker that two containers share the volume content. As a result, Docker labels the content with a shared content label. Shared volume labels allow all containers to read/write content. The Z option tells Docker to label the content with a private unshared label. Only the current container can use a private volume.