Linux程序员手册 第7部分
更新日期： 2020-06-09

名称

mount_namespaces-Linux安装名称空间概述

说明

有关名称空间的概述，请参见namespaces(7)。

挂接名称空间可隔离每个名称空间实例中的进程看到的挂接点列表。因此，每个安装名称空间实例中的进程将看到不同的单目录层次结构。

/ proc / [pid] / mounts，/ proc / [pid] / mountinfo和/ proc / [pid] / mountstats文件(均在proc(5)中进行了描述)提供的视图对应于其中的挂载名称空间。 PID [pid]驻留的进程。 (驻留在同一装载名称空间中的所有进程在这些文件中将看到相同的视图。)

使用带有CLONE_NEWNS标志的clone(2)或unshare(2)创建一个新的装载名称空间。创建新的安装名称空间后，其安装点列表将初始化如下：

*

如果名称空间是使用clone(2)创建的，则子名称空间的安装点列表是父名称空间中安装点列表的副本。

*

如果使用unshare(2)创建名称空间，则新名称空间的安装点列表是调用者先前的安装名称空间中的安装点列表的副本。

对两个装入名称空间中的装入点列表(mount(2)和umount(2))的后续修改不会(默认情况下)不会影响在另一个名称空间中看到的装入点列表(但请参见下面有关共享子树的讨论)。

Restrictions on mount namespaces

关于安装名称空间，请注意以下几点：

*

每个安装名称空间都有一个所有者用户名称空间。如上所述，创建新的安装命名空间时，其安装点列表将初始化为另一个安装命名空间的安装点列表的副本。如果新名称空间和从中复制安装点列表的名称空间由不同的用户名称空间拥有，则认为新的安装名称空间的特权较低。

*

创建特权较低的安装名称空间时，共享安装将减少为从属安装。 (下面将讨论共享和从属装载。)这确保了在特权较少的装载名称空间中执行的映射不会传播到特权更大的装载名称空间。

*

来自更高特权的安装命名空间中作为单个单元的安装被锁定在一起，并且可能不会在较低特权的安装命名空间中分开。 (unshare(2)CLONE_NEWNS操作将原始安装名称空间中的所有安装作为一个单元，而在安装名称空间之间传播的递归安装作为一个单元传播。)

*

当从特权较高的装载命名空间传播到特权较低的装载命名空间时，mount(2)标志MS_RDONLY，MS_NOSUID，MS_NOEXEC和" atime"标志(MS_NOATIME，MS_NODIRATIME，MS_RELATIME)设置被锁定，并且在特权较低的装载命名空间中可能无法更改挂载名称空间。

*

作为一个命名空间中的安装点而不是另一个命名空间中的安装点的文件或目录，可以在不是安装点(主题)的安装命名空间中重命名，取消链接或删除(rmdir(2))。进行通常的权限检查)。因此，该安装点将在原来是安装点的安装名称空间中删除。

以前(在Linux 3.18之前)，尝试取消链接，重命名或删除作为另一个装入名称空间中的装入点的文件或目录将导致错误EBUSY。这种行为存在执行方面的技术问题(例如，对于NFS)，并且允许针对特权更高的用户的服务拒绝攻击。 (即，通过在其顶部进行绑定安装来防止更新单个文件)。

SHARED SUBTREES

装载名称空间的实现完成后，经验表明，在某些情况下，它们提供的隔离度过高。例如，为了使新装入的光盘在所有安装名称空间中可用，在每个名称空间中都需要安装操作。对于此用例及其他用例，Linux 2.6.15中引入了共享子树功能。此功能允许在名称空间之间(或更确切地说，在将事件相互传播的对等组成员之间)自动，受控地传播安装和卸载事件。

每个安装点(通过mount(2))被标记为具有以下传播类型之一：

MS_SHARED

该安装点与对等组的成员共享事件。紧接在此安装点下的安装和卸载事件将传播到对等组成员的其他安装点。此处的传播意味着对等组中的所有其他安装点下将自动发生相同的安装或卸载。相反，在对等安装点下发生的安装和卸载事件将传播到该安装点。

MS_PRIVATE

该安装点是私有的；它没有对等组。安装和卸载事件不会传播到该安装点或从该安装点传播出去。

MS_SLAVE

安装和卸载事件从(主)共享对等组传播到此安装点。此安装点下的安装和卸载事件不会传播到任何对等方。

请注意，安装点可以是另一个对等组的从属，同时可以与它所属的对等组共享安装和卸载事件。 (更确切地说，一个对等组可以是另一对等组的从属。)

MS_UNBINDABLE

这就像一个私有安装，并且此安装不能绑定安装。尝试绑定此安装(带有MS_BIND标志的mount(2))将失败。

在目录子树上执行递归绑定安装(带有MS_BIND和MS_REC标志的mount(2))时，在复制该子树以生成目标子树时，会自动修剪(即不复制)子树内的任何绑定安装。

有关分配给新安装架的传播类型的讨论，请参见"注意"。

传播类型是每个安装点的设置。某些挂载点可能被标记为共享(每个共享的挂载点是不同的对等组的成员)，而其他挂载点是私有的(或从属或不可绑定)。

请注意，安装的传播类型确定是否传播紧接在安装点下方的安装点的安装和卸载。因此，传播类型不影响孙子事件的传播以及进一步移除的后代安装点。如果卸载安装点本身会发生什么，则取决于对安装点的父节点有效的传播类型。

将安装点标记为共享时，成员将添加到对等组，并且：

*

在创建新的安装名称空间期间复制安装点；要么

*

从安装点创建一个新的绑定安装。

在这两种情况下，新的安装点都将加入现有安装点所属的对等组。

在标记为共享的现有安装点下创建子安装点时，也会创建一个新的对等组。在这种情况下，新的子安装点也被标记为共享，并且结果对等组由在父安装的对等下复制的所有安装点组成。

如果明确卸载了该装载，或者由于删除了一个装载名称空间(因为它没有成员进程)而隐式卸载了该装载，则该装载不再是对等组的成员。

可以通过/ proc / [pid] / mountinfo中公开的"可选字段"来发现安装名称空间中安装点的传播类型。 (有关此文件的详细信息，请参见proc(5)。)以下标记可以出现在该文件中记录的可选字段中：

shared:X

此安装点在对等组X中共享。每个对等组都有一个由内核自动生成的唯一ID，并且同一对等组中的所有安装点将显示相同的ID。 (这些ID从值1开始分配，当对等组不再具有任何成员时，可以回收这些ID。)

master:X

该安装是共享对等组X的从属。

propagate_from:X(since Linux 2.6.26)

该挂载是从站，从共享对等组X接收传播。此标记将始终与master：X标记一起出现。在此，X是进程根目录下最接近的显性对等组。如果X是安装的直接主服务器，或者在同一根目录下没有主要的对等组，则仅存在master：X字段，而不存在property_from：X字段。有关更多详细信息，请参见下文。

unbindable

这是不可绑定的安装。

如果以上标签都不存在，则这是私有安装。

MS_SHARED and MS_PRIVATE example

假设在初始安装名称空间的终端上，我们将一个安装点标记为共享，将另一个标记为私有，然后在/ proc / self / mountinfo中查看安装：

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

从/ proc / self / mountinfo输出中，我们看到/ mntS是对等组1中的共享装载，/ mntP没有可选标记，表明它是私有装载。该文件中每个记录的前两个字段是此装载的唯一ID，以及父装载的装载ID。我们可以进一步检查该文件中看到父挂载的/的MNT点和/ MNTP是根目录，/，安装为私有：

sh1# cat /proc/self/mountinfo | awk aq == 61aq | sed aqs/ - .*//aq
61 0 8:2 / / rw,relatime

在第二个终端上，我们创建一个新的安装命名空间，在其中运行第二个Shell并检查安装：

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

新的安装名称空间收到了初始安装名称空间的安装点的副本。这些新的挂载点保持相同的传播类型，但具有唯一的ID安装。 (--propagationunchanged选项可防止unshare(1)在创建新的安装名称空间时将所有安装标记为私有，默认情况下会执行此操作。)

在第二个终端中，我们然后在/ mntS和/ mntP的每一个下创建子安装并检查设置：

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 aq/mntaq | sed aqs/ - .*//aq
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

从上面可以看出，/ mntS / a是作为共享创建的(从其父挂载继承此设置)，/ mntP / b是作为私有挂载创建的。

返回第一个终端并检查设置，我们看到在共享安装点/ mntS下创建的新安装传播到其对等安装(在初始安装名称空间中)，但是在专用安装点/下创建的新安装mntP没有传播：

sh1# cat /proc/self/mountinfo | grep aq/mntaq | sed aqs/ - .*//aq
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

将装载点设为从站可以使其从主共享对等组接收传播的安装和卸载事件，同时防止其将事件传播到该主站。如果我们希望(例如)在主共享对等组中(在另一个安装名称空间中)安装光盘时接收到安装事件，但又希望防止从属安装下的安装和卸载事件在以下方面产生副作用，则这很有用：其他名称空间。

我们可以通过首先在初始安装名称空间中将两个安装点标记为共享来证明从属的效果：

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

在第二个终端上，我们创建一个新的安装命名空间并检查安装点：

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

然后，在新的安装名称空间中，我们将安装点之一标记为从属：

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

从上面的输出中，我们看到/ mntY现在是一个从属安装正在接收传播事件从共享对等体组具有ID 2。

继续新的名称空间，我们在/ mntX和/ mntY的每个目录下创建子装载：

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

当我们在新安装的命名空间检查挂接点的状态，我们可以看到/ MNTX / A创建为一个新的共享安装(继承其父安装"共享"设置)和/ mntY / B是作为创建私人坐骑：

sh2# cat /proc/self/mountinfo | grep aq/mntaq | sed aqs/ - .*//aq
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

返回第一个终端(在初始安装名称空间中)，我们看到安装/ mntX / a传播到了对等方(共享的/ mntX)，但是未传播安装/ mntY / b：

sh1# cat /proc/self/mountinfo | grep aq/mntaq | sed aqs/ - .*//aq
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

现在我们创建的第一个shell下/ mntY一个新的安装点：

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

当我们检查第二个安装命名空间中的安装点时，我们看到在这种情况下，新的安装已传播到从属安装点，并且新的安装本身就是从属安装(到对等组4)：

sh2# cat /proc/self/mountinfo | grep aq/mntaq | sed aqs/ - .*//aq
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

不可绑定挂载的主要目的之一是避免在较低级别的挂载点重复执行较高级别子树的绑定挂载时发生"挂载点爆炸"问题。以下shell会话说明了该问题。

假设我们有一个带有以下安装点的系统：

# mount | awk aq{print , , }aq
/dev/sda1 on /
/dev/sdb6 on /mntX
/dev/sdb7 on /mntY

此外，假设我们希望以递归方式将根目录安装到几个用户的主目录下。我们为第一个用户执行此操作，并检查安装点：

# mount --rbind / /home/cecilia/
# mount | awk aq{print , , }aq
/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

当我们为第二个用户重复此操作时，我们开始看到爆炸问题：

# mount --rbind / /home/henry
# mount | awk aq{print , , }aq
/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

在/ home / henry下，我们不仅以递归方式添加了/ mntX和/ mntY挂载，还以递归方式添加了上一步中在/ home / cecilia下创建的那些目录。在重复对第三用户的步骤中，可以很明显的是，爆炸在本质上是指数：

# mount --rbind / /home/otto
# mount | awk aq{print , , }aq
/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

通过使每个新安装架不可绑定，可以避免上述情况下的安装架爆炸问题。这样做的效果是，根目录的递归挂载将不会复制不可绑定的挂载。我们为第一个用户安装了这样的支架：

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

在进一步介绍之前，我们证明了不可绑定的安装确实是不可绑定的：

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

现在，我们为其他两个用户创建不可绑定的递归绑定安装：

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

在检查挂载点的列表中，我们可以看到，一直没有安装点的爆炸，因为unbindable坐骑并没有每个用户的目录下复制：

# mount | awk aq{print , , }aq
/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

下表显示了应用新的传播类型(即mount --make-xxxx)对安装点的现有传播类型的影响。这些行对应于现有的传播类型，而列则是新的传播设置。出于篇幅考虑，" private"缩写为" priv"，" unbindable"缩写为" unbind"。

单元格不一致

在表中注意以下详细信息：

[1]

如果共享安装是唯一的在其对等体组安装，使得它的从自动使得私人。

[2]

从站非共享挂载对挂载没有影响。

Bind (MS_BIND) semantics

假设执行以下命令：

mount --bind A/a B/b

此处，A是源安装点，B是目标安装点，a是安装点A下的子目录路径，b是安装点B下的子目录路径。生成的安装的传播类型B / b取决于挂载点A和B的传播类型，并在下表中进行了概述。

单元格不一致

请注意，子树的递归绑定遵循与子树中每个装载上的绑定操作相同的语义。 (Unbindable安装件在目标自动修剪挂载点。)

有关更多详细信息，请参阅内核源代码树中的Documentation / filesystems / sharedsubtree.txt。

Move (MS_MOVE) semantics

假设执行以下命令：

mount --move A B/b

此处，A是源安装点，B是目标安装点，b是安装点B下的子目录路径。生成的安装的传播类型B / b取决于安装点A的传播类型和B，汇总在下表中。

单元格不一致

注意：移动驻留在共享安装下的安装是无效的。

有关详细信息，请参阅内核源代码树中的Documentation /文件系统/ sharedsubtree.txt。

Mount semantics

假设我们使用以下命令创建安装点：

mount device B/b

在这里，B是目标安装点，b是安装点B下的子目录路径。结果安装的传播类型B / b遵循与绑定安装相同的规则，其中源的传播类型安装始终被认为是私有的。

Unmount semantics

假设我们使用以下命令拆除安装点：

unmount A

此处，A是B / b上的安装点，其中B是父安装，b是安装点B下的子目录路径。如果B是共享的，则所有最近传播的安装在b上的接收传播的安装从底座B卸下，并且没有下面的底座被卸下。

The /proc/[pid]/mountinfo propagate_from tag

如果进程无法看到从属的直接主控方(即，从文件系统根目录无法访问主控方的路径名)，则/ proc / [pid] / mountinfo记录的可选字段中将显示property_from：X标记。目录)，因此无法确定它可以看到的安装之间的传播链。

在以下示例中，我们首先在挂载/ mnt，/ tmp / etc和/ mnt / tmp / etc之间创建一个双链接主从链。然后在chroot(1)命令是用来制造在/ tmp /等挂载点从根目录不可达，产生的情况下的到/ mnt / TMP /等的主站未从处理的(新的)的根目录可到达。

首先，我们将根目录绑定安装到/ mnt上，然后将安装/ proc绑定到/ mnt / proc上，以便在以后的chroot(1)之后，proc(5)文件系统在chroot环境中的正确位置仍然可见。

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

接下来，我们确保/ mnt挂载是新对等组(无对等)中的共享挂载：

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

接下来，我们绑定挂载到/ mnt /等等到/ tmp目录的/ etc：

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

最初，这两个安装点在同一个对等组中，但是我们随后将/ tmp / etc设为/ mnt / etc的从属，然后使/ tmp / etc也共享，以便将事件传播到下一个链中的奴隶：

# mount --make-slave /tmp/etc
# mount --make-shared /tmp/etc
# cat /proc/self/mountinfo | egrep aq/mnt|/tmp/aq | sed aqs/ - .*//aq
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

然后，将/ tmp / etc绑定到/ mnt / tmp / etc。同样，这两个安装点最初位于同一对等组中，但随后我们将/ mnt / tmp / etc设为/ 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 aq/mnt|/tmp/aq | sed aqs/ - .*//aq
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

从上面的内容中，我们看到/ mnt是从属服务器/ tmp / etc的主服务器，而后者又是从属服务器/ mnt / tmp / etc的主计算机。

然后，我们将chroot(1)转到/ mnt目录，这将使ID 267的安装无法从(新)根目录访问：

# chroot /mnt

当我们检查chroot环境中的安装状态时，会看到以下内容：

# cat /proc/self/mountinfo | sed aqs/ - .*//aq
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

以上，我们看到，安装，带ID 273是一个从站，其主站的对等体组105的安装点master是可达，从而显示一个propagate_from标签，指示最接近主对等体组(即，最近的从链中可到达的挂载)是ID为102的对等组(对应于执行chroot(1)之前的/ mnt挂载点)。

版本

挂载名称空间最早出现在Linux 2.4.19中。

遵循规范

命名空间是特定于Linux的功能。

备注

分配给一个新的安装点的传播类型取决于母体安装的传播类型。如果安装点具有父级(即它是非根安装点)，并且父级的传播类型为MS_SHARED，则新安装的传播类型也为MS_SHARED。否则，新安装的传播类型为MS_PRIVATE。

尽管新安装点的默认传播类型在许多情况下是MS_PRIVATE，但MS_SHARED通常更有用。因此，systemd(1)在系统启动时自动将所有安装点重新安装为MS_SHARED。因此，在大多数现代系统上，默认传播类型实际上是MS_SHARED。

因为，当使用unshare(1)创建安装名称空间时，通常的目标是在新名称空间中提供安装点的完全隔离，因此unshare(1)(自util-linux版本2.27起)反过来会逆转执行的步骤。由systemd(1)，通过使所有安装在新的命名空间的私人点。也就是说，unshare(1)在新的安装名称空间中执行以下操作：

mount --make-rprivate /

为了避免这种情况，可以使用--propagation不变选项来取消共享(1)。

直接使用clone(2)或unshare(2)创建新的挂载名称空间的应用程序可能希望阻止将挂载事件传播到其他挂载名称空间(由unshare(1)完成)。这可以通过将新名称空间中的安装点的传播类型更改为MS_SLAVE或MS_PRIVATE来完成。使用如下呼叫：

mount(NULL, "/", MS_SLAVE | MS_REC, NULL);

对于传播类型的讨论移动支架(MS_MOVE)时并创建绑定安装(MS_BIND)，见文档/文件系统/ sharedsubtree.txt。

示例

请参见pivot_root(2)。

另外参见

unshare(1)，clone(2)，mount(2)，pivot_root(2)，setns(2)，umount(2)，unshare(2)，proc(5)，名称空间(7)，user_namespaces(7)， findmnt(8)，mount(8)，pivot_root(8)，umount(8)

内核源代码树中的Documentation / filesystems / sharedsubtree.txt。

出版信息

这个页面是Linux手册页项目5.08版的一部分。有关项目的说明、有关报告错误的信息以及此页面的最新版本，请访问https://www.kernel.org/doc/man-pages/。