Linux mount bind 目录后为什么权限表现仍然不同

mount --bind 只是把同一段文件层级接到另一条路径上，不会复制目录，也不会自动修改源目录里的 owner、group 或 mode。于是，绑定前后看到的路径可能不同，真正参与权限判断的文件对象却还是同一个；如果访问结果不一致，通常要继续检查挂载点属性、父目录搜索权限、ACL、进程 UID/GID 以及所在 mount namespace。

bind 改变的是“从哪里看到对象”，不是“对象归谁所有”。先用 findmnt 看挂载关系，再用 stat 和进程凭据看权限，才能避免把路径映射误当成权限修复。

为什么 bind 之后权限不会自动改变

假设源目录是 /srv/data，目标目录是 /opt/app/data：

# 创建目标目录；目录本身只是挂载承载点
sudo mkdir -p /opt/app/data
# 将源目录的文件层级接到目标路径
sudo mount --bind /srv/data /opt/app/data
# 两条路径都能访问同一份内容
ls -ld /srv/data /opt/app/data

mount(8) 对 bind 的定义是把文件层级重新挂到别处，并强调 bind 不会在 VFS 中创建一种“次等节点”。它增加了一个挂载视图，源目录可以随后卸载，目标视图仍可能存在。更关键的是，目录里的文件和子目录没有因为换了路径就获得新 inode。

因此，chmod 750 /srv/data、chown app:app /srv/data 这类操作改变的是对象元数据，另一条 bind 路径也会反映出来。反过来，目标路径上的原目录内容和 mode 在挂载期间会被遮住，不能据此判断 bind 已经替你改过权限。

挂载点只读和文件 mode 不是一回事

最容易混淆的是 ro。用 bind 创建只读视图时，限制的是目标挂载点的写入能力；源文件系统的 superblock 仍可能可写，源路径不一定随之变成只读。也就是说，ls -l 看到的 rwx 位和挂载点的 VFS 属性处于不同层次。

# 先建立普通 bind 视图
sudo mount --bind /srv/data /opt/app/data
# 只给目标挂载点增加只读属性
sudo mount -o remount,bind,ro /opt/app/data
# 查看挂载点属性；不要把它当成 inode mode 的替代品
findmnt -T /opt/app/data -o TARGET,SOURCE,FSTYPE,OPTIONS,PROPAGATION

如果目标路径无法写入，而源路径仍能写入，这并不矛盾：前者是挂载入口的限制，后者是同一对象在另一挂载视图下的访问结果。若目标路径连读取都失败，则要回到普通 Unix 权限检查，不能只盯着 ro。

用 findmnt 和 stat 把问题拆开看

排查时建议固定分成两张表。第一张只记录挂载拓扑：source、target、文件系统类型、挂载选项和传播属性。findmnt -T 适合按路径定位挂载点；需要更底层的信息时，再看当前进程对应的 /proc/self/mountinfo。

# 按目标路径查看它落在哪个挂载点
findmnt -T /opt/app/data -o TARGET,SOURCE,FSTYPE,OPTIONS,PROPAGATION
# 查看当前 mount namespace 看到的挂载记录
grep ' /opt/app/data ' /proc/self/mountinfo

第二张只记录对象和访问者：

# 对比两条路径的设备号、inode、权限和所有者
stat -c '%n dev=%d inode=%i mode=%A owner=%U:%G' /srv/data /opt/app/data
# 确认当前进程用于权限判断的身份
id
# 需要时再检查 ACL；没有 ACL 的系统会提示未设置
getfacl -p /opt/app/data

如果两条路径中的文件显示相同的设备号和 inode，说明它们指向同一对象；如果目录本身的 inode 不同，也不代表 bind 复制了数据，因为目标目录可能只是原来的挂载承载点。此时还要沿路径检查父目录是否给当前用户保留了 x（搜索）权限。

还要检查递归挂载和命名空间边界

普通 --bind 只接入指定文件系统的一部分，不会自动带上源目录下的子挂载；需要连同子挂载一起复制时才考虑 --rbind。此外，挂载列表属于 mount namespace，同一主机上的两个进程未必看到同一份挂载关系。findmnt 和 /proc/self/mountinfo 看到的是当前进程所在命名空间的视图。

共享、slave、private 等传播属性也会影响后来创建或卸载的子挂载是否传播到另一处。生产环境调整前，先保存 findmnt -o TARGET,PROPAGATION 的结果；不要为了“修权限”直接使用 --rbind 或递归改变传播属性。

最后可以按这个顺序收敛问题：确认目标路径是否真的是 bind 挂载；确认 source 与 target 是否位于同一命名空间；比较实际文件的 inode、owner、mode；检查父目录的搜索权限和 ACL；最后才判断是否需要调整 inode 权限，或仅给目标挂载点做 remount,bind。这样既不会误改源数据，也能解释为什么两个入口的写入表现不同。

几个容易混淆的追问

bind 后能不能单独给目标路径 chmod？ 通常不能把它理解成给同一批文件复制一套独立 mode；chmod 仍然作用于文件对象。若要隔离写入能力，应讨论挂载点属性、命名空间或独立文件系统。

为什么目标目录原来的权限看不见了？ 挂载后，目标路径原有内容和 owner/mode 会被挂载内容遮住；卸载后它们才重新可见。这是路径覆盖现象，不是源目录权限被迁移。

参考资料

• mount(8) Linux manual page：bind、remount 和传播属性说明。
• mount_namespaces(7) Linux manual page：mountinfo 与命名空间边界。
• Linux kernel Shared Subtrees：bind、rbind 和传播关系。