–bind仅绑定指定路径本身，不包含子挂载点；–rbind则递归绑定源路径及其所有已挂载的子文件系统。docker默认使用–bind语义，不支持原生–rbind，需宿主机先用mount –rbind创建透传视图再映射进容器。
–bind 和 –rbind 都用于将一个目录或文件挂载到另一个位置，但它们对子挂载点（submounts）的处理方式不同，这在 Docker volume 场景中直接影响容器能否访问宿主机上已挂载的嵌套文件系统（如 NFS、tmpfs、其他 bind mount 等）。
核心区别：是否递归传播子挂载点
–bind 仅绑定指定路径本身，不包含其下已存在的任何挂载点。例如，若 /mnt/data 下有 /mnt/data/nfs 是一个独立挂载的 NFS 文件系统，执行：
mount --bind /mnt/data /container/data
则 /container/data/nfs 在容器内将不可见或显示为空目录（取决于挂载顺序和 mount propagation 设置），因为 --bind 不穿透原路径下的子挂载。
–rbind（recursive bind）会递归地将源路径及其所有已挂载的子文件系统一并绑定过去。执行：
mount --rbind /mnt/data /container/data
则 /container/data/nfs 将与宿主机上的 /mnt/data/nfs 完全一致，包括其挂载类型、权限和内容。
Docker 中默认不支持 –rbind，需手动或通过特权模式启用
Docker 的 -v 或 --mount 默认使用的是 --bind 语义，且不提供原生 --rbind 参数。这意味着：
- 直接
docker run -v /mnt/data:/data ...无法让容器看到/mnt/data下的子挂载（如/mnt/data/backup若是单独挂载的 tmpfs） - 若需该行为，必须在宿主机先用
mount --rbind创建一个“透传视图”，再将其映射进容器 - 例如：
mkdir -p /mnt/data-merged<br>mount --rbind /mnt/data /mnt/data-merged<br>docker run -v /mnt/data-merged:/data:ro ... - 注意：使用
--rbind需要CAP_SYS_ADMIN权限，在容器中启用需加--privileged或显式授权，生产环境慎用
实际 Docker 场景中的典型需求与替代方案
常见需要递归挂载的场景包括：
- 开发环境共享整个 NFS 挂载点（含其内部多个子项目目录）
- kubernetes Node 上将 hostPath 指向一个含多个 submount 的根目录（如
/var/lib/kubelet/pods下可能有 overlay、tmpfs 等） - CI 构建容器需访问宿主机上动态挂载的 artifact 存储（如 CephFS + tmpfs 缓存组合）
若不能或不愿用 --rbind，可考虑：
- 显式挂载每个子路径：如
-v /mnt/data:/data -v /mnt/data/nfs:/data/nfs - 改用
sharedmount propagation（需宿主机支持），并在容器内再次 bind mount 子目录（复杂且依赖配置） - 在容器启动前用脚本自动发现并挂载子路径（适合固定结构）
安全与稳定性提醒
--rbind 本质是挂载传播的强耦合，会带来潜在风险：
- 容器内卸载子挂载点（如
umount /data/nfs）可能影响宿主机（取决于 mount propagation 类型） - 若源路径下挂载了不可靠的远程文件系统（如不稳定 NFS），容器可能因 I/O hang 被卡住
- Docker 默认使用
privatepropagation，因此即使宿主机用了--rbind，容器内新增挂载也不会反向传播；但反过来，容器内 umount 仍可能受限于底层 mount Namespace 权限
生产环境中建议优先采用显式、最小化挂载策略，仅在明确需要完整子挂载拓扑时才引入 --rbind，并做好权限隔离与超时控制。