OCI runtime create failed after update to 17.12.0-ce-win46

[daelmaak]

Description
Starting containers with docker-compose up always results in OCI runtime error, but we never had such problems in version 17.09.0-ce-win32 (so downgrading back to 17.09.0-ce-win32 actually helped to resolve the problem right away). Tried to upgrade downgrade couple times with the same results.

Steps to reproduce the issue:
In this case it was really just about pulling our keycloak image from our private nexus repo, into which I was logged during the process.

Describe the results you received:
Cannot start service keycloak: OCI runtime create failed: container_linux.go:296: starting container process caused "process_linux.go:398: container init caused \"rootfs_linux.go:58: mounting \\\"/etc/localtime\\\" to rootfs \\\"/var/lib/docker/overlay2/69cf1d19a0466351fee8c347aa94780338db98a29cb298b8807578b12ab758b0/merged\\\" at \\\"/var/lib/docker/overlay2/69cf1d19a0466351fee8c347aa94780338db98a29cb298b8807578b12ab758b0/merged/usr/share/zoneinfo/UTC\\\" caused \\\"not a directory\\\"\"": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type

Describe the results you expected:
Image being pulled and container started.

Output of docker version:

Client:
 Version:       17.12.0-ce
 API version:   1.35
 Go version:    go1.9.2
 Git commit:    c97c6d6
 Built: Wed Dec 27 20:05:22 2017
 OS/Arch:       windows/amd64

Server:
 Engine:
  Version:      17.12.0-ce
  API version:  1.35 (minimum version 1.12)
  Go version:   go1.9.2
  Git commit:   c97c6d6
  Built:        Wed Dec 27 20:12:29 2017
  OS/Arch:      linux/amd64
  Experimental: true

Output of docker info:

Containers: 5
 Running: 4
 Paused: 0
 Stopped: 1
Images: 7
Server Version: 17.12.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 ipvlan 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: 89623f28b87a6004d4b785663257362d1658a729
runc version: b2567b37d7b75eb4cf325b77297b140ea686ce8f
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.60-linuxkit-aufs
Operating System: Docker for Windows
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 9.48GiB
Name: linuxkit-00155d0a5929
ID: EK7T:UPIP:XBUF:QEUU:AWVW:V634:FZPE:WO6X:ISPG:XBAT:IYDZ:4VXM
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 46
 Goroutines: 64
 System Time: 2018-01-10T15:14:28.4095607Z
 EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: true
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):
physical

[JerBlo]

Same issue here. After resetting credentials for shared drives (Docker Settings > Shared Drives), it seems to work again.

[cpuguy83]

Hi ow are you starting the container?
It looks like you are trying to mount a dir over a file or a file over a dir, which does not work.

If this used to work, the it sounds like something changed on the filesystem... Maybe the path is gone and now docker created a dir there (which is the expected behavior).

[thaJeztah]

I've seen some reports of bind-mounts using the wrong path on Docker for Mac and Docker for Windows, causing directories to be created instead of the file being mounted (see docker/for-win#1501, docker/for-win#1521); possibly related?

[schlemmge]

We have a potentially similar problem. The command

docker run -v //etc/passwd:/etc/passwd:ro busybox /bin/sh -c "cat /etc/passwd"

used to mount a password file into the image container using docker for windows 17.09.0-ce.
With the latest version of docker (docker info and diagnostic see below) for windows we get an error:

C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from daemon: OCI runtime create failed: container_linux.go:296: starting container process caused "process_linux.go:398: container init caused "rootfs_linux.go:58:
mounting \"/etc/passwd\" to rootfs \"/var/lib/docker/overlay2/8fd7bc92aaab9e1760466c79bf3f13e5d3cc8d4218e3c710b626b4e89d292414/merged\" at \"/var/lib/docker/overlay2/8fd7bc92aaab9e1760466c79bf3f13e5d3cc8d4218e3c710b626b4e89d292
414/merged/etc/passwd\" caused \"not a directory\""": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type.

diagnostic

EFAF41EC-91DA-46B4-8FFD-9A1D9F2306A6/2018-01-15_14-05-26

docker info

Containers: 1
Running: 0
Paused: 0
Stopped: 1
Images: 3
Server Version: 17.12.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 ipvlan 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: 89623f28b87a6004d4b785663257362d1658a729
runc version: b2567b37d7b75eb4cf325b77297b140ea686ce8f
init version: 949e6fa
Security Options:
seccomp
Profile: default
Kernel Version: 4.9.60-linuxkit-aufs
Operating System: Docker for Windows
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.934GiB
Name: linuxkit-00155d3801aa
ID: RYJT:CZ6F:C5TJ:KMRY:FVQT:2NO6:YTVV:FT37:HQIP:WH7P:STDR:HADD
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: 20
Goroutines: 40
System Time: 2018-01-15T13:04:39.2926684Z
EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: true
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false

[thaJeztah]

The original issue (bind-mounting /etc/localtime) looks to be a duplicate of docker/for-mac#2396 (that one is for Docker for Mac, but the problem looks to be inside the Docker VM).

@schlemmge your issue may be one of the issues I linked to in my comment.

Given that this is an issue with Docker for Mac / Docker for Windows, I'll close the issue here, because the problem is not in the code that's maintained in this repository, but feel free to continue the conversation 👍