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 2018-04-30 "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).
68 .\" ============================================================
70 .SS Restrictions on mount namespaces
71 Note the following points with respect to mount namespaces:
73 A mount namespace has an owner user namespace.
74 A mount namespace whose owner user namespace is different from
75 the owner user namespace of its parent mount namespace is
76 considered a less privileged mount namespace.
78 When creating a less privileged mount namespace,
79 shared mounts are reduced to slave mounts.
80 (Shared and slave mounts are discussed below.)
81 This ensures that mappings performed in less
82 privileged mount namespaces will not propagate to more privileged
86 .\" What does "come as a single unit from more privileged mount" mean?
87 Mounts that come as a single unit from more privileged mount are
88 locked together and may not be separated in a less privileged mount
93 operation brings across all of the mounts from the original
94 mount namespace as a single unit,
95 and recursive mounts that propagate between
96 mount namespaces propagate as a single unit.)
104 and the "atime" flags
108 settings become locked
109 .\" commit 9566d6742852c527bf5af38af5cbb878dad75705
110 .\" Author: Eric W. Biederman <ebiederm@xmission.com>
111 .\" Date: Mon Jul 28 17:26:07 2014 -0700
113 .\" mnt: Correct permission checks in do_remount
115 when propagated from a more privileged to
116 a less privileged mount namespace,
117 and may not be changed in the less privileged mount namespace.
119 .\" (As of 3.18-rc1 (in Al Viro's 2014-08-30 vfs.git#for-next tree))
120 A file or directory that is a mount point in one namespace that is not
121 a mount point in another namespace, may be renamed, unlinked, or removed
123 in the mount namespace in which it is not a mount point
124 (subject to the usual permission checks).
126 Previously, attempting to unlink, rename, or remove a file or directory
127 that was a mount point in another mount namespace would result in the error
129 That behavior had technical problems of enforcement (e.g., for NFS)
130 and permitted denial-of-service attacks against more privileged users.
131 (i.e., preventing individual files from being updated
132 by bind mounting on top of them).
135 After the implementation of mount namespaces was completed,
136 experience showed that the isolation that they provided was,
137 in some cases, too great.
138 For example, in order to make a newly loaded optical disk
139 available in all mount namespaces,
140 a mount operation was required in each namespace.
141 For this use case, and others,
142 the shared subtree feature was introduced in Linux 2.6.15.
143 This feature allows for automatic, controlled propagation of mount and unmount
146 (or, more precisely, between the members of a
148 that are propagating events to one another).
150 Each mount point is marked (via
152 as having one of the following
153 .IR "propagation types" :
156 This mount point shares events with members of a peer group.
157 Mount and unmount events immediately under this mount point will propagate
158 to the other mount points that are members of the peer group.
160 here means that the same mount or unmount will automatically occur
161 under all of the other mount points in the peer group.
162 Conversely, mount and unmount events that take place under
163 peer mount points will propagate to this mount point.
166 This mount point is private; it does not have a peer group.
167 Mount and unmount events do not propagate into or out of this mount point.
170 Mount and unmount events propagate into this mount point from
171 a (master) shared peer group.
172 Mount and unmount events under this mount point do not propagate to any peer.
174 Note that a mount point can be the slave of another peer group
175 while at the same time sharing mount and unmount events
176 with a peer group of which it is a member.
177 (More precisely, one peer group can be the slave of another peer group.)
180 This is like a private mount,
181 and in addition this mount can't be bind mounted.
182 Attempts to bind mount this mount
188 When a recursive bind mount
194 flags) is performed on a directory subtree,
195 any bind mounts within the subtree are automatically pruned
196 (i.e., not replicated)
197 when replicating that subtree to produce the target subtree.
199 For a discussion of the propagation type assigned to a new mount,
202 The propagation type is a per-mount-point setting;
203 some mount points may be marked as shared
204 (with each shared mount point being a member of a distinct peer group),
205 while others are private
206 (or slaved or unbindable).
208 Note that a mount's propagation type determines whether
209 mounts and unmounts of mount points
210 .I "immediately under"
211 the mount point are propagated.
212 Thus, the propagation type does not affect propagation of events for
213 grandchildren and further removed descendant mount points.
214 What happens if the mount point itself is unmounted is determined by
215 the propagation type that is in effect for the
219 Members are added to a
221 when a mount point is marked as shared and either:
223 the mount point is replicated during the creation of a new mount namespace; or
225 a new bind mount is created from the mount point.
227 In both of these cases, the new mount point joins the peer group
228 of which the existing mount point is a member.
230 A new peer group is also created when a child mount point is created under
231 an existing mount point that is marked as shared.
232 In this case, the new child mount point is also marked as shared and
233 the resulting peer group consists of all the mount points
234 that are replicated under the peers of parent mount.
236 A mount ceases to be a member of a peer group when either
237 the mount is explicitly unmounted,
238 or when the mount is implicitly unmounted because a mount namespace is removed
239 (because it has no more member processes).
241 The propagation type of the mount points in a mount namespace
242 can be discovered via the "optional fields" exposed in
243 .IR /proc/[pid]/mountinfo .
246 for details of this file.)
247 The following tags can appear in the optional fields
248 for a record in that file:
251 This mount point is shared in peer group
253 Each peer group has a unique ID that is automatically
254 generated by the kernel,
255 and all mount points in the same peer group will show the same ID.
256 (These IDs are assigned starting from the value 1,
257 and may be recycled when a peer group ceases to have any members.)
260 This mount is a slave to shared peer group
263 .IR propagate_from:X " (since Linux 2.6.26)"
264 .\" commit 97e7e0f71d6d948c25f11f0a33878d9356d9579e
265 This mount is a slave and receives propagation from shared peer group
267 This tag will always appear in conjunction with a
272 is the closest dominant peer group under the process's root directory.
275 is the immediate master of the mount,
276 or if there is no dominant peer group under the same root,
279 field is present and not the
282 For further details, see below.
285 This is an unbindable mount.
287 If none of the above tags is present, then this is a private mount.
288 .SS MS_SHARED and MS_PRIVATE example
289 Suppose that on a terminal in the initial mount namespace,
290 we mark one mount point as shared and another as private,
291 and then view the mounts in
292 .IR /proc/self/mountinfo :
296 sh1# \fBmount \-\-make\-shared /mntS\fP
297 sh1# \fBmount \-\-make\-private /mntP\fP
298 sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
299 77 61 8:17 / /mntS rw,relatime shared:1
300 83 61 8:15 / /mntP rw,relatime
305 .IR /proc/self/mountinfo
308 is a shared mount in peer group 1, and that
310 has no optional tags, indicating that it is a private mount.
311 The first two fields in each record in this file are the unique
312 ID for this mount, and the mount ID of the parent mount.
313 We can further inspect this file to see that the parent mount point of
317 is the root directory,
319 which is mounted as private:
323 sh1# \fBcat /proc/self/mountinfo | awk \(aq$1 == 61\(aq | sed \(aqs/ \- .*//\(aq\fP
324 61 0 8:2 / / rw,relatime
328 On a second terminal,
329 we create a new mount namespace where we run a second shell
330 and inspect the mounts:
334 $ \fBPS1=\(aqsh2# \(aq sudo unshare \-m \-\-propagation unchanged sh\fP
335 sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
336 222 145 8:17 / /mntS rw,relatime shared:1
337 225 145 8:15 / /mntP rw,relatime
341 The new mount namespace received a copy of the initial mount namespace's
343 These new mount points maintain the same propagation types,
344 but have unique mount IDs.
346 .IR \-\-propagation\ unchanged
349 from marking all mounts as private when creating a new mount namespace,
350 .\" Since util-linux 2.27
351 which it does by default.)
353 In the second terminal, we then create submounts under each of
357 and inspect the set-up:
361 sh2# \fBmkdir /mntS/a\fP
362 sh2# \fBmount /dev/sdb6 /mntS/a\fP
363 sh2# \fBmkdir /mntP/b\fP
364 sh2# \fBmount /dev/sdb7 /mntP/b\fP
365 sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
366 222 145 8:17 / /mntS rw,relatime shared:1
367 225 145 8:15 / /mntP rw,relatime
368 178 222 8:22 / /mntS/a rw,relatime shared:2
369 230 225 8:23 / /mntP/b rw,relatime
373 From the above, it can be seen that
375 was created as shared (inheriting this setting from its parent mount) and
377 was created as a private mount.
379 Returning to the first terminal and inspecting the set-up,
380 we see that the new mount created under the shared mount point
382 propagated to its peer mount (in the initial mount namespace),
383 but the new mount created under the private mount point
389 sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
390 77 61 8:17 / /mntS rw,relatime shared:1
391 83 61 8:15 / /mntP rw,relatime
392 179 77 8:22 / /mntS/a rw,relatime shared:2
397 Making a mount point a slave allows it to receive propagated
398 mount and unmount events from a master shared peer group,
399 while preventing it from propagating events to that master.
400 This is useful if we want to (say) receive a mount event when
401 an optical disk is mounted in the master shared peer group
402 (in another mount namespace),
403 but want to prevent mount and unmount events under the slave mount
404 from having side effects in other namespaces.
406 We can demonstrate the effect of slaving by first marking
407 two mount points as shared in the initial mount namespace:
411 sh1# \fBmount \-\-make\-shared /mntX\fP
412 sh1# \fBmount \-\-make\-shared /mntY\fP
413 sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
414 132 83 8:23 / /mntX rw,relatime shared:1
415 133 83 8:22 / /mntY rw,relatime shared:2
419 On a second terminal,
420 we create a new mount namespace and inspect the mount points:
424 sh2# \fBunshare \-m \-\-propagation unchanged sh\fP
425 sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
426 168 167 8:23 / /mntX rw,relatime shared:1
427 169 167 8:22 / /mntY rw,relatime shared:2
431 In the new mount namespace, we then mark one of the mount points as a slave:
435 sh2# \fBmount \-\-make\-slave /mntY\fP
436 sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
437 168 167 8:23 / /mntX rw,relatime shared:1
438 169 167 8:22 / /mntY rw,relatime master:2
442 From the above output, we see that
444 is now a slave mount that is receiving propagation events from
445 the shared peer group with the ID 2.
447 Continuing in the new namespace, we create submounts under each of
454 sh2# \fBmkdir /mntX/a\fP
455 sh2# \fBmount /dev/sda3 /mntX/a\fP
456 sh2# \fBmkdir /mntY/b\fP
457 sh2# \fBmount /dev/sda5 /mntY/b\fP
461 When we inspect the state of the mount points in the new mount namespace,
464 was created as a new shared mount
465 (inheriting the "shared" setting from its parent mount) and
467 was created as a private mount:
471 sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
472 168 167 8:23 / /mntX rw,relatime shared:1
473 169 167 8:22 / /mntY rw,relatime master:2
474 173 168 8:3 / /mntX/a rw,relatime shared:3
475 175 169 8:5 / /mntY/b rw,relatime
479 Returning to the first terminal (in the initial mount namespace),
480 we see that the mount
482 propagated to the peer (the shared
490 sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
491 132 83 8:23 / /mntX rw,relatime shared:1
492 133 83 8:22 / /mntY rw,relatime shared:2
493 174 132 8:3 / /mntX/a rw,relatime shared:3
497 Now we create a new mount point under
503 sh1# \fBmkdir /mntY/c\fP
504 sh1# \fBmount /dev/sda1 /mntY/c\fP
505 sh1# \fBcat /proc/self/mountinfo | grep '/mnt' | sed 's/ \- .*//'\fP
506 132 83 8:23 / /mntX rw,relatime shared:1
507 133 83 8:22 / /mntY rw,relatime shared:2
508 174 132 8:3 / /mntX/a rw,relatime shared:3
509 178 133 8:1 / /mntY/c rw,relatime shared:4
513 When we examine the mount points in the second mount namespace,
514 we see that in this case the new mount has been propagated
515 to the slave mount point,
516 and that the new mount is itself a slave mount (to peer group 4):
520 sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
521 168 167 8:23 / /mntX rw,relatime shared:1
522 169 167 8:22 / /mntY rw,relatime master:2
523 173 168 8:3 / /mntX/a rw,relatime shared:3
524 175 169 8:5 / /mntY/b rw,relatime
525 179 169 8:1 / /mntY/c rw,relatime master:4
529 .SS MS_UNBINDABLE example
530 One of the primary purposes of unbindable mounts is to avoid
531 the "mount point explosion" problem when repeatedly performing bind mounts
532 of a higher-level subtree at a lower-level mount point.
533 The problem is illustrated by the following shell session.
535 Suppose we have a system with the following mount points:
539 # \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP
546 Suppose furthermore that we wish to recursively bind mount
547 the root directory under several users' home directories.
548 We do this for the first user, and inspect the mount points:
552 # \fBmount \-\-rbind / /home/cecilia/\fP
553 # \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP
557 /dev/sda1 on /home/cecilia
558 /dev/sdb6 on /home/cecilia/mntX
559 /dev/sdb7 on /home/cecilia/mntY
563 When we repeat this operation for the second user,
564 we start to see the explosion problem:
568 # \fBmount \-\-rbind / /home/henry\fP
569 # \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP
573 /dev/sda1 on /home/cecilia
574 /dev/sdb6 on /home/cecilia/mntX
575 /dev/sdb7 on /home/cecilia/mntY
576 /dev/sda1 on /home/henry
577 /dev/sdb6 on /home/henry/mntX
578 /dev/sdb7 on /home/henry/mntY
579 /dev/sda1 on /home/henry/home/cecilia
580 /dev/sdb6 on /home/henry/home/cecilia/mntX
581 /dev/sdb7 on /home/henry/home/cecilia/mntY
587 we have not only recursively added the
591 mounts, but also the recursive mounts of those directories under
593 that were created in the previous step.
594 Upon repeating the step for a third user,
595 it becomes obvious that the explosion is exponential in nature:
599 # \fBmount \-\-rbind / /home/otto\fP
600 # \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP
604 /dev/sda1 on /home/cecilia
605 /dev/sdb6 on /home/cecilia/mntX
606 /dev/sdb7 on /home/cecilia/mntY
607 /dev/sda1 on /home/henry
608 /dev/sdb6 on /home/henry/mntX
609 /dev/sdb7 on /home/henry/mntY
610 /dev/sda1 on /home/henry/home/cecilia
611 /dev/sdb6 on /home/henry/home/cecilia/mntX
612 /dev/sdb7 on /home/henry/home/cecilia/mntY
613 /dev/sda1 on /home/otto
614 /dev/sdb6 on /home/otto/mntX
615 /dev/sdb7 on /home/otto/mntY
616 /dev/sda1 on /home/otto/home/cecilia
617 /dev/sdb6 on /home/otto/home/cecilia/mntX
618 /dev/sdb7 on /home/otto/home/cecilia/mntY
619 /dev/sda1 on /home/otto/home/henry
620 /dev/sdb6 on /home/otto/home/henry/mntX
621 /dev/sdb7 on /home/otto/home/henry/mntY
622 /dev/sda1 on /home/otto/home/henry/home/cecilia
623 /dev/sdb6 on /home/otto/home/henry/home/cecilia/mntX
624 /dev/sdb7 on /home/otto/home/henry/home/cecilia/mntY
628 The mount explosion problem in the above scenario can be avoided
629 by making each of the new mounts unbindable.
630 The effect of doing this is that recursive mounts of the root
631 directory will not replicate the unbindable mounts.
632 We make such a mount for the first user:
636 # \fBmount \-\-rbind \-\-make\-unbindable / /home/cecilia\fP
640 Before going further, we show that unbindable mounts are indeed unbindable:
645 # \fBmount \-\-bind /home/cecilia /mntZ\fP
646 mount: wrong fs type, bad option, bad superblock on /home/cecilia,
647 missing codepage or helper program, or other error
649 In some cases useful info is found in syslog \- try
654 Now we create unbindable recursive bind mounts for the other two users:
658 # \fBmount \-\-rbind \-\-make\-unbindable / /home/henry\fP
659 # \fBmount \-\-rbind \-\-make\-unbindable / /home/otto\fP
663 Upon examining the list of mount points,
664 we see there has been no explosion of mount points,
665 because the unbindable mounts were not replicated
666 under each user's directory:
670 # \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP
674 /dev/sda1 on /home/cecilia
675 /dev/sdb6 on /home/cecilia/mntX
676 /dev/sdb7 on /home/cecilia/mntY
677 /dev/sda1 on /home/henry
678 /dev/sdb6 on /home/henry/mntX
679 /dev/sdb7 on /home/henry/mntY
680 /dev/sda1 on /home/otto
681 /dev/sdb6 on /home/otto/mntX
682 /dev/sdb7 on /home/otto/mntY
686 .SS Propagation type transitions
687 The following table shows the effect that applying a new propagation type
689 .IR "mount \-\-make\-xxxx")
690 has on the existing propagation type of a mount point.
691 The rows correspond to existing propagation types,
692 and the columns are the new propagation settings.
693 For reasons of space, "private" is abbreviated as "priv" and
694 "unbindable" as "unbind".
698 make-shared make-slave make-priv make-unbind
699 shared shared slave/priv [1] priv unbind
700 slave slave+shared slave [2] priv unbind
701 slave+shared slave+shared slave priv unbind
702 private shared priv [2] priv unbind
703 unbindable shared unbind [2] priv unbind
706 Note the following details to the table:
708 If a shared mount is the only mount in its peer group,
709 making it a slave automatically makes it private.
711 Slaving a nonshared mount has no effect on the mount.
713 .SS Bind (MS_BIND) semantics
714 Suppose that the following command is performed:
716 mount \-\-bind A/a B/b
720 is the source mount point,
722 is the destination mount point,
724 is a subdirectory path under the mount point
728 is a subdirectory path under the mount point
730 The propagation type of the resulting mount,
732 depends on the propagation types of the mount points
736 and is summarized in the following table.
739 lb2 lb1 lb2 lb2 lb2 lb0
740 lb2 lb1 lb2 lb2 lb2 lb0
743 shared private slave unbind
745 dest(B) shared | shared shared slave+shared invalid
746 nonshared | shared private slave invalid
749 Note that a recursive bind of a subtree follows the same semantics
750 as for a bind operation on each mount in the subtree.
751 (Unbindable mounts are automatically pruned at the target mount point.)
753 For further details, see
754 .I Documentation/filesystems/sharedsubtree.txt
755 in the kernel source tree.
757 .SS Move (MS_MOVE) semantics
758 Suppose that the following command is performed:
764 is the source mount point,
766 is the destination mount point, and
768 is a subdirectory path under the mount point
770 The propagation type of the resulting mount,
772 depends on the propagation types of the mount points
776 and is summarized in the following table.
779 lb2 lb1 lb2 lb2 lb2 lb0
780 lb2 lb1 lb2 lb2 lb2 lb0
783 shared private slave unbind
785 dest(B) shared | shared shared slave+shared invalid
786 nonshared | shared private slave unbindable
789 Note: moving a mount that resides under a shared mount is invalid.
791 For further details, see
792 .I Documentation/filesystems/sharedsubtree.txt
793 in the kernel source tree.
796 Suppose that we use the following command to create a mount point:
802 is the destination mount point, and
804 is a subdirectory path under the mount point
806 The propagation type of the resulting mount,
808 follows the same rules as for a bind mount,
809 where the propagation type of the source mount
810 is considered always to be private.
812 .SS Unmount semantics
813 Suppose that we use the following command to tear down a mount point:
823 is the parent mount and
825 is a subdirectory path under the mount point
829 is shared, then all most-recently-mounted mounts at
831 on mounts that receive propagation from mount
833 and do not have submounts under them are unmounted.
835 .SS The /proc/[pid]/mountinfo "propagate_from" tag
838 tag is shown in the optional fields of a
839 .IR /proc/[pid]/mountinfo
840 record in cases where a process can't see a slave's immediate master
841 (i.e., the pathname of the master is not reachable from
842 the filesystem root directory)
843 and so cannot determine the
844 chain of propagation between the mounts it can see.
846 In the following example, we first create a two-link master-slave chain
854 command is used to make the
856 mount point unreachable from the root directory,
857 creating a situation where the master of
859 is not reachable from the (new) root directory of the process.
861 First, we bind mount the root directory onto
867 so that after the later
871 filesystem remains visible at the correct location
872 in the chroot-ed environment.
876 # \fBmkdir \-p /mnt/proc\fP
877 # \fBmount \-\-bind / /mnt\fP
878 # \fBmount \-\-bind /proc /mnt/proc\fP
882 Next, we ensure that the
884 mount is a shared mount in a new peer group (with no peers):
888 # \fBmount \-\-make\-private /mnt\fP # Isolate from any previous peer group
889 # \fBmount \-\-make\-shared /mnt\fP
890 # \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
891 239 61 8:2 / /mnt ... shared:102
892 248 239 0:4 / /mnt/proc ... shared:5
903 # \fBmkdir \-p /tmp/etc\fP
904 # \fBmount \-\-bind /mnt/etc /tmp/etc\fP
905 # \fBcat /proc/self/mountinfo | egrep \(aq/mnt|/tmp/\(aq | sed \(aqs/ \- .*//\(aq\fP
906 239 61 8:2 / /mnt ... shared:102
907 248 239 0:4 / /mnt/proc ... shared:5
908 267 40 8:2 /etc /tmp/etc ... shared:102
912 Initially, these two mount points are in the same peer group,
920 so that it can propagate events to the next slave in the chain:
924 # \fBmount \-\-make\-slave /tmp/etc\fP
925 # \fBmount \-\-make\-shared /tmp/etc\fP
926 # \fBcat /proc/self/mountinfo | egrep \(aq/mnt|/tmp/\(aq | sed \(aqs/ \- .*//\(aq\fP
927 239 61 8:2 / /mnt ... shared:102
928 248 239 0:4 / /mnt/proc ... shared:5
929 267 40 8:2 /etc /tmp/etc ... shared:105 master:102
937 Again, the two mount points are initially in the same peer group,
945 # \fBmkdir \-p /mnt/tmp/etc\fP
946 # \fBmount \-\-bind /tmp/etc /mnt/tmp/etc\fP
947 # \fBmount \-\-make\-slave /mnt/tmp/etc\fP
948 # \fBcat /proc/self/mountinfo | egrep \(aq/mnt|/tmp/\(aq | sed \(aqs/ \- .*//\(aq\fP
949 239 61 8:2 / /mnt ... shared:102
950 248 239 0:4 / /mnt/proc ... shared:5
951 267 40 8:2 /etc /tmp/etc ... shared:105 master:102
952 273 239 8:2 /etc /mnt/tmp/etc ... master:105
956 From the above, we see that
958 is the master of the slave
960 which in turn is the master of the slave
967 directory, which renders the mount with ID 267 unreachable
968 from the (new) root directory:
976 When we examine the state of the mounts inside the chroot-ed environment,
977 we see the following:
981 # \fBcat /proc/self/mountinfo | sed \(aqs/ \- .*//\(aq\fP
982 239 61 8:2 / / ... shared:102
983 248 239 0:4 / /proc ... shared:5
984 273 239 8:2 /etc /tmp/etc ... master:105 propagate_from:102
988 Above, we see that the mount with ID 273
989 is a slave whose master is the peer group 105.
990 The mount point for that master is unreachable, and so a
992 tag is displayed, indicating that the closest dominant peer group
993 (i.e., the nearest reachable mount in the slave chain)
994 is the peer group with the ID 102 (corresponding to the
996 mount point before the
1001 Mount namespaces first appeared in Linux 2.4.19.
1003 Namespaces are a Linux-specific feature.
1006 The propagation type assigned to a new mount point depends
1007 on the propagation type of the parent mount.
1008 If the mount point has a parent (i.e., it is a non-root mount
1009 point) and the propagation type of the parent is
1011 then the propagation type of the new mount is also
1013 Otherwise, the propagation type of the new mount is
1016 Notwithstanding the fact that the default propagation type
1017 for new mount points is in many cases
1020 is typically more useful.
1023 automatically remounts all mount points as
1026 Thus, on most modern systems, the default propagation type is in practice
1029 Since, when one uses
1031 to create a mount namespace,
1032 the goal is commonly to provide full isolation of the mount points
1033 in the new namespace,
1037 version 2.27) in turn reverses the step performed by
1039 by making all mount points private in the new namespace.
1042 performs the equivalent of the following in the new mount namespace:
1044 mount \-\-make\-rprivate /
1046 To prevent this, one can use the
1047 .IR "\-\-propagation\ unchanged"
1051 For a discussion of propagation types when moving mounts
1053 and creating bind mounts
1056 .IR Documentation/filesystems/sharedsubtree.txt .
1067 .BR user_namespaces (7),
1071 .IR Documentation/filesystems/sharedsubtree.txt
1072 in the kernel source tree.
projects / thirdparty / man-pages.git / blob