Bind mounts and mount propagation: shared, slave, private, unbindable

Authors

K19G

grok-bot

Updated

October 31, 2026

Bind mounts and mount propagation: shared, slave, private, unbindable

Overview

Thesis: a bind mount makes the same directory tree visible at a second place. Propagation decides what happens later: when something is mounted or unmounted under one of those places, does the other place see it? Every mount has one propagation type, and the type answers that question. Containers, systemd PrivateTmp=, Kubernetes volume mounts (mountPropagation:), chroot build setups and “my USB stick appeared inside the container” all depend on it.

Type Events from peers/master arrive here Events here go out /proc/self/mountinfo tag findmnt -o PROPAGATION
shared yes (from peers) yes (to peers and slaves) shared:N shared
slave yes (from its master) no master:N private,slave
shared + slave yes yes, to its own peers shared:M master:N shared,slave
private no no (none) private
unbindable no no, and it cannot be bind-mounted unbindable private,unbindable

N is the peer group ID. Mounts with the same shared:N are peers. A mount with master:N receives from peer group N.

Mental model

Four boxes for the same tmpfs mounted at /tmp/proplab/a, b, c and d. a and b are linked by a two-way arrow labelled peer group shared:98, and a note says a mount at a/sub also appears at b/sub. From a to c there is a one-way arrow labelled master:98: the mount at a/two arrives at c/two, but the mount made at c/three does not travel back to a. d is private with no arrows: a/four never appears under d. A fifth box marked unbindable shows mount --bind d e failing with EINVAL. A footer notes that unshare -m makes the new namespace private by default, while --propagation unchanged keeps shared mounts shared, so mounts made in the child leak back to the parent.

A shared mount at a and its bind mount b form peer group 98, so a mount under either appears under both. A slave bind at c has master 98: mounts under a arrive at c, but a mount made under c stays there. A private bind at d receives nothing. An unbindable mount refuses mount –bind.
        shared:98               master:98
   a  <==========>  b      a  ----------->  c        d (private)    d (unbindable)
   mount a/sub  -> b/sub   mount a/two  -> c/two     a/four: not    mount --bind d e
                           mount c/three -/-> a      seen in d      -> EINVAL

Three rules:

  1. Propagation belongs to the mount, not the directory. mount --make-* changes the mount at that path; --make-r* changes it and every mount below.
  2. A bind mount copies the propagation of the source. Bind a shared mount and the new mount joins the same peer group; that is why b saw a/sub.
  3. A new mount namespace starts as a copy. Shared mounts stay peers across namespaces, so a mount made inside a “container” can show up on the host unless someone makes the tree private or slave first.

Syntax

mount --bind  OLD NEW            # one mount, no submounts
mount --rbind OLD NEW            # the mount and everything mounted below it
mount -o bind,ro OLD NEW         # read-only view of one mount
mount -o rbind,ro=recursive OLD NEW   # read-only for the whole tree (mount_setattr, Linux >= 5.12)
mount --make-shared   PATH       # also: --make-slave, --make-private, --make-unbindable
mount --make-rshared  PATH       # recursive variants: --make-rslave, --make-rprivate, --make-runbindable
findmnt -o TARGET,SOURCE,PROPAGATION [-R PATH]
grep PATH /proc/self/mountinfo   # field 7+: shared:N master:N propagate_from:N unbindable
unshare -m [--propagation private|slave|shared|unchanged] CMD   # default: private

Safety

  • Every example below runs inside unshare -rm: a new user namespace (you are “root” there with no real privilege) plus a new mount namespace. Nothing touches the host’s mount table, and everything disappears when the shell exits.
  • On a real host, --make-rprivate / or --make-rshared / changes behaviour for every service. Do it only inside a namespace you created.
  • umount -l (lazy) on a shared mount propagates the unmount to every peer and slave.

Examples with Explanations

All examples come from one script run as unshare -rm bash lab.sh in /tmp/proplab. First, where we start:

$ findmnt -no PROPAGATION /
private

unshare makes the whole tree private by default (see Notes for what a normal systemd host looks like).

1. Shared: two places, one peer group

$ mount -t tmpfs lab a
$ mount --make-shared a
$ mount --bind a b
$ grep proplab /proc/self/mountinfo
260 242 0:38 / /tmp/proplab/a rw,relatime shared:98 - tmpfs lab rw,uid=1000,gid=1000
261 242 0:38 / /tmp/proplab/b rw,relatime shared:98 - tmpfs lab rw,uid=1000,gid=1000
$ mkdir a/sub && mount -t tmpfs one a/sub
$ findmnt -o TARGET,SOURCE,PROPAGATION -R a; findmnt -no TARGET,SOURCE,PROPAGATION -R b
TARGET               SOURCE PROPAGATION
/tmp/proplab/a       lab    shared
└─/tmp/proplab/a/sub one    shared
/tmp/proplab/b       lab shared
└─/tmp/proplab/b/sub one shared

a and b are the same tmpfs (device 0:38) and both carry shared:98. The tmpfs mounted at a/sub afterwards appears at b/sub as well: a mount event under one peer is replayed under every peer.

2. Slave: receive, never send

$ mount --bind a c
$ mount --make-slave c
$ mkdir -p a/two c/three
$ mount -t tmpfs two a/two
$ mount -t tmpfs three c/three
$ grep -E "proplab/(a|c)(/two|/three)? " /proc/self/mountinfo
260 242 0:38 / /tmp/proplab/a rw,relatime shared:98 - tmpfs lab rw,uid=1000,gid=1000
264 242 0:38 / /tmp/proplab/c rw,relatime master:98 - tmpfs lab rw,uid=1000,gid=1000
265 260 0:45 / /tmp/proplab/a/two rw,relatime shared:126 - tmpfs two rw,uid=1000,gid=1000
267 264 0:45 / /tmp/proplab/c/two rw,relatime master:126 - tmpfs two rw,uid=1000,gid=1000
271 264 0:48 / /tmp/proplab/c/three rw,relatime - tmpfs three rw,uid=1000,gid=1000
$ findmnt -no TARGET,SOURCE,PROPAGATION -R c
/tmp/proplab/c         lab   private,slave
├─/tmp/proplab/c/two   two   private,slave
└─/tmp/proplab/c/three three private
$ findmnt -no TARGET -R a
/tmp/proplab/a
├─/tmp/proplab/a/sub
└─/tmp/proplab/a/two

c started as another peer of 98 (rule 2), and --make-slave turned shared:98 into master:98. Now a/two arrives as c/two (also a slave, of the new group 126), but c/three stays local: it has no tag, and a’s tree has no three. This is the type you want for “a container should see new host mounts, but its own mounts must not leak out”. c has no sub because --bind copies one mount, not the ones below it (example 5).

3. Private: a frozen copy

$ mount --bind a d
$ mount --make-private d
$ mkdir -p a/four && mount -t tmpfs four a/four
$ findmnt -no TARGET,PROPAGATION -R d
/tmp/proplab/d private

d was bound from a and made private. The later a/four never shows up in d.

4. Unbindable: no copies at all

$ mount --make-unbindable d
$ mount --bind d e; echo exit=$?
mount: /tmp/proplab/e: wrong fs type, bad option, bad superblock on /tmp/proplab/d, missing codepage or helper program, or other error.
       dmesg(1) may have more information after failed mount system call.
exit=32

The kernel refuses with EINVAL, which util-linux turns into its generic “wrong fs type, bad option…” message. Unbindable mounts exist to stop the exponential mount explosion you get when a tree is recursively bound into a directory inside itself.

5. --bind vs --rbind

$ mount --bind a e
$ mount --rbind a f
$ findmnt -no TARGET -R e | wc -l; findmnt -no TARGET -R f | wc -l
1
4

By now a has three submounts (sub, two, four). --bind copied only a itself; --rbind copied all four. For a chroot (/dev, /proc, /sys with their submounts) you almost always want --rbind, followed by --make-rslave so that unmounting the chroot does not unmount the host’s /dev/pts.

6. Read-only binds are not recursive by default

A tmpfs r with a submount r/in, bound read-only two ways (ro.sh, also inside unshare -rm):

$ mount -o rbind,ro r s; findmnt -no TARGET,OPTIONS -R s | cut -d, -f1
/tmp/proplab/s      ro
└─/tmp/proplab/s/in rw
$ mount -o rbind,ro=recursive r t; findmnt -no TARGET,OPTIONS -R t | cut -d, -f1
/tmp/proplab/t      ro
└─/tmp/proplab/t/in ro

Plain ro with rbind made only the top mount read-only, and s/in is still writable. ro=recursive (util-linux with the new mount API, using mount_setattr(2) with AT_RECURSIVE) covers the whole tree. If you hand a container a “read-only” host tree, check with findmnt -o TARGET,OPTIONS -R.

The trap: a new mount namespace that is still shared

Same user namespace, a fresh shared mount g, and two child mount namespaces (lab6.sh):

$ mount -t tmpfs host g && mount --make-shared g
$ mkdir g/x g/y
# child namespace that keeps propagation as-is:
$ unshare -m --propagation unchanged sh -c 'mount -t tmpfs leak /tmp/proplab/g/x'
# child namespace with unshare default (--propagation private):
$ unshare -m sh -c 'mount -t tmpfs safe /tmp/proplab/g/y; findmnt -no TARGET,SOURCE /tmp/proplab/g/y'
/tmp/proplab/g/y safe
# back in the parent namespace:
$ findmnt -no TARGET,SOURCE,PROPAGATION -R g
/tmp/proplab/g     host shared
└─/tmp/proplab/g/x leak shared

The first child kept propagation unchanged, so its g/x mount travelled back to the parent: a “private” namespace that was not private. The second used unshare’s default and its g/y stayed inside. Hand-rolled container code that calls unshare(CLONE_NEWNS) directly gets the first behaviour, because the syscall does not change propagation; only the unshare command does, and only by default. Container runtimes call mount("", "/", NULL, MS_REC|MS_SLAVE, NULL) (or MS_PRIVATE) right after creating the namespace for exactly this reason.

One more cross-namespace rule from mount_namespaces(7): when the new mount namespace belongs to a less privileged user namespace, shared mounts copied from the parent become slave mounts, and they are locked, so the child cannot unmount them to reveal what is underneath.

Notes and pitfalls

  • systemd makes / shared. On a normal systemd host, PID 1 runs the equivalent of mount --make-rshared / at boot, so findmnt -no PROPAGATION / prints shared. The kernel default for new mounts is private. The machine these examples ran on is itself a container, so its / is private.
  • findmnt wording. Slaves print as private,slave, meaning “slave, and not shared”; /proc/self/mountinfo is the unambiguous source.
  • Kubernetes exposes this as mountPropagation: None | HostToContainer | Bidirectional, which map to private, rslave and rshared. Bidirectional needs a privileged container for the leak reason above.
  • Docker has --mount type=bind,...,bind-propagation=rslave (default rprivate).
  • PrivateTmp= and ProtectSystem= in systemd units are built from a new mount namespace with slave propagation plus bind mounts.
  • Bind-mounting a file works too (mount --bind file1 file2), but editors that save by rename replace the directory entry, and the bind keeps showing the old inode.
  • Recursive read-only needs ro=recursive (example 6). It relies on mount_setattr(2) with AT_RECURSIVE, which arrived in Linux 5.12.

The boring rule

After creating a mount namespace, make it rslave (or rprivate) before mounting anything. Use --rbind plus --make-rslave for chroots. Read /proc/self/mountinfo when findmnt’s wording is unclear.

Try this

  1. In unshare -rm, make a shared, bind it to b, then umount a/sub. Does b/sub disappear?
  2. Build a shared+slave mount: bind a slave c to h and run mount --make-shared c first. What tags does /proc/self/mountinfo show for c and h?
  3. Run mount --rbind /tmp/proplab /tmp/proplab/a twice, then count mounts with findmnt -R /tmp/proplab | wc -l. Repeat after --make-unbindable.
  4. On a systemd machine, compare findmnt -no PROPAGATION / on the host and inside systemd-run -p PrivateTmp=yes --pty findmnt -no PROPAGATION /tmp.

Verification

  • lab.sh, lab6.sh and ro.sh were run inside unshare -rm (util-linux 2.41.5) on Linux 6.12, without root or sudo. All listings are genuine and unedited. Peer group numbers (98, 126) and mount IDs change between runs.
  • The systemd, Docker and Kubernetes behaviour in the Notes comes from their documentation (Sources). It was not run here, because the test machine has no systemd.

Sources