Error response from daemon: cannot stop container - signaling init process caused "permission denied"

Question

I started the Docker container:

VirtualBox:~$ sudo docker run --name rabbitmq -d -p 0.0.0.0:5672:5672 -p 0.0.0.0:15672:15672 bitnami/rabbitmq

All is well, the container is working.

docker  ps

CONTAINER ID        IMAGE                     COMMAND                  CREATED             STATUS              PORTS                                                                                                NAMES
dd3d12133774        bitnami/rabbitmq:latest   "/app-entrypoint.sh …"   37 minutes ago      Up 37 minutes       0.0.0.0:4369->4369/tcp, 0.0.0.0:5672->5672/tcp, 0.0.0.0:15672->15672/tcp, 0.0.0.0:25672->25672/tcp   sad_knuth
203500ee7f1e        bitnami/rabbitmq          "/app-entrypoint.sh …"   5 hours ago         Up 5 hours          0.0.0.0:5672->5672/tcp, 4369/tcp, 25672/tcp, 0.0.0.0:15672->15672/tcp                                rabbitmq

When I use command :

docker stop 203500ee7f1e

or

docker stop rabbitmq

Nothing happens (Error):

VirtualBox:~$ docker stop rabbitmq
Error response from daemon: cannot stop container: rabbitmq: Cannot kill container 203500ee7f1eb09bf0ecb2fdaf2041f4da27990a3654bca90b808a3ec36238cf: unknown error after kill: docker-runc did not terminate sucessfully: container_linux.go:393: signaling init process caused "permission denied"
: unknown

Output Docker version

VirtualBox:~$ docker version
Client:
 Version:           18.06.0-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        0ffa825
 Built:             Wed Jul 18 19:09:54 2018
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.0-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       0ffa825
  Built:            Wed Jul 18 19:07:56 2018
  OS/Arch:          linux/amd64
  Experimental:     false

Output Docker info

    VirtualBox:~$ docker info
Containers: 2
 Running: 2
 Paused: 0
 Stopped: 0
Images: 2
Server Version: 18.06.0-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: d64c661f1d51c48782c9cec8fda7604785f93587
runc version: 69663f0bd4b60df09991c08812a60108003fa340
init version: fec3683
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.15.0-29-generic
Operating System: Ubuntu 18.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.852GiB
Name: ivanpuzyrev-VirtualBox
ID: 2LAE:PADC:VVDH:G2OW:MWUD:IRTS:CRNU:J727:DDEV:ZYBS:GTGG:SIOI
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support

Help Please!!! Nothing happens. Perhaps you have any ideas?

Answer 1

This answer helped me with docker as well:

After

sudo aa-remove-unknown

the problem was instantly gone and docker stop would work again as expected. See: aa-remove-unknown - remove unknown AppArmor profiles

Background

As far as I understand it, the problem cause is that the docker package does not install a profile for docker in the AppArmor service, so docker is categorized as 'unknown' by AppArmor. The above command removes the profile for all unknown applications, so they are no longer restricted by AppArmor.

Of course, the correct way would be to keep the profile for unknown applications and create an AppArmor profile for docker. According to the docker docs on AppArmor security profiles for Docker, "A profile for the Docker Engine daemon exists but it is not currently installed".

However, I myself did not care enough to dig into this, so I can't provide instructions here.

Answer 2

I'm going to disagree with everyone suggesting sudo. The docker command sends api calls to the daemon, and if you needed sudo to run the command, you would know from the failure to connect to the docker socket. The daemon itself should be running as root.

The permission error to me looks like something that could be caused by an AppArmor policy or it could just be a bug in the engine/containerd/runc. You are also running Ubuntu 18.04 which docker only recently added support, so if possible, try running a slightly older version of Ubuntu LTS, or see if one of the edge/nightly builds fixes the issue. In the short term, you may have luck restarting the docker engine (systemctl restart docker) and possibly the entire host to see if that clears up the issue.