Description of problem: Mounting sockets or special files from subpaths fails. Version-Release number of selected component (if applicable): 3.9.x How reproducible: Steps to Reproduce: 1. Create a pod definition that uses "/" as hostPath. 2. Try and mount something like "/run/docker.sock" as a subpath within a container. 3. The pod will fail to start The reason of this regression is - openat system call being used on https://github.com/kubernetes/kubernetes/blob/master/pkg/util/mount/mount_linux.go#L1138 does not work for special files like Unix sockets and it will throw - Errno::ENXIO: No such device or address /run/docker.sock Actual results: The pod fails to start Expected results: The pod should start
For now, while we make the fix. One possible workaround is to directly mount "/run/docker.sock" via a new volume entry and a new VolumeMounts entry that does not uses subpath. Something like: VolumeMounts: [ { mountPath: "/run/docker.sock", name: docker_sock, readOnly: true} ], volumes: [ { name: docker_sock, hostPath: { path: "/run/docker.sock", type: "" }, ]
PR upstream for the fix https://github.com/kubernetes/kubernetes/pull/61480
Opened PR for Openshift/origin - https://github.com/openshift/origin/pull/19100
This is merged in both origin and OSE.So it is done and done from development POV.
Verified in OCP: v3.9.22 # cat pod.yaml kind: Pod apiVersion: v1 metadata: name: testpod spec: containers: - name: testpod image: aosqe/hello-openshift ports: - containerPort: 80 name: "http-server" volumeMounts: - mountPath: "/mnt/run/docker.sock" subPath: "run/docker.sock" name: file volumes: - name: file hostPath: path: "/" # oc exec testpod -- ls /mnt/run/docker.sock -l srw-rw---- 1 root root 0 Apr 17 02:42 /mnt/run/docker.sock
Verified in OCP: oc v3.9.24 openshift v3.9.24 kubernetes v1.9.1+a0ce1bc657 # uname -a Linux host-172-16-120-35 3.10.0-693.21.1.el7.x86_64 #1 SMP Fri Feb 23 18:54:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux # cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.4 (Maipo)
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:1566