mount --rbind 怎样复制嵌套挂载关系

先给结论：mount --rbind olddir newdir 会把 olddir 的目录树连同树内已有的子挂载一起映射到 newdir。普通 mount --bind 只绑定单个文件系统的一部分，不会自动复制源目录下的子挂载。

这正是“目录看起来复制成功，但里面的挂载点是空的”这类问题的常见原因。递归绑定解决的是复制范围；它不会自动替你决定挂载事件是否跨位置传播，也不会替你完成卸载。下面按“选择命令—控制传播—观察结果—回收目标树”的顺序说明。

官方地址：https://man7.org/linux/man-pages/man8/mount.8.html

先区分 --bind 与 --rbind 的复制范围

--bind 的语义是把源目录的一部分文件层次挂到另一个位置，源目录和目标目录都能访问同一份内容。它只处理当前绑定点对应的文件系统层次；如果源目录下面还有独立挂载的目录，普通绑定不会把这些子挂载一并带过去。

--rbind 可以理解为 bind 加上 recursive：除了顶层目录，还递归复制源树内部的挂载关系。这里的“复制”不是复制文件，也不是创建新的磁盘分区，而是为目标位置建立一棵新的挂载视图。

因此，判断标准不是“目录有多深”，而是“源目录内部是否存在独立挂载”。普通子目录只是同一个文件系统里的路径，递归绑定真正关心的是额外的 mount 节点。

准备源目录与目标挂载点

先确定两个绝对路径：源目录必须是你想暴露的挂载树根，目标目录必须是另一个不会与源树重叠的挂载点。目标放在源目录内部，或者让源目录和目标目录形成回环，会让排障和卸载都变得危险。

# 创建目标挂载点；示例只说明命令结构，不代表已在本机执行
sudo mkdir -p /srv/mirror

# 先查看源树的挂载关系，避免把普通目录误当成子挂载
findmnt -R -o TARGET,SOURCE,FSTYPE,OPTIONS,PROPAGATION /srv/data

findmnt 的输出应重点看 TARGET 是否出现源目录下的独立路径，以及 PROPAGATION 是否带有 shared、master 等标记。若源树没有子挂载，--rbind 与 --bind 的结果在内容上可能看不出差别，但它们的意图仍然不同。

执行递归绑定并控制传播方向

最小的递归绑定命令只有一行：

# 把源目录树及其中的子挂载一起映射到目标目录
sudo mount --rbind /srv/data /srv/mirror

挂载完成后，目标树拥有自己的挂载节点，但这不等于所有后续 mount/umount 事件都只发生在目标侧。Linux 的 shared subtree 机制会影响事件是否在相关挂载之间传播，所以“复制挂载树”和“决定传播策略”应当分成两个动作。

在希望目标侧接收上游事件、但不把目标内部的新挂载反向传播回去的场景，可以把目标树设为递归 slave：

# 让目标树递归接收上游传播，但避免目标侧事件回传到源侧
sudo mount --make-rslave /srv/mirror

如果目标需要完全隔离传播，则可以选择递归 private：

# 让目标树递归成为 private，目标与其它挂载树互不传播事件
sudo mount --make-rprivate /srv/mirror

rslave 与 rprivate 不是谁更“正确”，而是传播策略不同：前者保留从 master 到 slave 的接收方向，后者两边都不传播。容器或隔离视图里常见 rbind 后接 rslave，但最终应按应用是否需要接收上游挂载事件来选择。

用 findmnt 和 mountinfo 观察嵌套关系

不要只用“目标目录能列出文件”判断递归绑定成功，因为普通目录内容和独立挂载的可见性不是一回事。应当按目标路径递归查看挂载表：

# 递归列出目标及其下方的挂载节点，观察来源和传播属性
findmnt -R -o TARGET,SOURCE,FSTYPE,OPTIONS,PROPAGATION /srv/mirror

如果源侧存在 /srv/data/cache 这样的子挂载，目标侧通常应能看到对应的 /srv/mirror/cache 记录。SOURCE、文件系统类型和挂载选项用于确认它不是普通目录；PROPAGATION 则用于判断后续事件传播方式。

需要查看内核提供的详细挂载关系时，可读取当前 mount namespace 的 mountinfo：

# 过滤目标树的挂载记录；复杂路径或脚本场景应改用专门解析器
awk '$5 == "/srv/mirror" || index($5, "/srv/mirror/") == 1 {print}' /proc/self/mountinfo

/proc/self/mountinfo 的可见内容属于当前进程所在的 mount namespace。若你在容器内查看，看到的挂载树可能与宿主机不同；这不是 --rbind 丢失关系，而是观察者所在的命名空间不同。

递归卸载目标树并处理 busy 边界

递归绑定建立的是多个挂载节点，清理时也要按挂载点树处理。umount --recursive 会根据内核的挂载关系递归卸载指定目录下的挂载；参数应使用目标挂载点路径，而不是设备名。

# 按目标挂载点递归卸载目标树；必须确认路径确实是本次建立的入口
sudo umount --recursive /srv/mirror

如果返回 busy，先检查进程的当前工作目录、打开文件和子挂载使用情况，再决定是否停止相关服务。不要把 umount --lazy 当成默认修复手段：懒卸载会先从文件层次脱离，剩余引用稍后清理，网络文件系统或本地子挂载场景还可能引入新的不确定性。

清理后可以再次用 findmnt -R /srv/mirror 检查目标入口是否仍有挂载记录。若目标目录本身只是普通目录，它可能仍然存在；卸载的是挂载关系，不是自动删除目录。

按场景选择 rbind 的适用范围

• 需要完整复制挂载树：例如为隔离环境准备一个目录视图，源树内部的独立挂载也必须可见，此时选 --rbind。
• 只需要一个目录入口：源目录没有子挂载，或者你明确不希望带入子挂载，普通 --bind 更容易表达意图。
• 需要接收上游但禁止回传：递归绑定后考虑 --make-rslave，并在文档中写清传播方向。
• 需要完全隔离：使用 --make-rprivate，但同时确认业务不依赖其它命名空间或源树的后续挂载事件。
• 需要稳定回滚：保存目标挂载点，使用 umount --recursive 清理，并避免把目标嵌套在源目录内。

常见问题

为什么 --bind 后子目录还在，但里面的挂载内容不见了？

因为普通 bind 映射的是当前文件系统层次，源目录下独立的子挂载不会自动复制。需要完整挂载树时改用 --rbind，再用 findmnt -R 检查目标侧是否出现对应挂载节点。

--rbind 会复制文件吗？

不会。它建立的是新的挂载视图，底层文件内容仍由原文件系统提供；删除、写入和权限效果仍取决于原文件系统、挂载选项和访问者所在的命名空间。

为什么 rbind 后还要设置 rslave 或 rprivate？

因为递归复制只解决“哪些挂载节点出现在目标”，传播属性解决“后续挂载和卸载事件是否互相影响”。两者是不同层面，是否设置以及选哪一种取决于隔离和接收事件的要求。

递归卸载一定要使用目标目录吗？

是。umount --recursive 按目录路径确定要递归处理的挂载树，设备名不能替代目标挂载点来表达这棵嵌套关系。

总结：--rbind 适合复制“目录树 + 树内子挂载”，--bind 适合单层目录入口；传播控制用 rslave 或 rprivate 表达，观察用 findmnt 和 mountinfo，回收用 umount --recursive。把这四个动作分开记录，排障时就不会把“内容可见”“事件传播”和“资源清理”混成一个问题。