两个协议的根本差异
NFS 源自 Unix，用 UID/GID 数字标识身份，权限是 POSIX 权限位加 NFSv4 ACL，协议本身偏无状态、客户端缓存激进；SMB 源自 Windows，用 SID 标识身份，权限是共享权限与 NTFS ACL 叠加取交集，会话有状态，原生带 oplock/lease 与变更通知。选型真正要比的是身份体系、权限语义与客户端能否原生接入。
基本信息
| 典型客户端 | NFS：Linux/Unix、macOS、虚拟化平台；SMB：Windows 与多数桌面 |
|---|---|
| 身份标识 | NFS 用 UID/GID 或 Kerberos 主体；SMB 用域账号与 SID |
| 权限叠加 | NFS 为导出选项加文件系统权限；SMB 为共享权限与 NTFS 权限取交集 |
| 锁与通知 | NFS 依赖 lockd/NLM 或 NFSv4 内建；SMB 使用 oplock 与 lease |
| 主要端口 | NFSv4 只需 2049/TCP；SMB 主用 445/TCP |
| 审计能力 | NFS 依赖系统审计与存储日志；SMB 配合 AD 原生支持对象访问审核 |
典型使用场景
- 纯 Linux 计算集群、容器与虚拟化挂载数据盘：NFS 少一层身份映射
- Windows 办公用户访问部门共享盘与漫游配置：SMB 是唯一自然选择
- 混合环境中主力是 Windows 用户：存端开 SMB，Linux 侧用 cifs 客户端接入
- 权限审计要落到具体人且账号来自 AD：SMB 与域审计天然贴合
- 高性能纯读分发、无身份区分的场景：NFS 配置更简单、路径更短
两种协议接入同一存储
两种协议接入同一存储
# Linux 客户端走 NFS
mount -t nfs -o vers=4.2 10.0.0.10:/data/proj /mnt/proj
# 同一共享用 SMB 挂到 Linux，必须显式指定身份与权限映射
mount -t cifs //10.0.0.10/proj /mnt/proj -o vers=3.1.1,uid=1000,gid=1000,file_mode=0664,dir_mode=0775
# 选型前的核对命令
showmount -e 10.0.0.10 # 服务端宣告的 NFS 导出
smbclient -L //10.0.0.10 -U user # 服务端 SMB 共享与协商能力选型对照维度
| 维度 | NFS | SMB |
|---|---|---|
| 主要客户端 | Linux/Unix、macOS、虚拟化 | Windows、macOS，Linux 经 cifs |
| 身份标识 | UID/GID 数字或 Kerberos 主体 | 域账号与 SID |
| 权限模型 | 导出选项加文件系统权限 | 共享权限与 NTFS 权限取交集 |
| 锁机制 | lockd/NLM 或 NFSv4 内建 | oplock 与 lease |
| 审计与合规 | 依赖系统审计与存储侧日志 | AD 对象访问审核原生支持 |
| 跨平台难点 | Windows 侧需额外映射，UID 难统一 | Linux 侧需指定 uid/gid 与挂载选项 |
同版本、同网络条件下两种协议都能接近跑满链路，差异通常出现在海量小文件与元数据密集场景，而且更多取决于服务端实现而非协议本身。先按身份与权限能否对齐筛选，再谈性能调优。
同一份数据不要同时向两种协议开放写权限，除非已确认 ID 映射与 ACL 模型完全对齐。否则容易出现一侧设定的权限在另一侧不生效，或者两边并发写互相覆盖。