MS_SHARED and MS_PRIVATE example

Suppose that on a terminal in the initial mount namespace, we mark one mount point as shared and another as private, and then view the mounts in /proc/self/mountinfo:

From the /proc/self/mountinfo output, we see that /mntS is a shared mount in peer group 1, and that /mntP has no optional tags, indicating that it is a private mount. The first two fields in each record in this file are the unique ID for this mount, and the mount ID of the parent mount. We can further inspect this file to see that the parent mount point of /mntS and /mntP is the root directory, /, which is mounted as private:

On a second terminal, we create a new mount namespace where we run a second shell and inspect the mounts:

The new mount namespace received a copy of the initial mount namespace's mount points. These new mount points maintain the same propagation types, but have unique mount IDs. (The −−propagation unchanged option prevents unshare(1) from marking all mounts as private when creating a new mount namespace, which it does by default.)

In the second terminal, we then create submounts under each of /mntS and /mntP and inspect the set-up:

From the above, it can be seen that /mntS/a was created as shared (inheriting this setting from its parent mount) and /mntP/b was created as a private mount.

Returning to the first terminal and inspecting the set-up, we see that the new mount created under the shared mount point /mntS propagated to its peer mount (in the initial mount namespace), but the new mount created under the private mount point /mntP did not propagate:

MS_SLAVE example

Making a mount point a slave allows it to receive propagated mount and unmount events from a master shared peer group, while preventing it from propagating events to that master. This is useful if we want to (say) receive a mount event when an optical disk is mounted in the master shared peer group (in another mount namespace), but want to prevent mount and unmount events under the slave mount from having side effects in other namespaces.

We can demonstrate the effect of slaving by first marking two mount points as shared in the initial mount namespace:

On a second terminal, we create a new mount namespace and inspect the mount points:

In the new mount namespace, we then mark one of the mount points as a slave:

From the above output, we see that /mntY is now a slave mount that is receiving propagation events from the shared peer group with the ID 2.

Continuing in the new namespace, we create submounts under each of /mntX and /mntY:

When we inspect the state of the mount points in the new mount namespace, we see that /mntX/a was created as a new shared mount (inheriting the "shared" setting from its parent mount) and /mntY/b was created as a private mount:

Returning to the first terminal (in the initial mount namespace), we see that the mount /mntX/a propagated to the peer (the shared /mntX), but the mount /mntY/b was not propagated:

Now we create a new mount point under /mntY in the first shell:

When we examine the mount points in the second mount namespace, we see that in this case the new mount has been propagated to the slave mount point, and that the new mount is itself a slave mount (to peer group 4):

MS_UNBINDABLE example

One of the primary purposes of unbindable mounts is to avoid the "mount point explosion" problem when repeatedly performing bind mounts of a higher-level subtree at a lower-level mount point. The problem is illustrated by the following shell session.

Suppose we have a system with the following mount points:

Suppose furthermore that we wish to recursively bind mount the root directory under several users' home directories. We do this for the first user, and inspect the mount points:

When we repeat this operation for the second user, we start to see the explosion problem:

Under /home/henry, we have not only recursively added the /mntX and /mntY mounts, but also the recursive mounts of those directories under /home/cecilia that were created in the previous step. Upon repeating the step for a third user, it becomes obvious that the explosion is exponential in nature:

The mount explosion problem in the above scenario can be avoided by making each of the new mounts unbindable. The effect of doing this is that recursive mounts of the root directory will not replicate the unbindable mounts. We make such a mount for the first user:

Before going further, we show that unbindable mounts are indeed unbindable:

Now we create unbindable recursive bind mounts for the other two users:

Upon examining the list of mount points, we see there has been no explosion of mount points, because the unbindable mounts were not replicated under each user's directory:

Propagation type transitions

The following table shows the effect that applying a new propagation type (i.e., mount −−make−xxxx) has on the existing propagation type of a mount point. The rows correspond to existing propagation types, and the columns are the new propagation settings. For reasons of space, "private" is abbreviated as "priv" and "unbindable" as "unbind".

Note the following details to the table:

Bind (MS_BIND) semantics

Suppose that the following command is performed:

mount −−bind A/a B/b

Here, A is the source mount point, B is the destination mount point, a is a subdirectory path under the mount point A, and b is a subdirectory path under the mount point B. The propagation type of the resulting mount, B/b, depends on the propagation types of the mount points A and B, and is summarized in the following table.

Note that a recursive bind of a subtree follows the same semantics as for a bind operation on each mount in the subtree. (Unbindable mounts are automatically pruned at the target mount point.)

For further details, see Documentation/filesystems/sharedsubtree.txt in the kernel source tree.

Move (MS_MOVE) semantics

Suppose that the following command is performed:

mount −−move A B/b

Here, A is the source mount point, B is the destination mount point, and b is a subdirectory path under the mount point B. The propagation type of the resulting mount, B/b, depends on the propagation types of the mount points A and B, and is summarized in the following table.

	Note
	Moving a mount that resides under a shared mount is invalid.

For further details, see Documentation/filesystems/sharedsubtree.txt in the kernel source tree.

Mount semantics

Suppose that we use the following command to create a mount point:

mount device B/b

Here, B is the destination mount point, and b is a subdirectory path under the mount point B. The propagation type of the resulting mount, B/b, follows the same rules as for a bind mount, where the propagation type of the source mount is considered always to be private.

Unmount semantics

Suppose that we use the following command to tear down a mount point:

unmount A

Here, A is a mount point on B/b, where B is the parent mount and b is a subdirectory path under the mount point B. If B is shared, then all most-recently-mounted mounts at b on mounts that receive propagation from mount B and do not have submounts under them are unmounted.

The /proc/[pid]/mountinfo propagate_from tag

The propagate_from:X tag is shown in the optional fields of a /proc/[pid]/mountinfo record in cases where a process can't see a slave's immediate master (i.e., the pathname of the master is not reachable from the filesystem root directory) and so cannot determine the chain of propagation between the mounts it can see.

In the following example, we first create a two-link master-slave chain between the mounts /mnt, /tmp/etc, and /mnt/tmp/etc. Then the chroot(1) command is used to make the /tmp/etc mount point unreachable from the root directory, creating a situation where the master of /mnt/tmp/etc is not reachable from the (new) root directory of the process.

First, we bind mount the root directory onto /mnt and then bind mount /proc at /mnt/proc so that after the later chroot(1) the proc(5) filesystem remains visible at the correct location in the chroot-ed environment.

Next, we ensure that the /mnt mount is a shared mount in a new peer group (with no peers):

Next, we bind mount /mnt/etc onto /tmp/etc:

Initially, these two mount points are in the same peer group, but we then make the /tmp/etc a slave of /mnt/etc, and then make /tmp/etc shared as well, so that it can propagate events to the next slave in the chain:

Then we bind mount /tmp/etc onto /mnt/tmp/etc. Again, the two mount points are initially in the same peer group, but we then make /mnt/tmp/etc a slave of /tmp/etc:

From the above, we see that /mnt is the master of the slave /tmp/etc, which in turn is the master of the slave /mnt/tmp/etc.

We then chroot(1) to the /mnt directory, which renders the mount with ID 267 unreachable from the (new) root directory:

When we examine the state of the mounts inside the chroot-ed environment, we see the following:

Above, we see that the mount with ID 273 is a slave whose master is the peer group 105. The mount point for that master is unreachable, and so a propagate_from tag is displayed, indicating that the closest dominant peer group (i.e., the nearest reachable mount in the slave chain) is the peer group with the ID 102 (corresponding to the /mnt mount point before the chroot(1) was performed.