Cannot start container with --network container:<name> when using userns-remap and a volume

[ygersie]

Description
When running Docker daemon with userns-remapping enabled I can't start a container that uses an image declaring a VOLUME.

Steps to reproduce the issue:
Make sure userns-remap is enabled.

Build an image declaring a volume

FROM alpine
VOLUME [ "/foobar" ]

docker build -t image-with-volume .

Start a normal alpine container

docker run -d --name test --rm alpine tail -f /dev/null

Start the just built image linking it to the already running container

docker run -it --rm --network container:test image-with-volume

Describe the results you received:

docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: rootfs_linux.go:76: mounting "/data/docker/256000.256000/volumes/6421158607f8c3f4d544af6f42b29c0dd514138dbcc14f6428ceb6d3288217f4/_data" to rootfs at "/foobar" caused: stat /data/docker/256000.256000/volumes/6421158607f8c3f4d544af6f42b29c0dd514138dbcc14f6428ceb6d3288217f4/_data: permission denied: unknown.

Describe the results you expected:
A working container

Output of docker version:

Client:
 Version:           20.10.11
 API version:       1.41
 Go version:        go1.16.15
 Git commit:        dea9396e184290f638ea873c76db7c80efd5a1d2
 Built:             Thu Apr 14 23:00:14 2022
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server:
 Engine:
  Version:          20.10.11
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.15
  Git commit:       847da184ad5048b27f5bdf9d53d070f731b43180
  Built:            Wed Apr 13 23:41:08 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.5.8
  GitCommit:        1e5ef943eb76627a6d3b6de8cd1ef6537f393a71
 runc:
  Version:          1.0.0-rc95
  GitCommit:        b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
 docker-init:
  Version:          0.19.0
  GitCommit:

Output of docker info:

Client:
 Context:    default
 Debug Mode: false

Server:
 Containers: 4
  Running: 4
  Paused: 0
  Stopped: 0
 Images: 9
 Server Version: 20.10.11
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 1e5ef943eb76627a6d3b6de8cd1ef6537f393a71
 runc version: b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
 init version:
 Security Options:
  seccomp
   Profile: default
  userns
 Kernel Version: 5.10.109-0-virt
 Operating System: Alpine Linux v3.14
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 15.36GiB
 Name: ip-10-125-39-41
 ID: W7XA:JTA3:QQVI:USHV:EBV7:CWGW:IX5F:JKRT:VEAX:KI36:TBHX:UWTN
 Docker Root Dir: /data/docker/256000.256000
 Debug Mode: false
 Username: pdacc
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: true

[thaJeztah]

I suspect this is similar to opencontainers/runc#2484, which was resolved in runc v1.1.0 and up through opencontainers/runc#2576

I see you're running an older version of docker 20.10, containerd, and runc; are you still able to reproduce this on current versions?

[ygersie]

Hey @thaJeztah yep you're completely right! Thanks for pointing in the right direction 👍 I'll close this.

[thaJeztah]

Awesome, good to hear!