docker.sock permission denied
Did you re-login after making that change? The change is not available in the same session. Also does sudo docker ps work for you?
You have to restart the docker daemon, otherwise it won’t let members of the docker group to control the docker daemon
12 Answers 12
For those new to the shell, the command:
$ sudo usermod -aG docker $USER needs to have $USER defined in your shell. This is often there by default, but you may need to set the value to your login id in some shells.
Changing the groups of a user does not change existing logins, terminals, and shells that a user has open. To avoid performing a login again, you can simply run:
to get access to that group in your current shell.
Once you have done this, the user effectively has root access on the server, so only do this for users that are trusted with unrestricted sudo access.
I tried every other trick in this thread, followed the docs, reinstalled Docker to a newer version, rebooted plenty of times, everything I thought about. I am indeed in the docker group, but the default shell won’t acknowledge it (maybe a problem with a script in my .profile?). Other than sudoing to the root user, only that newgrp command worked.
@BrunoLaturner If you are on Ubuntu, I’ve heard of LightDM causing an issue where it drops secondary groups from the login user.
@BMitch are you in NSA spying me? That is my exact config and bug. Thanks! Solved following askubuntu.com/q/1057258/259660
Reason: The error message means that the current user can’t access the docker engine, because the user hasn’t enough permissions to access the UNIX socket to communicate with the engine.
- Run the command as root using sudo.
sudo chown $USER /var/run/docker.sock Caution: Running sudo chmod 777 /var/run/docker.sock will solve your problem but it will open the docker socket for everyone which is a security vulnerability as pointed out by @AaylaSecura. Hence it shouldn’t be used, except for testing purposes on the local system.
Permanent Solution:
Add the current user to the docker group.
sudo usermod -a -G docker $USER Note: You have to log out and log in again for the changes to take effect.
Refer to this blog to know more about managing Docker as a non-root user.
You’re probably missing out on votes because people log out then forget to come back and upvote lols.
I bet they’re missing the upvotes cause the «Quick Fix» is a security disaster. The docker socket should never be accessible to world.
@AaylaSecura Yes, you’re right. I had added it as a quick fix but again it’s a bad practice. I have changed it in the answer now. Feel free to comment if you think It can be improved.
this was the solution that worked for me. thanks. the ownership of the docker.sock file was of root so no logout would ever fix it.
I needed to restart the PC, for some reason logout and login did not work and I spend a lot of time troubleshooting this problem.
$ echo $USER $ sudo usermod -aG docker $USER $ sudo systemctl restart docker $ docker ps Restarting the Docker daemon was a big one. Always forget to do that after adding user to Docker group :\
There should be no need to restart the daemon, it’s root, and already configured the socket to run as docker. The only thing I can think it fixes is if you modified the socket permissions.
I actually had to reboot the computer, wtf. Logout and login did not help. newgrp worked, but re-login or sudo systemctl restart docker did NOT work in my case. weird, but in case somebody else wonders.
enter the command and explore docker without sudo command
sudo chmod 666 /var/run/docker.sock Remember that anyone who can access the Docker socket can trivially root the entire host; running this command allows any local process to do that.
As mentioned earlier in the comment the changes won’t apply until your re-login. If you were doing a SSH and opening a new terminal, it would have worked in new terminal
But since you were using GUI and opening the new terminal the changes were not applied. That is the reason the error didn’t go away
So below command did do its job, its just a re-login was missed
sudo usermod -aG docker $USER You need to manage docker as a non-root user. To create the docker group and add your user:
- Create the docker group. $ sudo groupadd docker
- Add your user to the docker group. $ sudo usermod -aG docker $USER
- 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:
***Important Note on these answers: the docker group is not always «docker» sometimes it is «dockerroot», for example the case of Centos 7 installation by
sudo yum install -y docker The first thing you should do, after installing Docker, is
it should say something like
. sshd:x:74: postdrop:x:90: postfix:x:89: yourusername:x:1000:yourusername cgred:x:996: dockerroot:x:995: In this case, it is «dockerroot» not «docker». So,
sudo usermod -aG dockerroot yourusername logout As my user is and AD user, I have to add the AD user to the local group by manually editing /etc/group file. Unforrtunately the adduser commands do not seem to be nsswitch aware and do not recognize a user not locally defined when adding someone to a group.
Then reboot or refresh /etc/group. Now, you can use docker without sudo.
When I try to run simple docker commands like: $ docker ps -a
I get an error message: Got permission denied . /var/run/docker.sock: connect: permission denied .
[…] How can I fix it?
TL;DR: There are two ways (the first one, also mentioned in the question itself, was extensively addressed by other answers, but comes with security concerns; so I’ll elaborate on this issue, and develop the second solution that can also be applicable for this fairly sensible use case).
Just to recall the context, the Docker daemon socket is owned by root:docker :
$ ls -l /var/run/docker.sock srw-rw---- 1 root docker 0 janv. 28 14:23 /var/run/docker.sock so with this default setup, one needs to prepend all docker CLI commands by sudo .
To avoid this, one can either:
- add one’s user account ( $USER ) to the docker group − but that’s quite risky to do this on one’s personal workstation, as this would amount to provide all programs run by the user with root permissions without any sudo password prompt nor auditing. See also:
- this page in the official Docker documentation:
https://docs.docker.com/engine/security/#docker-daemon-attack-surface - this page that documents the related exploit:
https://fosterelli.co/privilege-escalation-via-docker.html
- this page in the official Docker documentation:
- one can otherwise prepend sudo automatically without typing sudo docker manually: to this aim, a solution consists in adding the following alias in the ~/.bashrc (see e.g. this thread for details):
__docker() < if [[ "$" =~ "bash-completion" ]]; then docker "$@" else sudo docker "$@" fi > alias docker=__docker docker run --pul〈TAB〉 # → docker run --pull # autocompletion works docker run --pull always --rm -it debian:11 # ask one's password \docker run --help # bypass the alias (thanks to the \) and ask no password 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 ):
# docker run -it --name oracle_install -v /root/database:/tmp/install/database bofm/oracle12c:preinstall bash 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:
[root@77eb235aceac /]# cd /tmp/install/database/ [root@77eb235aceac database]# ls ls: cannot open directory .: Permission denied [root@77eb235aceac database]# id uid=0(root) gid=0(root) groups=0(root) [root@77eb235aceac database]# cd .. [root@77eb235aceac install]# ls -alt . drwxr-xr-x. 7 root root 4096 Jul 7 2014 database [root@localhost ~]# ls -lt . drwxr-xr-x. 7 root root 4096 Jul 7 2014 database Why does docker container prompt «Permission denied»? Update:
The root cause is related to SELinux . Actually, I met similar issue last year.
Could try by adding —privileged to the docker run command and tell us if the permission is still denied. Also, could you perform (on the host) # ls -lh /tmp/install/database please?
@Auzias: Yes, add —privileged works! Thanks! Could you write an answer and explain what is the difference of using this option or not though working as a root user in container?
Not really yet as I’m unsure of the reason. could you perform (on the host) # ls -lh /tmp/install/database please? (you provided ls -ldh /root/database no the /tmp one). Also, is you /tmp on a specific device?
5 Answers 5
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).
--device=[] Add a host device to the container (e.g. --device=/dev/sdc:/dev/xvdc:rwm) --privileged=true|false Give extended privileges to this container. The default is false. By default, Docker containers are “unprivileged” (=false) and cannot, for example, run a Docker daemon inside the Docker container. This is because by default a container is not allowed to access any devices. A “privileged” container is given access to all devices. When the operator executes docker run --privileged, Docker will enable access to all devices on the host as well as set some configuration in AppArmor to allow the container nearly all the same access to the host as processes running outside of a container on the host.