That volumeMounts line? It’s secretly messing with your host: Taming mount propagation in containers

Technical Briefing | 10/14/2026

You’ve dropped a volumeMount into your Kubernetes YAML or your docker run command a thousand times. It works, right? Your container sees the directory, writes to it, reads from it, and life is good. But sometimes, usually in a dark corner of a test environment or, worse, production, you’ll see something utterly bizarre. A new mountpoint shows up on your host, seemingly out of nowhere, or a temporary file created inside a container persists on the host, long after the container is gone. This silent interaction between container and host mounts is often the culprit, and it boils down to mount propagation. Most people just assume mount points are isolated, but that’s a dangerous assumption.

Your Container’s View Isn’t Always Its Own

At the kernel level, containers get their isolation through namespaces. Each container lives in its own PID namespace, network namespace, and, critically for this discussion, its own mount namespace. This means when a container does something like mount /dev/sda1 /mnt/data, that mount is generally only visible within that container’s world. But “generally” is the operative word here. The relationship between the container’s mount namespace and the host’s isn’t always a simple one-way street. It can be a two-way sync, a one-way street from the host, or truly isolated. And that behavior is controlled by propagation.

findmnt -o TARGET,PROPAGATION,SOURCE -M /
findmnt -o TARGET,PROPAGATION,SOURCE

The Three Musketeers of Mount Propagation: Shared, Slave, and Private

Let’s break down the options. When a mount is shared, any mount or unmount event within that mount’s subtree, whether initiated by the host or by a container whose mount point is also shared, will propagate to all peers. This is where things get gnarly. Imagine a developer mounting a FUSE filesystem in their container, thinking it’s just for them, and suddenly that mount appears on the host, potentially interfering with system services or consuming host resources directly. I’ve seen this silently fill up /tmp on a host because a container process was creating a sub-mount that ended up propagating. On the flip side, slave propagation means mount events from the host will propagate into the container, but not the other way around. This is usually what kubelet uses for host path volumes, making sure things like device mounts show up in your pods, but your pods can’t suddenly make new mounts appear on the host.

Then there’s private. This is the one you probably want most of the time. When a mount is private, mount and unmount events do not propagate in either direction. The container has its own private view of that mount point, completely isolated from its peers and the host for that specific path. This gives you the strong isolation most people assume they’re getting out of the box. There’s also rprivate (recursive private), rshared, and rslave for applying these modes recursively to all sub-mounts within a subtree, which is pretty standard for the root filesystem. Most container runtimes like Docker and containerd default to rprivate for many of the crucial parts of a container’s filesystem for this exact reason.

• Shared: Avoid this unless you absolutely need two-way propagation, and you know exactly why. It’s a source of hard-to-debug host issues.
• Slave: Good for when you want host changes (like device hot-plugging) to reflect in a container, but want to prevent container changes from affecting the host. Kubernetes’ hostPath volumes often end up here.
• Private (and rprivate): Your default choice for isolation. Use this when you want maximum separation and don’t want any surprises leaking between host and container.
• Check your container runtime’s default propagation settings. Docker often sets / to rprivate, but bind mounts can inherit the parent’s propagation. This is where you need to be careful.

Mount propagation isn’t some obscure kernel detail reserved for distro maintainers. It’s a fundamental aspect of how containers interact with the host filesystem, and getting it wrong can lead to security vulnerabilities, silent resource leaks, and bizarre operational failures that’ll have you pulling your hair out. Next time you drop a volumeMount or a bind mount, take a second to consider what that shared or private flag truly means for your environment. It’s often the difference between a stable system and one that’s quietly breaking under the surface.