混合协议为什么危险
NFS 侧身份是 UID/GID、权限是 POSIX 位加 NFSv4 ACL；SMB 侧身份是 SID、权限是共享权限与 NTFS ACL 叠加。同一份数据被两条路径访问时，全部一致性都依赖中间的映射规则与 ACL 换算，而锁管理器和客户端缓存又是各自独立的，不会互相通知。
基本信息
| 映射核心 | NFS 的 UID/GID 与 SMB 的 SID 之间经 idmap 或用户名映射转换 |
|---|---|
| 权限换算 | NFSv4 ACL 与 Windows ACL 语义相近，但继承标志与掩码位并不等价 |
| 锁域隔离 | NFS 锁与 SMB 锁分别由不同锁管理器维护，彼此不可见 |
| 缓存行为 | 两侧客户端各自缓存元数据与数据，没有跨协议失效通知 |
| 命名规则 | SMB 对字符集、大小写与保留字符的处理更严格 |
风险高发场景
- 迁移过渡期新旧客户端并存：旧 NFS 客户端与新 SMB 客户端同时写同一目录
- NAS 同时对外提供两种协议：未明确划分哪些目录对哪种协议只读
- 跨平台协同目录：Linux 侧跑计算、Windows 侧编辑文档，两边都需写
- 存储替换或协议切换：共享路径保留但协议变了，映射表没跟着更新
- 临时提权放行：为解决问题放宽一侧权限，另一侧判定随之改变
一致性核对命令
一致性核对命令
# Linux 侧查看属主与 ACL
getfacl /data/proj/report.docx
nfs4_getfacl /data/proj/report.docx # NFSv4 ACL 明细
# SMB 侧查看同一文件的属性与权限
smbclient //nas/proj -U user -c 'allinfo report.docx'
# Samba 环境确认映射结果
wbinfo -n user # 账号名对应的 SID
net idmap dump # 当前 UID/GID 与 SID 的映射表混合访问风险对照
| 风险 | 成因 | 典型表现 |
|---|---|---|
| 权限判定不一致 | ACL 模型换算存在语义损耗 | 同一用户一侧可写、另一侧只读 |
| 属主显示异常 | UID/GID 与 SID 缺少对应映射 | 属主变成 nobody 或纯数字 ID |
| 互相看不到新数据 | 两侧缓存独立且无失效通知 | 写入后另一侧短时间读到旧内容 |
| 并发写覆盖 | 锁管理器相互独立 | 两协议同时写同一文件，后写覆盖前写 |
| 访问直接失败 | SMB 命名与大小写规则更严 | NFS 侧合法的文件名在 SMB 侧打不开 |
| 删除被拒 | Windows 共享模式与 POSIX 语义不同 | 一侧删除失败并提示文件被占用 |
长期双协议并存时，按用途切目录通常比强行统一 ACL 更稳：把人工编辑目录划给 SMB，把计算与流水线目录划给 NFS，另一种协议对不属于自己的目录只读。这样映射偏差的影响面被限制在单个目录内。
同一文件被两种协议同时写入是数据损坏的高发场景：两边锁域互不感知，SMB 侧缓存回写可能整块覆盖 NFS 侧刚写入的内容，而服务端日志通常没有任何异常记录。