1 .\" Copyright (c) 2016 by Michael Kerrisk <mtk.manpages@gmail.com>
3 .\" %%%LICENSE_START(VERBATIM)
4 .\" Permission is granted to make and distribute verbatim copies of this
5 .\" manual provided the copyright notice and this permission notice are
6 .\" preserved on all copies.
8 .\" Permission is granted to copy and distribute modified versions of this
9 .\" manual under the conditions for verbatim copying, provided that the
10 .\" entire resulting derived work is distributed under the terms of a
11 .\" permission notice identical to this one.
13 .\" Since the Linux kernel and libraries are constantly changing, this
14 .\" manual page may be incorrect or out-of-date. The author(s) assume no
15 .\" responsibility for errors or omissions, or for damages resulting from
16 .\" the use of the information contained herein. The author(s) may not
17 .\" have taken the same level of care in the production of this manual,
18 .\" which is licensed free of charge, as they might when working
21 .\" Formatted or processed versions of this manual, if unaccompanied by
22 .\" the source, must acknowledge the copyright and authors of this work.
26 .TH MOUNT_NAMESPACES 7 2016-07-17 "Linux" "Linux Programmer's Manual"
28 mount_namespaces \- overview of Linux mount namespaces
30 For an overview of namespaces, see
33 Mount namespaces provide isolation of the list of mount points seen
34 by the processes in each namespace instance.
35 Thus, the processes in each of the mount namespace instances
36 will see distinct single-directory hierarchies.
38 The views provided by the
39 .IR /proc/[pid]/mounts ,
40 .IR /proc/[pid]/mountinfo ,
42 .IR /proc/[pid]/mountstats
43 files (all described in
45 correspond to the mount namespace in which the process with the PID
48 (All of the processes that reside in the same mount namespace
49 will see the same view in these files.)
51 When a process creates a new mount namespace using
57 flag, the mount point list for the new namespace is a
59 of the caller's mount point list.
60 Subsequent modifications to the mount point list
64 in either mount namespace will not (by default) affect the
65 mount point list seen in the other namespace
66 (but see the following discussion of shared subtrees).
69 After the implementation of mount namespaces was completed,
70 experience showed that the isolation that they provided was,
71 in some cases, too great.
72 For example, in order to make a newly loaded optical disk
73 available in all mount namespaces,
74 a mount operation was required in each namespace.
75 For this use case, and others,
76 the shared subtree feature was introduced in Linux 2.6.15.
77 This feature allows for automatic, controlled propagation of mount and unmount
80 (or, more precisely, between the members of a
82 that are propagating events to one another).
84 Each mount point is marked (via
86 as having one of the following
87 .IR "propagation types" :
90 This mount point shares events with members of a peer group.
91 Mount and unmount events immediately under this mount point will propagate
92 to the other mount points that are members of the peer group.
94 here means that the same mount or unmount will automatically occur
95 under all of the other mount points in the peer group.
96 Conversely, mount and unmount events that take place under
97 peer mount points will propagate to this mount point.
100 This mount point is private; it does not have a peer group.
101 Mount and unmount events do not propagate into or out of this mount point.
102 This is the default propagation type for newly created mount points
106 Mount and unmount events propagate into this mount point from
107 a (master) shared peer group.
108 Mount and unmount events under this mount point do not propagate to any peer.
110 Note that a mount point can be the slave of another peer group
111 while at the same time sharing mount and unmount events
112 with a peer group of which it is a member.
113 (More precisely, one peer group can be the slave of another peer group.)
116 This is like a private mount,
117 and in addition this mount can't be bind mounted.
118 Attempts to bind mount this mount
124 When a recursive bind mount
130 flags) is performed on a directory subtree,
131 any bind mounts within the subtree are automatically pruned
132 (i.e., not replicated)
133 when replicating that subtree to produce the target subtree.
135 The propagation type is a per-mount-point setting;
136 some mount points may be marked as shared
137 (with each shared mount point being a member of a distinct peer group),
138 while others are private
139 (or slaved or unbindable).
141 Note that a mount's propagation type determines whether
142 mounts and unmounts of mount points
143 .I "immediately under"
144 the mount point are propagated.
145 Thus, the propagation type does not affect propagation of events for
146 grandchildren and further removed descendant mount points.
147 What happens if the mount point itself is unmounted is determined by
148 the propagation type that is in effect for the
152 Members are added to a
154 when a mount point is marked as shared and either:
156 the mount point is replicated during the creation of a new mount namespace; or
158 a new bind mount is created from the mount point.
160 In both of these cases, the new mount point joins the peer group
161 of which the existing mount point is a member.
162 A mount ceases to be a member of a peer group when either
163 the mount is explicitly unmounted,
164 or when the mount is implicitly unmounted because a mount namespace is removed
165 (because it has no more member processes).
167 The propagation type of the mount points in a mount namespace
168 can be discovered via the "optional fields" exposed in
169 .IR /proc/[pid]/mountinfo .
172 for details of this file.)
173 The following tags can appear in the optional fields
174 for a record in that file:
177 This mount point is shared in peer group
179 Each peer group has a unique ID that is automatically
180 generated by the kernel,
181 and all mount points in the same peer group will show the same ID.
182 (These IDs are assigned starting from the value 1,
183 and may be recycled when a peer group ceases to have any members.)
186 This mount is a slave to shared peer group
189 .IR propagate_from:X " (since Linux 2.6.26)"
190 .\" commit 97e7e0f71d6d948c25f11f0a33878d9356d9579e
191 This mount is a slave and receives propagation from shared peer group
193 This tag will always appear in conjunction with a
198 is the closest dominant peer group under the process's root directory.
201 is the immediate master of the mount,
202 or if there is no dominant peer group under the same root,
205 field is present and not the
208 For further details, see below.
211 This is an unbindable mount.
213 If none of the above tags is present, then this is a private mount.
214 .SS MS_SHARED and MS_PRIVATE example
215 Suppose that on a terminal in the initial mount namespace,
216 we mark one mount point as shared and another as private,
217 and then view the mounts in
218 .IR /proc/self/mountinfo :
222 sh1# \fBmount \-\-make\-shared /mntS\fP
223 sh1# \fBmount \-\-make\-private /mntP\fP
224 sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
225 77 61 8:17 / /mntS rw,relatime shared:1
226 83 61 8:15 / /mntP rw,relatime
231 .IR /proc/self/mountinfo
234 is a shared mount in peer group 1, and that
236 has no optional tags, indicating that it is a private mount.
237 The first two fields in each record in this file are the unique
238 ID for this mount, and the mount ID of the parent mount.
239 We can further inspect this file to see that the parent mount point of
243 is the root directory,
245 which is mounted as private:
249 sh1# \fBcat /proc/self/mountinfo | awk \(aq$1 == 61\(aq | sed \(aqs/ \- .*//\(aq\fP
250 61 0 8:2 / / rw,relatime
254 On a second terminal,
255 we create a new mount namespace where we run a second shell
256 and inspect the mounts:
260 $ \fBPS1=\(aqsh2# \(aq sudo unshare \-m \-\-propagation unchanged sh\fP
261 sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
262 222 145 8:17 / /mntS rw,relatime shared:1
263 225 145 8:15 / /mntP rw,relatime
267 The new mount namespace received a copy of the initial mount namespace's
269 These new mount points maintain the same propagation types,
270 but have unique mount IDs.
272 .IR \-\-propagation\ unchanged
275 from marking all mounts as private when creating a new mount namespace,
276 .\" Since util-linux 2.27
277 which it does by default.)
279 In the second terminal, we then create submounts under each of
283 and inspect the set-up:
287 sh2# \fBmkdir /mntS/a\fP
288 sh2# \fBmount /dev/sdb6 /mntS/a\fP
289 sh2# \fBmkdir /mntP/b\fP
290 sh2# \fBmount /dev/sdb7 /mntP/b\fP
291 sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
292 222 145 8:17 / /mntS rw,relatime shared:1
293 225 145 8:15 / /mntP rw,relatime
294 178 222 8:22 / /mntS/a rw,relatime shared:2
295 230 225 8:23 / /mntP/b rw,relatime
299 From the above, it can be seen that
301 was created as shared (inheriting this setting from its parent mount) and
303 was created as a private mount.
305 Returning to the first terminal and inspecting the set-up,
306 we see that the new mount created under the shared mount point
308 propagated to its peer mount (in the initial mount namespace),
309 but the new mount created under the private mount point
315 sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
316 77 61 8:17 / /mntS rw,relatime shared:1
317 83 61 8:15 / /mntP rw,relatime
318 179 77 8:22 / /mntS/a rw,relatime shared:2
323 Making a mount point a slave allows it to receive propagated
324 mount and unmount events from a master shared peer group,
325 while preventing it from propagating events to that master.
326 This is useful if we want to (say) receive a mount event when
327 an optical disk is mounted in the master shared peer group
328 (in another mount namespace),
329 but want to prevent mount and unmount events under the slave mount
330 from having side effects in other namespaces.
332 We can demonstrate the effect of slaving by first marking
333 two mount points as shared in the initial mount namespace:
337 sh1# \fBmount \-\-make\-shared /mntX\fP
338 sh1# \fBmount \-\-make\-shared /mntY\fP
339 sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
340 132 83 8:23 / /mntX rw,relatime shared:1
341 133 83 8:22 / /mntY rw,relatime shared:2
345 On a second terminal,
346 we create a new mount namespace and inspect the mount points:
350 sh2# \fBunshare \-m \-\-propagation unchanged sh\fP
351 sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
352 168 167 8:23 / /mntX rw,relatime shared:1
353 169 167 8:22 / /mntY rw,relatime shared:2
357 In the new mount namespace, we then mark one of the mount points as a slave:
361 sh2# \fBmount \-\-make\-slave /mntY\fP
362 sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
363 168 167 8:23 / /mntX rw,relatime shared:1
364 169 167 8:22 / /mntY rw,relatime master:2
368 From the above output, we see that
370 is now a slave mount that is receiving propagation events from
371 the shared peer group with the ID 2.
373 Continuing in the new namespace, we create submounts under each of
380 sh2# \fBmkdir /mntX/a\fP
381 sh2# \fBmount /dev/sda3 /mntX/a\fP
382 sh2# \fBmkdir /mntY/b\fP
383 sh2# \fBmount /dev/sda5 /mntY/b\fP
387 When we inspect the state of the mount points in the new mount namespace,
390 was created as a new shared mount
391 (inheriting the "shared" setting from its parent mount) and
393 was created as a private mount:
397 sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
398 168 167 8:23 / /mntX rw,relatime shared:1
399 169 167 8:22 / /mntY rw,relatime master:2
400 173 168 8:3 / /mntX/a rw,relatime shared:3
401 175 169 8:5 / /mntY/b rw,relatime
405 Returning to the first terminal (in the initial mount namespace),
406 we see that the mount
408 propagated to the peer (the shared
416 sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
417 132 83 8:23 / /mntX rw,relatime shared:1
418 133 83 8:22 / /mntY rw,relatime shared:2
419 174 132 8:3 / /mntX/a rw,relatime shared:3
423 Now we create a new mount point under
429 sh1# \fBmkdir /mntY/c\fP
430 sh1# \fBmount /dev/sda1 /mntY/c\fP
431 sh1# \fBcat /proc/self/mountinfo | grep '/mnt' | sed 's/ \- .*//'\fP
432 132 83 8:23 / /mntX rw,relatime shared:1
433 133 83 8:22 / /mntY rw,relatime shared:2
434 174 132 8:3 / /mntX/a rw,relatime shared:3
435 178 133 8:1 / /mntY/c rw,relatime shared:4
439 When we examine the mount points in the second mount namespace,
440 we see that in this case the new mount has been propagated
441 to the slave mount point,
442 and that the new mount is itself a slave mount (to peer group 4):
446 sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
447 168 167 8:23 / /mntX rw,relatime shared:1
448 169 167 8:22 / /mntY rw,relatime master:2
449 173 168 8:3 / /mntX/a rw,relatime shared:3
450 175 169 8:5 / /mntY/b rw,relatime
451 179 169 8:1 / /mntY/c rw,relatime master:4
455 .SS MS_UNBINDABLE example
456 One of the primary purposes of unbindable mounts is to avoid
457 the "mount point explosion" problem when repeatedly performing bind mounts
458 of a higher-level subtree at a lower-level mount point.
459 The problem is illustrated by the following shell session.
461 Suppose we have a system with the following mount points:
465 # \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP
472 Suppose furthermore that we wish to recursively bind mount
473 the root directory under several users' home directories.
474 We do this for the first user, and inspect the mount points:
478 # \fBmount \-\-rbind / /home/cecilia/\fP
479 # \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP
483 /dev/sda1 on /home/cecilia
484 /dev/sdb6 on /home/cecilia/mntX
485 /dev/sdb7 on /home/cecilia/mntY
489 When we repeat this operation for the second user,
490 we start to see the explosion problem:
494 # \fBmount \-\-rbind / /home/henry\fP
495 # \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP
499 /dev/sda1 on /home/cecilia
500 /dev/sdb6 on /home/cecilia/mntX
501 /dev/sdb7 on /home/cecilia/mntY
502 /dev/sda1 on /home/henry
503 /dev/sdb6 on /home/henry/mntX
504 /dev/sdb7 on /home/henry/mntY
505 /dev/sda1 on /home/henry/home/cecilia
506 /dev/sdb6 on /home/henry/home/cecilia/mntX
507 /dev/sdb7 on /home/henry/home/cecilia/mntY
513 we have not only recursively added the
517 mounts, but also the recursive mounts of those directories under
519 that were created in the previous step.
520 Upon repeating the step for a third user,
521 it becomes obvious that the explosion is exponential in nature:
525 # \fBmount \-\-rbind / /home/otto\fP
526 # \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP
530 /dev/sda1 on /home/cecilia
531 /dev/sdb6 on /home/cecilia/mntX
532 /dev/sdb7 on /home/cecilia/mntY
533 /dev/sda1 on /home/henry
534 /dev/sdb6 on /home/henry/mntX
535 /dev/sdb7 on /home/henry/mntY
536 /dev/sda1 on /home/henry/home/cecilia
537 /dev/sdb6 on /home/henry/home/cecilia/mntX
538 /dev/sdb7 on /home/henry/home/cecilia/mntY
539 /dev/sda1 on /home/otto
540 /dev/sdb6 on /home/otto/mntX
541 /dev/sdb7 on /home/otto/mntY
542 /dev/sda1 on /home/otto/home/cecilia
543 /dev/sdb6 on /home/otto/home/cecilia/mntX
544 /dev/sdb7 on /home/otto/home/cecilia/mntY
545 /dev/sda1 on /home/otto/home/henry
546 /dev/sdb6 on /home/otto/home/henry/mntX
547 /dev/sdb7 on /home/otto/home/henry/mntY
548 /dev/sda1 on /home/otto/home/henry/home/cecilia
549 /dev/sdb6 on /home/otto/home/henry/home/cecilia/mntX
550 /dev/sdb7 on /home/otto/home/henry/home/cecilia/mntY
554 The mount explosion problem in the above scenario can be avoided
555 by making each of the new mounts unbindable.
556 The effect of doing this is that recursive mounts of the root
557 directory will not replicate the unbindable mounts.
558 We make such a mount for the first user:
562 # \fBmount \-\-rbind \-\-make\-unbindable / /home/cecilia\fP
566 Before going further, we show that unbindable mounts are indeed unbindable:
571 # \fBmount \-\-bind /home/cecilia /mntZ\fP
572 mount: wrong fs type, bad option, bad superblock on /home/cecilia,
573 missing codepage or helper program, or other error
575 In some cases useful info is found in syslog \- try
580 Now we create unbindable recursive bind mounts for the other two users:
584 # \fBmount \-\-rbind \-\-make\-unbindable / /home/henry\fP
585 # \fBmount \-\-rbind \-\-make\-unbindable / /home/otto\fP
589 Upon examining the list of mount points,
590 we see there has been no explosion of mount points,
591 because the unbindable mounts were not replicated
592 under each user's directory:
596 # \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP
600 /dev/sda1 on /home/cecilia
601 /dev/sdb6 on /home/cecilia/mntX
602 /dev/sdb7 on /home/cecilia/mntY
603 /dev/sda1 on /home/henry
604 /dev/sdb6 on /home/henry/mntX
605 /dev/sdb7 on /home/henry/mntY
606 /dev/sda1 on /home/otto
607 /dev/sdb6 on /home/otto/mntX
608 /dev/sdb7 on /home/otto/mntY
612 .SS Propagation type transitions
613 The following table shows the effect that applying a new propagation type
615 .IR "mount \-\-make\-xxxx")
616 has on the existing propagation type of a mount point.
617 The rows correspond to existing propagation types,
618 and the columns are the new propagation settings.
619 For reasons of space, "private" is abbreviated as "priv" and
620 "unbindable" as "unbind".
624 make-shared make-slave make-priv make-unbind
625 shared shared slave/priv [1] priv unbind
626 slave slave+shared slave [2] priv unbind
627 slave+shared slave+shared slave priv unbind
628 private shared priv [2] priv unbind
629 unbindable shared unbind [2] priv unbind
632 Note the following details to the table:
634 If a shared mount is the only mount in its peer group,
635 making it a slave automatically makes it private.
637 Slaving a nonshared mount has no effect on the mount.
639 .SS Bind (MS_BIND) semantics
640 Suppose that the following command is performed:
642 mount \-\-bind A/a B/b
646 is the source mount point,
648 is the destination mount point,
650 is a subdirectory path under the mount point
654 is a subdirectory path under the mount point
656 The propagation type of the resulting mount,
658 depends on the propagation types of the mount points
662 and is summarized in the following table.
665 lb2 lb1 lb2 lb2 lb2 lb0
666 lb2 lb1 lb2 lb2 lb2 lb0
669 shared private slave unbind
671 dest(B) shared | shared shared slave+shared invalid
672 nonshared | shared private slave invalid
675 Note that a recursive bind of a subtree follows the same semantics
676 as for a bind operation on each mount in the subtree.
677 (Unbindable mounts are automatically pruned at the target mount point.)
679 For further details, see
680 .I Documentation/filesystems/sharedsubtree.txt
681 in the kernel source tree.
683 .SS Move (MS_MOVE) semantics
684 Suppose that the following command is performed:
690 is the source mount point,
692 is the destination mount point, and
694 is a subdirectory path under the mount point
696 The propagation type of the resulting mount,
698 depends on the propagation types of the mount points
702 and is summarized in the following table.
705 lb2 lb1 lb2 lb2 lb2 lb0
706 lb2 lb1 lb2 lb2 lb2 lb0
709 shared private slave unbind
711 dest(B) shared | shared shared slave+shared invalid
712 nonshared | shared private slave unbindable
715 Note: moving a mount that resides under a shared mount is invalid.
717 For further details, see
718 .I Documentation/filesystems/sharedsubtree.txt
719 in the kernel source tree.
722 Suppose that we use the following command to create a mount point:
728 is the destination mount point, and
730 is a subdirectory path under the mount point
732 The propagation type of the resulting mount,
734 follows the same rules as for a bind mount,
735 where the propagation type of the source mount
736 is considered always to be private.
738 .SS Unmount semantics
739 Suppose that we use the following command to tear down a mount point:
749 is the parent mount and
751 is a subdirectory path under the mount point
755 is shared, then all most-recently-mounted mounts at
757 on mounts that receive propagation from mount
759 and do not have submounts under them are unmounted.
761 .SS The /proc/[pid]/mountinfo "propagate_from" tag
764 tag is shown in the optional fields of a
765 .IR /proc/[pid]/mountinfo
766 record in cases where a process can't see a slave's immediate master
767 (i.e., the pathname of the master is not reachable from
768 the filesystem root directory)
769 and so cannot determine the
770 chain of propagation between the mounts it can see.
772 In the following example, we first create a two-link master-slave chain
780 command is used to make the
782 mount point unreachable from the root directory,
783 creating a situation where the master of
785 is not reachable from the (new) root directory of the process.
787 First, we bind mount the root directory onto
793 so that after the later
797 filesystem remains visible at the correct location
798 in the chroot-ed environment.
802 # \fBmkdir \-p /mnt/proc\fP
803 # \fBmount \-\-bind / /mnt\fP
804 # \fBmount \-\-bind /proc /mnt/proc\fP
808 Next, we ensure that the
810 mount is a shared mount in a new peer group (with no peers):
814 # \fBmount \-\-make\-private /mnt\fP # Isolate from any previous peer group
815 # \fBmount \-\-make\-shared /mnt\fP
816 # \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
817 239 61 8:2 / /mnt ... shared:102
818 248 239 0:4 / /mnt/proc ... shared:5
829 # \fBmkdir \-p /tmp/etc\fP
830 # \fBmount \-\-bind /mnt/etc /tmp/etc\fP
831 # \fBcat /proc/self/mountinfo | egrep \(aq/mnt|/tmp/\(aq | sed \(aqs/ \- .*//\(aq\fP
832 239 61 8:2 / /mnt ... shared:102
833 248 239 0:4 / /mnt/proc ... shared:5
834 267 40 8:2 /etc /tmp/etc ... shared:102
838 Initially, these two mount points are in the same peer group,
846 so that it can propagate events to the next slave in the chain:
850 # \fBmount \-\-make\-slave /tmp/etc\fP
851 # \fBmount \-\-make\-shared /tmp/etc\fP
852 # \fBcat /proc/self/mountinfo | egrep \(aq/mnt|/tmp/\(aq | sed \(aqs/ \- .*//\(aq\fP
853 239 61 8:2 / /mnt ... shared:102
854 248 239 0:4 / /mnt/proc ... shared:5
855 267 40 8:2 /etc /tmp/etc ... shared:105 master:102
863 Again, the two mount points are initially in the same peer group,
871 # \fBmkdir \-p /mnt/tmp/etc\fP
872 # \fBmount \-\-bind /tmp/etc /mnt/tmp/etc\fP
873 # \fBmount \-\-make\-slave /mnt/tmp/etc\fP
874 # \fBcat /proc/self/mountinfo | egrep \(aq/mnt|/tmp/\(aq | sed \(aqs/ \- .*//\(aq\fP
875 239 61 8:2 / /mnt ... shared:102
876 248 239 0:4 / /mnt/proc ... shared:5
877 267 40 8:2 /etc /tmp/etc ... shared:105 master:102
878 273 239 8:2 /etc /mnt/tmp/etc ... master:105
882 From the above, we see that
884 is the master of the slave
886 which in turn is the master of the slave
893 directory, which renders the mount with ID 267 unreachable
894 from the (new) root directory:
902 When we examine the state of the mounts inside the chroot-ed environment,
903 we see the following:
907 # \fBcat /proc/self/mountinfo | sed \(aqs/ \- .*//\(aq\fP
908 239 61 8:2 / / ... shared:102
909 248 239 0:4 / /proc ... shared:5
910 273 239 8:2 /etc /tmp/etc ... master:105 propagate_from:102
914 Above, we see that the mount with ID 273
915 is a slave whose master is the peer group 105.
916 The mount point for that master is unreachable, and so a
918 tag is displayed, indicating that the closest dominant peer group
919 (i.e., the nearest reachable mount in the slave chain)
920 is the peer group with the ID 102 (corresponding to the
922 mount point before the
927 Mount namespaces first appeared in Linux 2.4.19.
929 Namespaces are a Linux-specific feature.
932 The kernel default propagation type for mount points is
936 is typically more commonly required, and for this reason,
938 automatically remounts all mount points as
944 to create a mount namespace,
945 the goal is commonly to provide full isolation of the mount points
946 in the new namespace,
950 version 2.27) in turn reverses the step performed by
952 by making all mount points private in the new namespace.
955 performs the equivalent of the following in the new mount namespace:
957 mount \-\-make\-rprivate /
959 To prevent this, one can use the
960 .IR "\-\-propagation\ unchanged"
973 .IR Documentation/filesystems/sharedsubtree.txt
974 in the kernel source tree.