Permission denied to Docker daemon socket at unix:///var/run/docker.sock
Asked Answered
C

5

13

I have this Dockerfile:

FROM chekote/gulp:latest 

USER root
RUN apt-get update \
      && apt-get upgrade -y \
      && apt-get install -y sudo libltdl-dev

ARG dockerUser='my-user-name';
ARG group='docker';

# crate group if not exists
 RUN if ! grep -q -E "^$group:" /etc/group; then groupadd $group; fi

# create user if not exists
 RUN if ! grep -q -E "^$dockerUser:" /etc/passwd; then useradd -c 'Docker image creator' -m -s '/bin/bash' -g $group $dockerUser; fi

# add user to the group (if it was present and not created at the line above)
 RUN usermod -a -G ${group} ${dockerUser}

# set default user that runs the container
 USER ${dockerUser}

That I build this way:

docker build --tag my-gulp:latest .

and finally run by script this way:

#!/bin/bash

image="my-gulp:latest";
workDir='/home/gulp/project';

docker run -it --rm  \
-v $(pwd):${workDir} \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /usr/bin/docker:/usr/bin/docker \
${image} /bin/bash

that logs me into the docker container properly but when I want to see images

docker images

or try to pull image

docker pull hello-world:latest

I get this error:

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.38/images/json: dial unix /var/run/docker.sock: connect: permission denied

How to create docker image from chekote/gulp:latest so I can use docker inside it without the error?

Or maybe the error is because of wrong docker run command?

Cressida answered 2/11, 2018 at 23:28 Comment(4)
i am not 100% sure, but try --privileged tag while running the container. it may work.Infantine
Why are you trying to Inception your docker containersInfrasonic
@Code Bling This isn't inception, the gulp container does not run docker's containers inside of it but uses host's docker to start other docker's containers that at the same level as gulp container. The docker commands are going from gulp container outwards to the host that runs other containers, so from the host's point of view it is similar to running containers by gulp that is not containerized. Reason: you can easily switch between gulp versions (eg 3.x and 4.x) just by using different containers even there is no gulp at host at all.Cressida
@Cressida oh, that's neat! Still...Inception.Infrasonic
O
15

The permission matching happens only on numeric user ID and group ID. If the socket file is mode 0660 and owned by user ID 0 and group ID 32, and you're calling it as a user with user ID 1000 and group IDs 1000 and 16, it doesn't matter if one /etc/group file names gid 32 as docker and the other one names gid 16 the same; the numeric gids are different and you can't access the file. Also, since the actual numeric gid of the Docker group will vary across systems, this isn't something you can bake into the Dockerfile.

Many Docker images just run as root; if they do, they can access a bind-mounted Docker socket file regardless of its permissions.

If you run as a non-root user, you can use the docker run --group-add option to add a (numeric) gid to the effective user; it doesn't specifically need to be mentioned in the /etc/groups file. On a Linux host you might run:

docker run --group-add $(stat -c '%g' /var/run/docker.sock) ...

You wouldn't usually install sudo in a Dockerfile (it doesn't work well for non-interactive programs, you usually don't do a whole lot in interactive shells because of the ephemeral nature of containers, and you can always docker exec -u 0 to get a root shell) though installing some non-root user is often considered a best practice. You could reduce the Dockerfile to

FROM node:8
RUN apt-get update
# Trying to use the host's `docker` binary may not work well
RUN apt-get install -y docker.io
# Install the single node tool you need
RUN npm install -g gulp
# Get your non-root user
RUN adduser myusername
# Normal Dockerfile bits
WORKDIR ...
COPY ...
RUN gulp
USER myusername
CMD ["npm", "run", "start"]

(That Docker base image has a couple of things that don't really match Docker best practices, and doesn't seem to be updated routinely; I'd just use the standard node image as a base and add the one build tool you need on top of it.)

Oculist answered 3/11, 2018 at 7:47 Comment(5)
Can you elaborate on this statement Trying to use the hosts docker binary may not work well ? I am mounting docker binary in many places to avoid installing docker.,Odilo
The host is MacOS but the container is Linux, so the host's docker binary won't work. Both the host and container are Linux but the shared-library dependencies are different. One of the key goals for a Docker image is for it to be totally self-contained, and injecting binaries or code from the host violates this rule.Oculist
I agree with you on injecting binaries is not good. In case of Docker, I do Docker outside of docker (DooS) and it works without issue when I mount MacOS docker binary to Linux container. I believe, if host is Windows, it may not work. But do you see any concern in mounting MacOS docker binary on a Linux container ? This helps to avoid installing docker on container image.Odilo
A MacOS binary will not run in a Linux environment, full stop. Images that depend on code being injected from the host aren't going to be portable and this misses the point of using Docker.Oculist
Many thanks for this, especially the group-add flag. It saved me from doing couple of hacks to do its equivalent.Marquismarquisate
T
58

A quick way to avoid that. Add your user to the group.

sudo gpasswd -a $USER docker

Then set the proper permissions.

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

Should be good from there.

Thicken answered 3/11, 2018 at 6:14 Comment(1)
Docker documentation details this too: docs.docker.com/engine/install/linux-postinstallRanique
O
15

The permission matching happens only on numeric user ID and group ID. If the socket file is mode 0660 and owned by user ID 0 and group ID 32, and you're calling it as a user with user ID 1000 and group IDs 1000 and 16, it doesn't matter if one /etc/group file names gid 32 as docker and the other one names gid 16 the same; the numeric gids are different and you can't access the file. Also, since the actual numeric gid of the Docker group will vary across systems, this isn't something you can bake into the Dockerfile.

Many Docker images just run as root; if they do, they can access a bind-mounted Docker socket file regardless of its permissions.

If you run as a non-root user, you can use the docker run --group-add option to add a (numeric) gid to the effective user; it doesn't specifically need to be mentioned in the /etc/groups file. On a Linux host you might run:

docker run --group-add $(stat -c '%g' /var/run/docker.sock) ...

You wouldn't usually install sudo in a Dockerfile (it doesn't work well for non-interactive programs, you usually don't do a whole lot in interactive shells because of the ephemeral nature of containers, and you can always docker exec -u 0 to get a root shell) though installing some non-root user is often considered a best practice. You could reduce the Dockerfile to

FROM node:8
RUN apt-get update
# Trying to use the host's `docker` binary may not work well
RUN apt-get install -y docker.io
# Install the single node tool you need
RUN npm install -g gulp
# Get your non-root user
RUN adduser myusername
# Normal Dockerfile bits
WORKDIR ...
COPY ...
RUN gulp
USER myusername
CMD ["npm", "run", "start"]

(That Docker base image has a couple of things that don't really match Docker best practices, and doesn't seem to be updated routinely; I'd just use the standard node image as a base and add the one build tool you need on top of it.)

Oculist answered 3/11, 2018 at 7:47 Comment(5)
Can you elaborate on this statement Trying to use the hosts docker binary may not work well ? I am mounting docker binary in many places to avoid installing docker.,Odilo
The host is MacOS but the container is Linux, so the host's docker binary won't work. Both the host and container are Linux but the shared-library dependencies are different. One of the key goals for a Docker image is for it to be totally self-contained, and injecting binaries or code from the host violates this rule.Oculist
I agree with you on injecting binaries is not good. In case of Docker, I do Docker outside of docker (DooS) and it works without issue when I mount MacOS docker binary to Linux container. I believe, if host is Windows, it may not work. But do you see any concern in mounting MacOS docker binary on a Linux container ? This helps to avoid installing docker on container image.Odilo
A MacOS binary will not run in a Linux environment, full stop. Images that depend on code being injected from the host aren't going to be portable and this misses the point of using Docker.Oculist
Many thanks for this, especially the group-add flag. It saved me from doing couple of hacks to do its equivalent.Marquismarquisate
S
7

open terminal and type this command

sudo chmod 666 /var/run/docker.sock

let me know the results...

Spadix answered 18/8, 2020 at 21:6 Comment(4)
thanks @Mohit Rakhade, worked well for meChico
Easiest answer.Amaryllidaceous
Best and Easy!!Jazmin
I am sorry, but this is a terrible answer. It opens docker socket to be writtable by anyone. I would consider using this only on my local developer machine - and even then this is a bad preactice. If the image should work anywhere besides local environment, this should be avoided at all costs.Browband
H
0

The error has nothing to do with docker pull or docker image subcommand, but rather that you need to call the docker command as either a user with write access to the docker socket (for example, by being root, using sudo, or by being in the docker group).

Hinojosa answered 2/11, 2018 at 23:34 Comment(2)
but I added my-user-name in Dockerfile to the docker group didn't I? RUN usermod -a -G ${group} ${dockerUser}Cressida
You need to add to docker group the user on the host machine, not the user in the container. Dockerfile's RUN command runs inside the container and cannot affect the host machine.Hinojosa
B
0

You need the --privileged flag with your docker run command.

By the way , you can just use the docker in docker , image from docker for this kind of use case.

https://asciinema.org/a/24707

https://hub.docker.com/_/docker/

Brooch answered 3/11, 2018 at 0:57 Comment(2)
First line in the description of that image: "running Docker inside Docker is generally not recommended". You do not need --privileged to access the bind-mounted host Docker socket either, you just need to get the Unix permissions on the socket file right.Oculist
@DavidMaze yes it is not recommended in production , but he is trying to do it anyway maybe just for testing , by making his own dind , which is redundantBrooch

© 2022 - 2024 — McMap. All rights reserved.