是什么
多台主机挂载同一个文件存储（NAS 或共享文件系统）后，能不能写入不由“谁挂载的”决定，而由文件自身的属主属组、目录权限位与存储侧的映射规则共同决定。最常见的故障是同一批服务器上同名用户的数字 ID 不同，导致 A 机能写、B 机只能读；其次是存储默认把 root 映射成匿名用户，root 直接写入被拒。
基本信息
| 判定方式 | POSIX 权限按数字形式的用户与组 ID 判定，不看用户名 |
|---|---|
| root 映射 | 默认常把 root 映射为匿名用户，root 直写会失败 |
| 规划建议 | 统一各机业务账号的 ID，按业务子目录分别授权 |
| 验证方式 | 用实际业务账号写入测试，而不是用 root 试 |
| 共享粒度 | 目录级授权加组权限，避免整盘一个权限打天下 |
典型使用场景
- 多台应用服务器共享上传目录，需要所有节点都能写同一份文件
- 容器与宿主机共享挂载目录，容器内用户与宿主用户 ID 不一致导致写入失败
- 新旧系统并行期间账号体系不同，需要临时打通权限再逐步收敛
- 按业务线划分子目录：各自授权，避免越权读写他人数据
- 排查“能读不能写”：按目录权限、属主与映射规则逐层核对
查看与验证权限
查看与验证权限
id # 当前账号的用户与组数字 ID
ls -ln /mnt/shared # 用数字形式看属主属组，避免同名混淆
getfacl -m g:data:rwx /mnt/shared # 按组授权，比逐用户授权更好维护
sudo touch /mnt/shared/test-write && sudo rm /mnt/shared/test-write
# 用真实业务账号复测，root 能写不代表业务账号能写
sudo -u appuser touch /mnt/shared/test-appuser常见现象与原因
| 现象 | 常见原因 | 处理方向 |
|---|---|---|
| root 能写但业务账号不能 | 目录属主与权限位不对业务账号开放 | 按组授权或调整属主，别用全开放兜底 |
| 某台机器能写另一台不能 | 同名用户在不同机器上的数字 ID 不一致 | 统一各机账号 ID，或在存储侧做映射 |
| 新建文件属主异常 | 创建进程实际以其他身份运行 | 确认服务运行账号与目录授权是否匹配 |
| 删除失败提示权限不足 | 父目录缺少写权限 | 删除取决于父目录权限，检查上一层 |
为省事给目录设置成所有人可读写（777）或关闭 root 映射，会放大误删与越权风险；优先用统一账号 ID 加分组授权的方式解决。
排查共享目录权限问题时，按顺序核对四件事：当前账号的数字 ID、目录与父目录的权限位、存储侧的映射规则、实际写入进程的身份。四者对齐了，问题基本就定位到了。