Read mountinfo first

 3 min Before explaining a mount, read /proc/self/mountinfo—the kernel’s live table shows what mount(8) output hides.

When a mount is visible where it shouldn’t be, or missing where it should be, read the kernel’s table before reconstructing the commands:

cat /proc/self/mountinfo

In an lxc-users thread, Michael H. Warfield asked how to inspect propagation flags, and Serge Hallyn pointed him to /proc/self/mountinfo. I was discussing propagation policy and bind-mount topology in the same thread. The file let us inspect what the kernel had arranged.

What mountinfo shows that ordinary mount output hides—acutely so in 2011, when mount(8) still printed /etc/mtab, a userspace file that could drift from reality:

• Propagation flags. The optional fields describe sharing, upstream propagation, and whether a mount can be bind-mounted. A plain mount listing cannot distinguish a shared mount from a private one, and propagation is the entire question in a container-visibility dispute.
• Peer and upstream groups. shared:N says this mount belongs to peer group N; mounts carrying the same value propagate among those peers. master:N identifies the upstream peer group whose events this mount receives without sending changes back. A mount can belong to group M and receive from group N, forwarding events among its own peers and further downstream. Matching shared IDs finds peers; matching an upstream group ID against those IDs traces the direction between groups.
• Mount and parent IDs. Each line names its own ID and its parent’s, exposing the mount tree and overmounted (shadowed) mounts. A parent outside the process’s root has no corresponding row; a missing parent ID is not by itself a corrupt table.
• The root field. For bind mounts, which subtree of the source filesystem this mount exposes—the difference between “the same disk” and “the same directory”.

The self in the path is half the tool. Every process reads the table of its own mount namespace, so comparing /proc/<pid1>/mountinfo against /proc/<pid2>/mountinfo is comparing namespaces directly. “Unexpected visibility” localizes fast. First test whether the mounts share a peer group and propagation did what shared mounts do. Then test whether the two processes are in the namespaces you thought they were. If neither settles it, compare the mount and parent IDs, the bind root, and any overmounts; namespace identity and propagation are the first branches, not an exhaustive pair.

The gotcha: mount IDs are not stable—they are reused across mount/unmount cycles and mean nothing across reboots—and peer-group numbers are only meaningful relatively, for matching lines against each other. Today findmnt -o TARGET,PROPAGATION renders the same file legibly, but it is the same file; when the pretty view seems wrong, the raw table settles it.

The directional argument that thread was about is its own note: propagation is a direction.