Linux Mount Namespaces and Propagation

Mounts are per-namespace state. Two processes on the same host can see different mount trees, different bind mounts, different root filesystems, and different propagation behavior. This is fundamental for containers, systemd services, chroots, initramfs, and incident debugging.

Command Examples

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS,PROPAGATION
readlink /proc/<pid>/ns/mnt
cat /proc/<pid>/mountinfo
lsns -t mnt
nsenter --target <pid> --mount -- findmnt

Example output and meaning:

Mount Namespaces

A mount namespace isolates the list of mount points seen by a process. Creating, removing, or moving mounts in one namespace does not necessarily affect another namespace.

Operational places this appears:

• containers and container runtimes,
• systemd units with mount namespace sandboxing,
• rescue shells and initramfs,
• chroot and build environments,
• services using PrivateTmp=, ProtectSystem=, or bind mounts,
• backup agents that run outside an application’s namespace.

/proc/<pid>/mountinfo is the most precise view of what a specific process sees.

Bind Mounts

A bind mount exposes an existing path at another path. Bind mounts are not copies. They are another view onto the same underlying object.

Bind mount pitfalls:

• the source path was wrong at container start,
• the target path hides existing files underneath it,
• recursive bind behavior differs from a non-recursive bind,
• readonly bind mounts may still depend on lower-layer writeability,
• propagation settings determine whether nested mount events cross boundaries.

Propagation

Mount propagation controls whether mount and unmount events flow between related mount trees.

Container storage bugs often reduce to propagation: the host mounts a volume after a container starts, but the container never sees it, or a mount made inside one namespace unexpectedly appears elsewhere.

Propagation Lab

This lab shows why a bind mount can exist in one mount namespace but not another. Run it on a disposable VM or lab host.

mkdir -p /tmp/prop-host /tmp/prop-peer /tmp/prop-source
mount --bind /tmp/prop-host /tmp/prop-host
mount --make-rshared /tmp/prop-host
unshare --mount --fork --pid -- bash

Inside the new shell:

findmnt -o TARGET,PROPAGATION /tmp/prop-host
mkdir -p /tmp/prop-host/inside
mount --bind /tmp/prop-source /tmp/prop-host/inside

From the original namespace, check whether the nested mount propagated:

findmnt /tmp/prop-host/inside
findmnt -o TARGET,SOURCE,PROPAGATION /tmp/prop-host /tmp/prop-host/inside

Repeat with mount --make-rprivate /tmp/prop-host before entering unshare; the nested mount will stop crossing the boundary. That is the same class of failure that appears when a container needs to see host-mounted volumes, CSI mounts, or nested bind mounts but the parent mount tree is private.

Operational interpretation:

Root Changes

chroot changes pathname resolution root for a process, but it is not a complete container boundary. pivot_root and mount namespaces are part of stronger root filesystem isolation used by container runtimes.

Overlay and tmpfs

Overlay filesystems and tmpfs are common runtime mounts. Overlay can make a path look writable while changes land in an upper layer. tmpfs consumes memory-backed storage and can contribute to memory pressure or cgroup limits.

Troubleshooting Flow

1. Identify the affected process PID.
2. Compare host findmnt with nsenter --mount into that process.
3. Read /proc/<pid>/mountinfo.
4. Check bind mount source, target, readonly state, and recursive behavior.
5. Check propagation mode with findmnt.
6. Check systemd unit sandboxing and container runtime mount specs.
7. Remember that changing the host mount tree may not update existing namespaces.

Study Cards

References

• mount_namespaces(7)
• namespaces(7)
• proc_pid_mountinfo(5)
• nsenter(1)
• shared subtree kernel documentation