Yolinux.com

mount_namespaces manpage

Search topic Section


MOUNT_NAMESPACES(7)	   Linux Programmer's Manual	   MOUNT_NAMESPACES(7)



NAME
       mount_namespaces - overview of Linux mount namespaces

DESCRIPTION
       For an overview of namespaces, see namespaces(7).

       Mount  namespaces provide isolation of the list of mount points seen by
       the processes in each namespace instance.  Thus, the processes in  each
       of  the	mount  namespace  instances will see distinct single-directory
       hierarchies.

       The views provided by  the  /proc/[pid]/mounts,	/proc/[pid]/mountinfo,
       and  /proc/[pid]/mountstats files (all described in proc(5)) correspond
       to the mount namespace in which the process with the PID [pid] resides.
       (All  of the processes that reside in the same mount namespace will see
       the same view in these files.)

       When a  process	creates	 a  new	 mount	namespace  using  clone(2)  or
       unshare(2)  with the CLONE_NEWNS flag, the mount point list for the new
       namespace is a copy of the caller's mount point list.  Subsequent modi-
       fications  to  the  mount point list (mount(2) and umount(2)) in either
       mount namespace will not (by default) affect the mount point list  seen
       in the other namespace (but see the following discussion of shared sub-
       trees).

   Restrictions on mount namespaces
       Note the following points with respect to mount namespaces:

       *  A mount namespace has an owner user namespace.   A  mount  namespace
	  whose	 owner	user namespace is different from the owner user names-
	  pace of its parent mount namespace is considered a  less  privileged
	  mount namespace.

       *  When	creating  a less privileged mount namespace, shared mounts are
	  reduced to slave mounts.  (Shared and	 slave	mounts	are  discussed
	  below.)   This  ensures  that	 mappings performed in less privileged
	  mount namespaces will not propagate to more privileged mount	names-
	  paces.

       *  Mounts  that	come  as  a single unit from more privileged mount are
	  locked together and may not be separated in a less privileged	 mount
	  namespace.   (The unshare(2) CLONE_NEWNS operation brings across all
	  of the mounts from the original mount namespace as  a	 single	 unit,
	  and  recursive mounts that propagate between mount namespaces propa-
	  gate as a single unit.)

       *  The mount(2) flags MS_RDONLY, MS_NOSUID, MS_NOEXEC, and the  "atime"
	  flags	  (MS_NOATIME,	MS_NODIRATIME,	MS_RELATIME)  settings	become
	  locked when propagated from a more privileged to a  less  privileged
	  mount namespace, and may not be changed in the less privileged mount
	  namespace.

       *  A file or directory that is a mount point in one namespace  that  is
	  not a mount point in another namespace, may be renamed, unlinked, or
	  removed (rmdir(2)) in the mount namespace in which it is not a mount
	  point (subject to the usual permission checks).

	  Previously, attempting to unlink, rename, or remove a file or direc-
	  tory that was a mount point in another mount namespace would	result
	  in  the  error  EBUSY.   That	 behavior  had	technical  problems of
	  enforcement (e.g., for NFS) and permitted denial-of-service  attacks
	  against  more	 privileged users.  (i.e., preventing individual files
	  from being updated by bind mounting on top of them).

SHARED SUBTREES
       After the implementation of mount namespaces was completed,  experience
       showed  that  the  isolation that they provided was, in some cases, too
       great.  For example, in order to	 make  a  newly	 loaded	 optical  disk
       available  in  all  mount namespaces, a mount operation was required in
       each namespace.	For this use case, and others, the shared subtree fea-
       ture  was  introduced  in  Linux 2.6.15.	 This feature allows for auto-
       matic, controlled propagation  of  mount	 and  unmount  events  between
       namespaces  (or,	 more  precisely,  between the members of a peer group
       that are propagating events to one another).

       Each mount point is marked (via mount(2)) as having one of the  follow-
       ing propagation types:

       MS_SHARED
	      This  mount  point  shares  events with members of a peer group.
	      Mount and unmount events immediately under this mount point will
	      propagate to the other mount points that are members of the peer
	      group.  Propagation here means that the same  mount  or  unmount
	      will  automatically occur under all of the other mount points in
	      the peer group.  Conversely, mount and unmount events that  take
	      place  under  peer  mount	 points	 will  propagate to this mount
	      point.

       MS_PRIVATE
	      This mount point is private; it does  not	 have  a  peer	group.
	      Mount  and  unmount  events do not propagate into or out of this
	      mount point.

       MS_SLAVE
	      Mount and unmount events propagate into this mount point from  a
	      (master) shared peer group.  Mount and unmount events under this
	      mount point do not propagate to any peer.

	      Note that a mount point can be the slave of another  peer	 group
	      while  at	 the same time sharing mount and unmount events with a
	      peer group of which it is a member.  (More precisely,  one  peer
	      group can be the slave of another peer group.)

       MS_UNBINDABLE
	      This  is	like a private mount, and in addition this mount can't
	      be bind mounted.	Attempts to bind mount	this  mount  (mount(2)
	      with the MS_BIND flag) will fail.

	      When  a  recursive  bind	mount  (mount(2)  with the MS_BIND and
	      MS_REC flags) is performed on  a	directory  subtree,  any  bind
	      mounts  within  the  subtree are automatically pruned (i.e., not
	      replicated) when replicating that subtree to produce the	target
	      subtree.

       For  a  discussion of the propagation type assigned to a new mount, see
       NOTES.

       The propagation type is a per-mount-point setting;  some	 mount	points
       may be marked as shared (with each shared mount point being a member of
       a distinct peer group), while others are private (or slaved or  unbind-
       able).

       Note  that  a  mount's  propagation  type determines whether mounts and
       unmounts of mount points immediately under the mount point  are	propa-
       gated.	Thus,  the  propagation	 type  does  not affect propagation of
       events for grandchildren and further removed descendant	mount  points.
       What  happens  if  the mount point itself is unmounted is determined by
       the propagation type that is in effect for  the	parent	of  the	 mount
       point.

       Members	are  added  to	a  peer	 group when a mount point is marked as
       shared and either:

       *  the mount point is replicated during the creation  of	 a  new	 mount
	  namespace; or

       *  a new bind mount is created from the mount point.

       In  both	 of  these  cases, the new mount point joins the peer group of
       which the existing mount point is a member.  A mount  ceases  to	 be  a
       member  of  a peer group when either the mount is explicitly unmounted,
       or when the mount is implicitly unmounted because a mount namespace  is
       removed (because it has no more member processes).

       The  propagation	 type  of the mount points in a mount namespace can be
       discovered via the "optional fields" exposed in	/proc/[pid]/mountinfo.
       (See  proc(5) for details of this file.)	 The following tags can appear
       in the optional fields for a record in that file:

       shared:X
	      This mount point is shared in peer group X.  Each peer group has
	      a	 unique	 ID that is automatically generated by the kernel, and
	      all mount points in the same peer group will show the  same  ID.
	      (These  IDs  are	assigned starting from the value 1, and may be
	      recycled when a peer group ceases to have any members.)

       master:X
	      This mount is a slave to shared peer group X.

       propagate_from:X (since Linux 2.6.26)
	      This mount is a slave and receives propagation from shared  peer
	      group X.	This tag will always appear in conjunction with a mas-
	      ter:X tag.  Here, X is the closest dominant peer group under the
	      process's	 root  directory.  If X is the immediate master of the
	      mount, or if there is no dominant	 peer  group  under  the  same
	      root, then only the master:X field is present and not the propa-
	      gate_from:X field.  For further details, see below.

       unbindable
	      This is an unbindable mount.

       If none of the above tags is present, then this is a private mount.

   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:

	   sh1# mount --make-shared /mntS
	   sh1# mount --make-private /mntP
	   sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
	   77 61 8:17 / /mntS rw,relatime shared:1
	   83 61 8:15 / /mntP rw,relatime

       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:

	   sh1# cat /proc/self/mountinfo | awk '$1 == 61' | sed 's/ - .*//'
	   61 0 8:2 / / rw,relatime

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

	   $ PS1='sh2# ' sudo unshare -m --propagation unchanged sh
	   sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
	   222 145 8:17 / /mntS rw,relatime shared:1
	   225 145 8:15 / /mntP rw,relatime

       The  new	 mount	namespace  received a copy of the initial mount names-
       pace's mount points.  These new mount points maintain the same propaga-
       tion  types,  but  have unique mount IDs.  (The --propagation unchanged
       option prevents unshare(1) from marking all mounts as private when cre-
       ating 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:

	   sh2# mkdir /mntS/a
	   sh2# mount /dev/sdb6 /mntS/a
	   sh2# mkdir /mntP/b
	   sh2# mount /dev/sdb7 /mntP/b
	   sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
	   222 145 8:17 / /mntS rw,relatime shared:1
	   225 145 8:15 / /mntP rw,relatime
	   178 222 8:22 / /mntS/a rw,relatime shared:2
	   230 225 8:23 / /mntP/b rw,relatime

       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 cre-
       ated under the private mount point /mntP did not propagate:

	   sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
	   77 61 8:17 / /mntS rw,relatime shared:1
	   83 61 8:15 / /mntP rw,relatime
	   179 77 8:22 / /mntS/a rw,relatime shared:2

   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 mas-
       ter 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:

	   sh1# mount --make-shared /mntX
	   sh1# mount --make-shared /mntY
	   sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
	   132 83 8:23 / /mntX rw,relatime shared:1
	   133 83 8:22 / /mntY rw,relatime shared:2

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

	   sh2# unshare -m --propagation unchanged sh
	   sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
	   168 167 8:23 / /mntX rw,relatime shared:1
	   169 167 8:22 / /mntY rw,relatime shared:2

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

	   sh2# mount --make-slave /mntY
	   sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
	   168 167 8:23 / /mntX rw,relatime shared:1
	   169 167 8:22 / /mntY rw,relatime master:2

       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:

	   sh2# mkdir /mntX/a
	   sh2# mount /dev/sda3 /mntX/a
	   sh2# mkdir /mntY/b
	   sh2# mount /dev/sda5 /mntY/b

       When we inspect the state of the mount points in the new	 mount	names-
       pace, 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:

	   sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
	   168 167 8:23 / /mntX rw,relatime shared:1
	   169 167 8:22 / /mntY rw,relatime master:2
	   173 168 8:3 / /mntX/a rw,relatime shared:3
	   175 169 8:5 / /mntY/b rw,relatime

       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:

	   sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
	   132 83 8:23 / /mntX rw,relatime shared:1
	   133 83 8:22 / /mntY rw,relatime shared:2
	   174 132 8:3 / /mntX/a rw,relatime shared:3

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

	   sh1# mkdir /mntY/c
	   sh1# mount /dev/sda1 /mntY/c
	   sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
	   132 83 8:23 / /mntX rw,relatime shared:1
	   133 83 8:22 / /mntY rw,relatime shared:2
	   174 132 8:3 / /mntX/a rw,relatime shared:3
	   178 133 8:1 / /mntY/c rw,relatime shared:4

       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):

	   sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
	   168 167 8:23 / /mntX rw,relatime shared:1
	   169 167 8:22 / /mntY rw,relatime master:2
	   173 168 8:3 / /mntX/a rw,relatime shared:3
	   175 169 8:5 / /mntY/b rw,relatime
	   179 169 8:1 / /mntY/c rw,relatime master: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:

	   # mount | awk '{print $1, $2, $3}'
	   /dev/sda1 on /
	   /dev/sdb6 on /mntX
	   /dev/sdb7 on /mntY

       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:

	   # mount --rbind / /home/cecilia/
	   # mount | awk '{print $1, $2, $3}'
	   /dev/sda1 on /
	   /dev/sdb6 on /mntX
	   /dev/sdb7 on /mntY
	   /dev/sda1 on /home/cecilia
	   /dev/sdb6 on /home/cecilia/mntX
	   /dev/sdb7 on /home/cecilia/mntY

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

	   # mount --rbind / /home/henry
	   # mount | awk '{print $1, $2, $3}'
	   /dev/sda1 on /
	   /dev/sdb6 on /mntX
	   /dev/sdb7 on /mntY
	   /dev/sda1 on /home/cecilia
	   /dev/sdb6 on /home/cecilia/mntX
	   /dev/sdb7 on /home/cecilia/mntY
	   /dev/sda1 on /home/henry
	   /dev/sdb6 on /home/henry/mntX
	   /dev/sdb7 on /home/henry/mntY
	   /dev/sda1 on /home/henry/home/cecilia
	   /dev/sdb6 on /home/henry/home/cecilia/mntX
	   /dev/sdb7 on /home/henry/home/cecilia/mntY

       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:

	   # mount --rbind / /home/otto
	   # mount | awk '{print $1, $2, $3}'
	   /dev/sda1 on /
	   /dev/sdb6 on /mntX
	   /dev/sdb7 on /mntY
	   /dev/sda1 on /home/cecilia
	   /dev/sdb6 on /home/cecilia/mntX
	   /dev/sdb7 on /home/cecilia/mntY
	   /dev/sda1 on /home/henry
	   /dev/sdb6 on /home/henry/mntX
	   /dev/sdb7 on /home/henry/mntY
	   /dev/sda1 on /home/henry/home/cecilia
	   /dev/sdb6 on /home/henry/home/cecilia/mntX
	   /dev/sdb7 on /home/henry/home/cecilia/mntY
	   /dev/sda1 on /home/otto
	   /dev/sdb6 on /home/otto/mntX
	   /dev/sdb7 on /home/otto/mntY
	   /dev/sda1 on /home/otto/home/cecilia
	   /dev/sdb6 on /home/otto/home/cecilia/mntX
	   /dev/sdb7 on /home/otto/home/cecilia/mntY
	   /dev/sda1 on /home/otto/home/henry
	   /dev/sdb6 on /home/otto/home/henry/mntX
	   /dev/sdb7 on /home/otto/home/henry/mntY
	   /dev/sda1 on /home/otto/home/henry/home/cecilia
	   /dev/sdb6 on /home/otto/home/henry/home/cecilia/mntX
	   /dev/sdb7 on /home/otto/home/henry/home/cecilia/mntY

       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:

	   # mount --rbind --make-unbindable / /home/cecilia

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

	   # mkdir /mntZ
	   # mount --bind /home/cecilia /mntZ
	   mount: wrong fs type, bad option, bad superblock on /home/cecilia,
		  missing codepage or helper program, or other error

		  In some cases useful info is found in syslog - try
		  dmesg | tail or so.

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

	   # mount --rbind --make-unbindable / /home/henry
	   # mount --rbind --make-unbindable / /home/otto

       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:

	   # mount | awk '{print $1, $2, $3}'
	   /dev/sda1 on /
	   /dev/sdb6 on /mntX
	   /dev/sdb7 on /mntY
	   /dev/sda1 on /home/cecilia
	   /dev/sdb6 on /home/cecilia/mntX
	   /dev/sdb7 on /home/cecilia/mntY
	   /dev/sda1 on /home/henry
	   /dev/sdb6 on /home/henry/mntX
	   /dev/sdb7 on /home/henry/mntY
	   /dev/sda1 on /home/otto
	   /dev/sdb6 on /home/otto/mntX
	   /dev/sdb7 on /home/otto/mntY

   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".

		     make-shared   make-slave	   make-priv  make-unbind
       shared	     shared	   slave/priv [1]  priv	      unbind
       slave	     slave+shared  slave [2]	   priv	      unbind
       slave+shared  slave+shared  slave	   priv	      unbind
       private	     shared	   priv [2]	   priv	      unbind
       unbindable    shared	   unbind [2]	   priv	      unbind

       Note the following details to the table:

       [1] If a shared mount is the only mount in its peer group, making it  a
	   slave automatically makes it private.

       [2] Slaving a nonshared mount has no effect on the mount.

   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.


				    source(A)
			    shared  private    slave	     unbind
       ---------------------------------------------------------------
       dest(B)	shared	  | shared  shared     slave+shared  invalid
		nonshared | shared  private    slave	     invalid

       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.


				    source(A)
			    shared  private    slave	     unbind
       ------------------------------------------------------------------
       dest(B)	shared	  | shared  shared     slave+shared  invalid
		nonshared | shared  private    slave	     unbindable

       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.

	   # mkdir -p /mnt/proc
	   # mount --bind / /mnt
	   # mount --bind /proc /mnt/proc

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

	   # mount --make-private /mnt	# Isolate from any previous peer group
	   # mount --make-shared /mnt
	   # cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
	   239 61 8:2 / /mnt ... shared:102
	   248 239 0:4 / /mnt/proc ... shared:5

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

	   # mkdir -p /tmp/etc
	   # mount --bind /mnt/etc /tmp/etc
	   # cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
	   239 61 8:2 / /mnt ... shared:102
	   248 239 0:4 / /mnt/proc ... shared:5
	   267 40 8:2 /etc /tmp/etc ... shared:102

       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:

	   # mount --make-slave /tmp/etc
	   # mount --make-shared /tmp/etc
	   # cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
	   239 61 8:2 / /mnt ... shared:102
	   248 239 0:4 / /mnt/proc ... shared:5
	   267 40 8:2 /etc /tmp/etc ... shared:105 master:102

       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:

	   # mkdir -p /mnt/tmp/etc
	   # mount --bind /tmp/etc /mnt/tmp/etc
	   # mount --make-slave /mnt/tmp/etc
	   # cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
	   239 61 8:2 / /mnt ... shared:102
	   248 239 0:4 / /mnt/proc ... shared:5
	   267 40 8:2 /etc /tmp/etc ... shared:105 master:102
	   273 239 8:2 /etc /mnt/tmp/etc ... master:105

       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:

	   # chroot /mnt

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

	   # cat /proc/self/mountinfo | sed 's/ - .*//'
	   239 61 8:2 / / ... shared:102
	   248 239 0:4 / /proc ... shared:5
	   273 239 8:2 /etc /tmp/etc ... master:105 propagate_from:102

       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.

VERSIONS
       Mount namespaces first appeared in Linux 2.4.19.

CONFORMING TO
       Namespaces are a Linux-specific feature.

NOTES
       The propagation type assigned to a new mount point depends on the prop-
       agation	type of the parent directory.  If the mount point has a parent
       (i.e., it is a non-root mount point) and the propagation	 type  of  the
       parent is MS_SHARED, then the propagation type of the new mount is also
       MS_SHARED.  Otherwise, the propagation type of the new mount is MS_PRI-
       VATE.  But see also NOTES.

       Notwithstanding	the  fact  that	 the  default propagation type for new
       mount points is in many cases MS_PRIVATE, MS_SHARED is  typically  more
       useful.	 For  this reason, systemd(1) automatically remounts all mount
       points as MS_SHARED on system startup.  Thus, on most  modern  systems,
       the default propagation type is in practice MS_SHARED.

       Since,  when  one uses unshare(1) to create a mount namespace, the goal
       is commonly to provide full isolation of the mount points  in  the  new
       namespace,  unshare(1) (since util-linux version 2.27) in turn reverses
       the step performed by systemd(1), by making all mount points private in
       the  new namespace.  That is, unshare(1) performs the equivalent of the
       following in the new mount namespace:

	   mount --make-rprivate /

       To prevent this, one can	 use  the  --propagation unchanged  option  to
       unshare(1).

       For  a discussion of propagation types when moving mounts (MS_MOVE) and
       creating bind mounts (MS_BIND),	see  Documentation/filesystems/shared-
       subtree.txt.

SEE ALSO
       unshare(1),   clone(2),	 mount(2),  setns(2),  umount(2),  unshare(2),
       proc(5), namespaces(7), user_namespaces(7)

       Documentation/filesystems/sharedsubtree.txt in the kernel source tree.

COLOPHON
       This page is part of release 4.10 of the Linux  man-pages  project.   A
       description  of	the project, information about reporting bugs, and the
       latest	 version    of	  this	  page,	   can	   be	  found	    at
       https://www.kernel.org/doc/man-pages/.



Linux				  2016-12-12		   MOUNT_NAMESPACES(7)