Share Host’s Mount Namespace with Docker Containers

This is a follow-up to my previous post about using Super Privileged Container (SPC) to mount a remote filesystem on the host. That approach drew criticisms on hacking into mount helpers.

I made a Docker patch so that Docker daemon doesn’t isolate the host’s mount namespace from containers. Containers are thus able to see and update host’s mount namespace. This feature is turned on through a Docker client option –hostns=true.

A running instance is as the following:

First start a container and set –hostns=true:

[code language=”bash”]
#docker run –privileged –net=host –hostns=true -v /:/host -i -t centos bash
[/code]

On another terminal, wait after the container is up and you get a bash shell, see the container’s mount namespace:

[code language=”bash”]
# pid=`ps -ef |grep docker |grep -v run|grep -v grep|awk ‘{print $2}’`; b=`ps -ef |grep bash|grep ${pid}|awk ‘{print $2}’`; cat /proc/${b}/mountinfo
[/code]

And below, I spotted the following line, indicating the container and host share the same mount namespace.

[code language=”text”]
313 261 253:1 / /host rw,relatime shared:1 – ext4 /dev/mapper/fedora–server_host-root rw,data=ordered
[/code]

Then on the container’s shell, install glusterfs-fuse package and mount a remote Glusterfs volume:

[code language=”bash”]
# yum install glusterfs-fuse attr -y
# mount -t glusterfs gluster_server:kube_vol /host/shared
[/code]

Go back to the host terminal and check if the host can see Glusterfs volume:

[code language=”bash”]
# findmnt |grep glusterfs |tail -1
└─/shared gluster_server:kube_vol fuse.glusterfs rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072
[/code]

So far so good!

8 thoughts on “Share Host’s Mount Namespace with Docker Containers

      1. So I was able to mount glusterfs under coreos using this guide and (shared volume mount in docker, details of my setup are here: https://github.com/coreos/coreos-kubernetes/issues/696 ), but there is a problem while running kubernetes. I found out, that the volume is accessible by docker containers, BUT – when I run the mounter docker container before Kubelet start, then fluentd logging into elastic (standard kubernetes guide) and heapster loggin into influxdb (standard guide as well) won’t work … It’s like there is a permission problem somewhere. I need to run the mounter container precisely after kubelet starts, but before first docker containers start to run … that’s quite uncomfortable and unstable. Therefore I’d like to ask you – wouldn’t you have any idea which would explain the described behavior and maybe any suggestion how to proceed in this case.

        I’m just trying my luck, hoping for the best, thanks in advance, if you’d have some time to think about the case.

Leave a Reply