BindMount 中嵌套挂载的可见性由 mount propagation 类型控制：MS_SHARED 双向同步、MS_PRIVATE 完全隔离、MS_SLAVE 单向同步、MS_UNBINDABLE 禁止 bind 源；Docker 推荐用 rprivate 避免残留锁死。
在 bindmount 中控制嵌套挂载的可见性，核心是设置正确的 mount propagation 类型。默认情况下，bind 挂载会继承源挂载点的传播属性（通常是 shared），导致子目录中新增的挂载会“透传”到 bind 目标路径，引发意外可见或卸载失败等问题。
明确 propagation 类型的作用场景
propagation 控制的是：当某个挂载点下再挂载/卸载设备时，这些操作是否、以及如何影响同属一个 peer group 的其他挂载点。只有 bind mount 和 mount namespace 之间才涉及 propagation 行为。
- MS_SHARED：双向同步。在 /mnt/src 下挂载 /dev/sdb1 → /mnt/src/sub，/mnt/bind（bind 到 /mnt/src）下也会自动出现 /mnt/bind/sub，且内容一致
- MS_PRIVATE：完全隔离。/mnt/src/sub 新增挂载，/mnt/bind/sub 不可见；反之亦然
- MS_SLAVE：单向同步。仅源端变化会反映到从属端，从属端独立挂载不影响源端
- MS_UNBINDABLE：禁止被用作 bind 源，防止递归嵌套，一般不用于常规 bind mount
在 Docker 中显式禁用共享传播
Docker 容器默认可能继承宿主机的 shared propagation，容易导致容器退出后数据卷残留锁死。推荐在启动时强制设为 rprivate（递归 private）：
- 使用
--mount语法（推荐）：docker run --mount type=bind,source=/host/data,destination=/app/data,bind-propagation=rprivate … - 避免用
-v简写，因其不支持 propagation 参数 - 若已运行容器，需先停止并重建，propagation 无法热更新
在宿主机上手动调整 bind mount 的 propagation
对已存在的 bind mount，可通过 mount --make-private 或 --make-rprivate 实时修改：
- 临时修复：
sudo mount --make-rprivate /mnt/bind（递归生效，影响所有子挂载点） - 验证当前 propagation：
findmnt -o TARGET,PROPAGATION /mnt/bind，输出应为rprivate - 注意：必须在 bind 挂载完成后再执行，不能在 mount 命令中与
--bind合并在一条命令里（需两步）
规避 propagation 风险的设计建议
与其频繁调试 propagation，不如从结构上减少依赖：
- bind mount 的 source 路径不要嵌套在其他挂载点内（例如避免将
/host/data挂到/mnt/nfs/share下） - 容器内需要访问多个存储位置时，优先用多个独立 bind mount，而非在某一层 bind 下再做子挂载
- 生产环境优先使用
docker volume替代 bind mount，Volume 默认使用rprivate，且由 Docker 管理生命周期，不易锁死
