Linux mount --bind 解除挂载时为什么要先离开工作目录

使用 mount --bind 把目录映射到新路径后，umount 报 target is busy，最常见的原因不是源目录“还在使用”，而是某个进程仍把目标挂载点当作工作目录，或持有其中的文件。先在绑定目录之外执行卸载，再排查其他进程和子挂载，通常比直接使用懒卸载更安全。

先离开目标挂载点及其子目录，再执行 umount。如果仍然 busy，就沿着挂载树和进程引用定位；不要把 umount -l 当成普通失败的第一种修复。

官方参考：https://man7.org/linux/man-pages/man8/umount.8.html

为什么 bind mount 里工作目录会让 umount 失败

下面的例子把同一份数据挂到应用目录：

# 创建目标目录，并把源目录绑定到目标目录
sudo mkdir -p /opt/app/data
sudo mount --bind /srv/data /opt/app/data

# 在目标挂载点内打开一个 shell
cd /opt/app/data

# 另一个终端执行时可能得到 target is busy
sudo umount /opt/app/data

进入目标目录的 shell 持有一个工作目录引用。内核解除挂载时要把这段挂载关系从文件层级中摘除，但仍有进程站在它里面，因此返回 EBUSY。先在同一个 shell 执行 cd / 或 cd /tmp，再重试卸载，往往就能成功。

先排除当前 shell，再定位真正占用者

“离开工作目录”只处理当前 shell 的引用，不代表所有 busy 都消失。可以按下面的检查表缩小范围：

fuser 显示进程后，不要立即对所有 PID 执行强制终止。先确认它们属于哪个服务，优先停止服务或让任务正常关闭文件；如果只是另一个终端停在该目录，切换到目录外即可。

# 在挂载点外查看引用者；注释说明每一步的排查目的
cd /tmp
findmnt -T /opt/app/data
sudo fuser -vm /opt/app/data
sudo lsof +D /opt/app/data

# 确认没有子挂载后，再执行普通卸载
sudo umount /opt/app/data

绑定挂载、软链接和传播状态不是一回事

软链接只是目录项，目标挂载被移动或卸载后，链接可能失效；bind mount 则是在挂载树上增加一个指向同一目录对象的挂载点。正因为它属于挂载树，findmnt 能看到它，umount 也必须处理挂载引用。

还要留意目标所在的挂载传播状态。私有挂载不会接收或转发传播事件；共享挂载可能把挂载、卸载动作传播给同一 peer group。容器或 systemd 场景里，如果一个看似简单的 umount 影响了另一处路径，先查看：

# 只读取当前挂载的传播属性，不改变系统状态
findmnt -o TARGET,FSTYPE,OPTIONS,PROPAGATION /opt/app/data

# 如果业务边界要求隔离传播，变更前先确认运维规范和命名空间范围
sudo mount --make-private /opt/app/data

--make-private 不是解决所有 busy 的万能开关。它只改变传播关系；工作目录、打开文件和子挂载仍需分别处理。

什么时候使用 umount --lazy

umount --lazy 会先把文件系统从当前文件层级分离，等引用全部释放后再清理。它适合关机阶段、不可达的网络文件系统等明确场景，但会把真正的引用问题推迟，网络盘或带子挂载的本地文件系统还可能留下后续排障成本。

生产环境更稳妥的收尾顺序是：停止相关服务；让所有 shell 离开目录；用 findmnt -R 检查并按子到父的顺序处理；确认传播状态；最后执行普通 umount。如果必须延迟解除，也应记录原因和后续清理条件。

常见问题

只在绑定目录外执行 umount，为什么仍然 busy？

其他进程可能仍把它作为 cwd、root 或打开文件所在路径，也可能存在子挂载。用 fuser -vm、lsof +D 和 findmnt -R 分别排查。

bind mount 会复制目录里的文件吗？

不会。它增加一个挂载点，让同一目录对象从另一条路径可见；没有发生文件复制，因此卸载只移除挂载关系。

能不能直接使用 umount -l？

可以，但应把它视为延迟清理手段，而不是隐藏 busy 的常规方案。先确认进程、子挂载和传播边界，能避免服务继续持有已分离的文件系统。