Linux nsenter --mount 怎样进入目标挂载视图

排查容器或服务“宿主上明明有这个挂载、进程里却看不到”的问题时，先别急着加 --all。只要目标是查看文件系统挂载视图，通常使用 sudo nsenter --target PID --mount /bin/sh 就够了：--target 负责找到目标进程，--mount 只切换到它的 mount namespace，网络、PID 和用户 namespace 仍保持当前 shell 的上下文。

先确认目标进程的挂载视图

mount namespace 是进程可见挂载点的集合。同一 namespace 中的进程看到相同的挂载视图，因此第一步不是进入，而是把当前 shell 与目标 PID 的证据摆在一起。下面的命令只读取 namespace 链接和挂载信息，不修改挂载。

# 把目标 PID 替换成实际服务或容器内进程的 PID
PID=1234

# 查看当前 shell 与目标进程是否引用不同的 mount namespace
readlink /proc/self/ns/mnt
readlink /proc/$PID/ns/mnt

# 只筛选目标进程的关键挂载点，便于与进入后的视图比较
grep -E ' /proc | /sys | /etc | /app ' /proc/$PID/mountinfo

两个 readlink 的 inode 标识不同，只说明它们属于不同 mount namespace；真正要核对“看到了什么”，仍应以 mountinfo 中的挂载路径和传播字段为准。下面这张图是 namespace 边界的静态说明图，不是本机截图，也不是运行证据。

用 nsenter --mount 进入目标挂载树

最常用的写法是把目标 PID 和 --mount 放在一起。--mount 不带参数时，会使用 --target 指向进程的 mount namespace；最后的 /bin/sh 是进入后的程序，省略它时 nsenter 通常会按环境变量或账户设置启动 shell。

也可以显式指定 namespace 文件，适合已经保存了句柄或不想依赖目标 PID 的场景：

# namespace 文件由内核通过 /proc 暴露，路径必须指向目标的 mnt
sudo nsenter --mount=/proc/1234/ns/mnt /bin/sh

如果命令报权限错误，先确认当前用户能读取目标进程的 namespace 文件，并具备进入该 namespace 所需的权限；不要把失败简单归因于挂载点不存在。

进入后怎样验证视图并控制风险

进入 shell 后，建议先做只读检查，再决定是否执行任何 mount 或 umount。findmnt 适合快速看路径对应的文件系统，/proc/self/mountinfo 则能看到更完整的父子挂载关系和传播标记。

这里最容易踩坑的是传播关系。一个挂载被标记为 shared 时，后续挂载事件可能沿着共享组传播；master 与 slave 表示单向传播关系；private 则不参与这类传播。进入 mount namespace 并不自动把所有操作变成“只影响自己”，所以诊断阶段优先读 mountinfo，必要时在明确边界后再考虑把目标挂载设为私有。

参数边界与排查清单

• 目标路径消失：先比较进入前后的 mountinfo，不要只看宿主机的 mount 输出。
• 进入后看到路径但读写失败：继续检查 UID、文件权限、只读挂载和 user namespace，不要把 mount namespace 当成授权系统。
• 挂载或卸载影响了别处：回看传播标记，确认是否属于 shared group，并记录操作前后的 mountinfo。

相关问题

只想看挂载视图，需要加 --pid 吗？

不需要。标题场景只涉及 mount namespace，使用 --target PID --mount 更容易控制影响范围。只有排查进程树本身时，才考虑 PID namespace。

nsenter --mount 后为什么仍然没有权限？

切换挂载视图不等于切换 UID、GID 或 capability。文件权限、只读属性、user namespace 和 LSM 仍可能拒绝访问。

为什么同一个目录在两个 shell 里显示不同？

两个 shell 可能处在不同 mount namespace，或者挂载传播状态不同。用各自的 /proc/self/ns/mnt 和 /proc/self/mountinfo 对照，才能区分这两类原因。