Why Does Docker Container Prompt "Permission Denied"

Why does docker container prompt Permission denied?

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:

  --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.

Why does docker prompt Permission denied when backing up the data volume?

I just tried the commands you listed and they worked for me, both under an OSX platform and also a straight up linux platform. The thing is you are mounting $(pwd) (from your host) to /backup (in the ubuntu image, third docker run above).

I suspect that when you launch the command you are in a directory that is not writable? I tried to get it to fail like this:

mkdir failme
chmod 000 failme
cd failme
docker run --volumes-from dbdata -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata

But, it worked :-)

So, I cd'ed into a directory that isn't writable by root:

cd /proc
root@kube:/proc# docker run --volumes-from dbdata -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata
tar: /backup/backup.tar: Cannot open: Permission denied
tar: Error is not recoverable: exiting now

Is it possible that you are starting from a directory that is not writable by root?

Please post the output to these commands: First, run:

docker run --name ins --volumes-from dbdata -v $(pwd):/backup ubuntu sleep 99999 &

(instead of the backup command command you have listed.)

then do an inspect and post those results:

docker inspect ins

And the answer turned out to be that it was the selinux causing the errors. The Original Poster found the answer:

setenforce 0

Docker does not care about user permissions. Why?

Given that you are running the nc command as a non-root user (due to the USER 1000:1000 directive in your Dockerfile), you might expect to see a "permission denied" error of some sort when nc tries to bind port 80.

In earlier versions of Docker that is exactly what would have happened, but a few years ago Docker was modified so that containers run with net.ipv4.ip_unprivileged_port_start=0, which means there are no longer any "privileged ports": any UID can bind any port.

You can see this setting by running sysctl inside a container:

$ docker run -it --rm -u 1000:1000 alpine sysctl -a |grep net.ipv4.ip_unprivileged_port_start
net.ipv4.ip_unprivileged_port_start = 0

the container just hangs. Why?

The container isn't "hanging"; it is successfully running nc -l -p 80, which is waiting for a connection to the container on port 80. If you were to use curl or some other tool to connect to port 80 in that container, it would display any data send over the connection and then the container would exit when the connection is closed.

How to fix docker: Got permission denied issue

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

$ sudo groupadd docker

2. Add your user to the docker group.

$ sudo usermod -aG docker $USER

3. Log in to the new docker group (to avoid having to log out / log in again; but if not enough, try to reboot):

$ newgrp docker

4. Check if docker can be run without root

$ docker run hello-world

Reboot if still got error

$ reboot

Warning

The docker group grants privileges equivalent to the root user. For details on how this impacts security in your system, see Docker Daemon Attack Surface..

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

docker.sock permission denied

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:

$ newgrp docker

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.

DotNet 6 fails to run in a Windows container: Permission denied

My docker user needs more permissions. I solved it in an easy way because it is for testing.. don't do this at home, and grant the minimum permissions instead:

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
# Here is the risky trick
USER Administrator 

Permission denied in Docker container unless --privileged=true

Docker was running with --selinux-enabled=true, this prohibited me from accessing the contents of directories in the container.

Read more: http://www.projectatomic.io/blog/2016/07/docker-selinux-flag/

The solution was to disable it, it can either be done by (1) configuring or by (2) installing the non-selinux CentOS package, I went with option 2:

I made sure to reinstall and update Docker from 1.10 to 1.12.1 and not install docker-engine-selinux.noarch but instead have docker-engine.x86_64 and have the SELinux package installed as a dependency (yum does this automatically). By doing this and starting the Docker daemon, you can verify with ps aux | grep "docker" that docker-containerd is not started with the --selinux-enabled=true option.

---

Related Topics