Default Bind Mounts

General Discussions
,
1

Hey there;
I recently noticed that Docker by default bind mounts routes from the host into the container even if I haven’t done any bind mount myself.
I want a list of those paths, and is there any documentation about them, and is it possible that these paths are different depending on each operating system or image?

2

Please, share what path you found mounted and how you started the container, because there is no mounted folder unless you specify. Maybe you found an anonymous docker volume mounted which was defined in the Dockerfile of the image that you used.

3

I created a container with the following command:
docker run --rm -it ubuntu bash

Then, when I checked it out with docker inspect command, something caught my eye:

"HostConfig": {
...
"MaskedPaths": [
                "/proc/asound",
                "/proc/acpi",
                "/proc/kcore",
                "/proc/keys",
                "/proc/latency_stats",
                "/proc/timer_list",
                "/proc/timer_stats",
                "/proc/sched_debug",
                "/proc/scsi",
                "/sys/firmware",
                "/sys/devices/virtual/powercap"
            ],
            "ReadonlyPaths": [
                "/proc/bus",
                "/proc/fs",
                "/proc/irq",
                "/proc/sys",
                "/proc/sysrq-trigger"
            ]
}

Then I thought that these might be the paths that Docker mounts in the container by default without the user’s knowledge.

5

I edited your post. Please, use code blocks. Here is a guide for that: How to format your forum posts

It seems the problem is with the understanding what a container is. Everything that the container needs is on the host machine. It is not a virtual machine. So in that sense, yes, the container will “mount” the whole root folder of the container’s filesystem. Which includes the multiple layers of images and the writable filesystem on top of it. /proc and /sys are special folders on Linux for communicating with the kernel, not a regular filesystem.

As I wrote before, a container is not a virtual machine, so it needs the host kernel, although saying “it needs” the kernel doesn’t really make sense, as the container does not “use” the kernel, it would not exist without it.

You still want to run commands in a container. Without part of /proc, you wouldn’t even see the processes in the container fro the container.

If you want to see all the mounts, you can run:

docker run --rm bash cat /proc/self/mounts

You will see (probably) ext4 filesystems like /etc/hosts, but it doesn’t mean that file is mounted from /etc/hosts from the host machine. It is just the destination fro somewhere under /var/lib/docker.

You will see proc and sysfs filesystems which is required, and you will see tmpfs filesystems like:

tmpfs /sys/firmware tmpfs ro,relatime,inode64 0

That is one example of a masked path. The container shouldn’t have it, so it is masked and created empty in the memory. I guess it has to exists somehow. This is what I found as a little explanation

https://renenyffenegger.ch/notes/Linux/fhs/sys/firmware/index

So it is nice to know how exactly a container is created, but it requires deeper linux skills to actually understand what and why is needed to be available in a container and even I don’t know these hundred percent. Kernel capabilities could be mentioned too.

https://docs.docker.com/engine/security/#linux-kernel-capabilities

Now to clarify my statement “a container is not a virtual machine”

You could read and hear a lot that Docker Desktop creates a virtual machine even on Linux. That is true, but the virtual machine is still not the container, containers are running inside the virtual machine.

2 Likes
6

thank you.
Although I realized that I can view it by running the findmnt command inside the container
Or check the following code:

1 Like