Today I am trying to set up postgresql with Docker. However I have an error when I test with the 'hello-world' :

docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\"proc\\" to rootfs \\"/var/lib/docker/overlay2/1ef83761740dcfec79baa94e1ef3073bf1fa130a21f56e9201a80f4523e073ab/merged\\" at \\"/proc\\" caused \\"permission denied\\"\"": unknown. ERRO[0003] error waiting for container: context canceled

I learned about this problem, which happens a lot, however I found no solution (I tested to set docker groupe, launch with sudo, etc...)

This is 'docker info':

 Debug Mode: false

 Containers: 3
  Running: 0
  Paused: 0
  Stopped: 3
 Images: 1
 Server Version: 19.03.10
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
 init version: fec3683
 Security Options:
   Profile: default
 Kernel Version: 5.3.18-3-pve
 Operating System: Debian GNU/Linux 9 (stretch)
 OSType: linux
 Architecture: x86_64
 CPUs: 3
 Total Memory: 7.938GiB
 Name: 18507
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Experimental: false
 Insecure Registries:
 Live Restore Enabled: false

Do you have any questions or suggestions ?

  • I just find strange the association "Debian 9" and "kernel 5.3.18-3-pve" (Proxmox?)
    – A.B
    May 31, 2020 at 2:40
  • Hi ! It seemed strange to me too. I pay a custom vps under linux (alls-heberg). For Proxmox, I have no idea. May 31, 2020 at 8:14
  • II inquired and it seems that my vps is held by Proxmox May 31, 2020 at 9:20
  • Install virt-what and run it: being in a VM is fine, being already in a container is usually not. Else I'd try to check if Apparmor causes a problem. It was enabled in Debian10's kernel and Debian9 wasn't ready for it. so if the kernel running isn't the one supposed to be running for Debian 9 (nor Proxmox 5.4)... check wiki.debian.org/AppArmor/HowToUse#Debug .
    – A.B
    May 31, 2020 at 10:37
  • Thanks ! I checked, so I tested the command 'virt-what' and he give me 'lxc'. For Apparmor, I don't have it (any config file or folders). Am i supposed to install it or no ? May 31, 2020 at 11:22

1 Answer 1


The command virt-what you ran and which outputs lxc tells your whole system is already running in an unprivileged LXC container (itself probably provisionned by Proxmox' own API/method), as determined by seing cat /proc/1/uid_map didn't output 0 0 4294967295 but 0 100000 65536.

LXC puts restrictions to containers it's running. Such containers don't have standard access to containerization features themselves without special settings in place on the host (providing the LXC container, owned by your VPS provider) and sometimes also the containerization tool to work along.

I found this discussed in an LXC forum, and it appears to match exactly your problem:
Working install of Docker-CE in LXC unprivileged container in Proxmox

Now the docker daemon should be OK ; it’s time for the second error: docker run hello-world returns an error « mounting proc to rootfs…permission denied »

As expected, the solution is to enable nested containerization on LXC/Proxmox. This must be done by your VPS provider (or some API it would provide to its users).

Fix it (trick #2) by inserting manually a line containing the following :

features:  keyctl=1,nesting=1

when looking at Proxmox' documentation:

keyctl=<boolean> (default = 0)

For unprivileged containers only: Allow the use of the keyctl() system call. This is required to use docker inside a container.


nesting=<boolean> (default = 0)

Allow nesting. Best used with unprivileged containers with additional id mapping. Note that this will expose procfs and sysfs contents of the host to the guest.

Those two features must be activated for you by your provider. As there are security considerations, your provider might not be inclined to do it. So you should check your contract with your provider to see if you are supposed to get such restriction or not and act accordingly.

You won't get this problem in an environment where the result of virt-what gives a VM hypervisor rather than a container result (eg: kvm, vmware, hyperv, even qemu (which would run very slowly) ... but not docker or lxc), or else if the provider explicitly allows nesting by relaxing some restrictions.

  • TL;DR: this answer probably means "no, you can't", sorry about it.
    – A.B
    May 31, 2020 at 14:05
  • Also I checked out of curiosity if it's possible to run a QEMU (non accelerated) VM inside an unprivileged container: it's possible to tweak libvirtd (actually replacing dmidecode with a stub) to start. But then it doesn't offer QEMU's user mode network stack and fails at creating a tap interface (which the container is not allowed to create). So that would leave running qemu directly. At this point better run this on one's own computer it's way easier
    – A.B
    May 31, 2020 at 14:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .