先交代一下背景。局域网共享文件这件事几乎每个做运维、做嵌入式、搞 NAS 的同行都会遇到同一个问题到底用 SMB 还是 NFS前两天我在一个技术群里看人为了这个吵起来——一方说 SMB 在 Windows、Linux、手机上都通用另一方说 NFS 性能好、Linux 下用起来才叫舒服。说实话两边都没错但都只说对了一半。SMB 和 NFS 都是网络文件共享协议目标却完全不一样一个长在 Windows 生态一个长在 UNIX 生态。你手里是 Windows 台式机、Linux 服务器、ARM 开发板还是电视盒子跑在什么样的网络环境里直接决定了哪个更适合你。这篇文章我把两边的来历、性能表现、功能差异、典型场景坑和排查链路一次摊开讲适合混合环境运维、嵌入式开发、以及想给 NAS 选共享协议的朋友参考。1. 先搞清楚SMB 和 NFS 的设计目标根本不在一条赛道上很多对比文章上来就列参数、贴 benchmark反而让人更迷惑。我觉得要先看它们各自是怎么来的解决什么问题才能真正理解后面所有优劣。1.1 SMB 是 Windows 生态的共享协议之王SMB 全称 Server Message Block80 年代 IBM 做 PC 网络时提出微软后来把它吸收进 Windows慢慢发展成局域网文件共享的事实标准。早期 Windows 的网上邻居全靠它撑着后来微软在 SMB 1.0 基础上推出 CIFSCommon Internet File System再后来重写协议栈推出 SMB2、SMB3一直用到今天。SMB 的设计目标非常明确让局域网里的 PC 能像访问本地磁盘一样访问别人的共享文件夹而且要开箱即用。所以它做了很多方便用户的事——自动发现共享、自动协商协议版本、靠 NetBIOS 广播主机名、直接走 TCP 445 端口。你从 Windows 资源管理器输入\\192.168.1.10\share就能连背后那一堆握手、协商、会话建立都是协议自己完成的。SMB3 之后又补了不少企业级能力Multichannel 支持多网卡并行提升吞吐SMB Direct 可以走 RDMA 绕过内核协议栈SMB over QUIC 能加密穿越公网访问端到端 AES 加密和故障转移集群支持也都是新引入的。所以别看它出身是家庭局域网共享现在早已不是当年那个小协议了。1.2 NFS 是 UNIX 世界的远程文件系统元老NFS 是 Sun Microsystems 在 1984 年发布的网络文件系统基于 ONC RPC / XDR 设计目标是让 UNIX 工作站之间共享文件成为一种标准能力。NFSv2 和 NFSv3 长期占据服务器领域后来 NFSv4 做了大量重新设计加入了状态、文件锁、复合操作等特性。NFS 的设计更偏向服务器与服务器之间共享资源。早期 NFSv3 是典型的无状态协议服务器不记录客户端会话状态每个请求都是独立 RPC。服务器重启后客户端只要重新发送请求就能继续工作崩溃恢复逻辑非常干净。在 HA 环境里这是巨大的优势也是它几十年扎根 UNIX/Linux 的重要原因。NFSv4 引入了状态管理、锁、批量操作还造出伪文件系统概念来表示导出的目录树以及基于 Kerberos 的身份认证和可选加密。不过真正生产环境里大量场景还在用 NFSv3尤其是嵌入式开发领域——后面我会专门讲为什么。1.3 一句话理解协议哲学差异类比一下SMB 像去餐馆吃饭服务员会记住你的桌号、菜单、忌口整个过程有状态服务体验好NFSv3 更像寄明信片每张明信片都写得清清楚楚丢了就再寄一封邮局不需要记住任何历史记录。NFSv4 是在明信片旁边加了个小助手帮你把几张明信片打包成一次发出复合操作但整体还是请求-响应的 RPC 风格。这种差异会渗透到所有层面——权限怎么管、锁怎么处理、加密怎么开、跨平台好不好用都能从设计目标里找到原因。所以下面我完全按实际场景来对比而不是干巴巴背协议字段。2. 性能对比大文件、小文件、高并发三种负载下的真实差距性能是最容易被嘴炮带偏的领域。NFS 比 SMB 快这种结论经常被人无脑引用其实要分负载、分客户端、分网络环境。2.1 大文件顺序读写瓶颈在网络和磁盘不在协议在大文件顺序读写场景里SMB3 和 NFS 的差距通常很小。我在千兆网加机械盘环境测过两者都能跑到 110MB/s 左右换到万兆网加 SSD也能都在 900MB/s 上下浮动。此时真正的瓶颈是网卡、磁盘、内存通道而不是协议本身。为什么很多老工程师会说 NFS 快因为 NFS 走 RPC封装路径短、CPU 占用低SMB3 内核实现Linux 的 cifs.ko虽然优化多年但协议里的会话维持、签名、协商等固定开销确实比 NFS 大。反过来说SMB3 的 Multichannel 能在多网卡万兆环境里叠加带宽NFS 要自己去做 bond 才算等效。所以如果你只是偶尔传大 ISO、视频素材两个协议选谁都没问题不用纠结。2.2 小文件与高并发协议开销开始显现小文件随机访问才是分水岭。NFSv4.1 引入 COMPOUND 操作后可以把 open、lookup、read、getattr 合并成一次 RPC 往返延迟一下子降下来NFSv4.2 又加了 READ_PLUS 之类的优化。SMB 2.1/3.0 也有复合操作和异步机制但协商、会话层面的固定开销更大。我做构建产物共享时有个直观感受同一目录放大量小文件Linux 客户端挂 NFSv4.1 拉取比 SMB3 快大概 20% 到 30%。这个数据受硬件和内核版本影响很大但趋势是稳定的。NFS 的内核属性缓存、目录缓存非常成熟配合 gcc 编译、代码同步这类高并发小文件场景收益确实是实打实的。反过来纯 Windows 环境里跑高并发随机 I/OSMB 加上 Windows Server 的 oplock/lease 机制比 Windows 当 NFS 客户端要稳得多。Windows 对 NFS 客户端的实现一直偏弱这是另一个不能忽略的现实。2.3 开启加密后的性能衰减不能忽略SMB3 支持端到端加密Linux 挂载时可以指定seckrb5默认也会协商 AES 加密。NFS 传统上默认明文NFSv4.1 加 Kerberoskrb5p才会加密数据。实测里没有 AES-NI 加速的老服务器开 SMB3 加密加签名后吞吐可以降 15% 到 30%NFSv4 开krb5p降得更多GSSAPI 层的处理开销确实不小。这给我们的工程启示是内网隔离、可管控的环境没必要给全链路加密掏性能代价一旦跨网段、跨机房至少要开签名或加密。安全与性能永远是取舍协议本身不决定选择你的信任边界才决定。2.4 我自己测过的一组参考数据先声明这些数据只来自我手头几台机器的实测硬件和内核版本都会影响结果看看趋势就好。负载类型SMB3NFSv4.1/4.2备注大文件顺序读950-1100 MB/s1000-1150 MB/s万兆网 SSD接近线速大文件顺序写850-1000 MB/s900-1100 MB/s受写缓存、掉电保护策略影响大10 万个小文件读取一般明显更快复合操作和属性缓存占优高并发随机读一般较好Windows 客户端除外开启加密后约降 15%-30%约降 25%-40%看 CPU 是否支持 AES-NI我不建议任何人拿着别家的 benchmark 就做决定。你的磁盘型号、网卡、内核版本、Samba 参数、exports 参数都不一样差出 20% 太正常了。后面第六节我会给一套自己验证的方法。3. 功能与运维维度权限、锁、跨平台支持哪个更省心性能只能说谁更快真正决定你日常头疼不头疼的往往是权限怎么分、锁靠不靠谱、客户端好不好找、出了问题好不好处理。3.1 权限模型ACL 和 ugo 的哲学之争SMB 权限是两层结构共享权限加 NTFS 文件级 ACL。共享权限只有读取、更改、完全控制几个粗粒度选项文件级 ACL 才做到精细控制。Windows 域环境配 AD 用户组非常顺手但也正是因为这套 ACL 体系复杂Linux 用户管理 SMB 共享时经常一头雾水还要折腾 uid/gid 映射。NFS 延续 POSIX 的 rwx 三元组ugo理解成本极低。NFSv3 几乎完全信任客户端传来的 uid/gidNFSv4 引入了 idmapd 做账号映射支持 NFSv4 ACL配置复杂度也跟着上来了。我的体感是Windows 域环境里 SMB 权限是优势纯 Linux 内部环境 NFS 的 ugo 权限反而更直接。最怕的是Windows 访问 NFS这种组合——Windows 端权限语义和 POSIX 对不上ACL 经常成一堆乱码。3.2 文件锁数据库和并发写入的雷区NFSv3 的锁需要 rpc.statd 和 rpc.lockd 配合而且无状态设计意味着锁是尽力而为客户端崩溃后可能残留锁状态。NFSv4 把锁纳入协议状态解决了部分问题但 NFSv4.0 的事件重放问题在特定场景下还有坑4.1 的 Session 机制才算真正好用。SMB 的 oplock 机制很早就出现SMB2 的 Lease 机制在 Windows 平台非常成熟这种成熟度让 Windows 下的共享文件写入体验明显更流畅。可一旦涉及 Linux 客户端挂 SMB某些应用对锁和缓存语义的配合又会出现奇奇怪怪的行为。这里我要明确劝一句不管 SMB 还是 NFS都别把数据库文件直接放到共享目录上跑。数据库依赖文件锁、同步落盘、原子写网络文件系统在锁、缓存、fcntl 语义上很难完全模拟本地磁盘。真要共享存储上 iSCSI 块存储或者走数据库自带的复制能力别拿共享目录扛。3.3 跨平台客户端生态与自动发现差异先给一张客户端支持情况表平台SMBNFSWindows原生体验最佳需手动启用 NFS Services挂载和权限较脆弱Linux内核 cifs.ko配置相对繁琐内核原生性能和稳定性好macOSFinder 默认支持顺手能挂载但 GUI 支持弱Android/iOS文件管理器普遍支持基本没有可用客户端VMware ESXi不做官方推荐原生支持 NFSv3/v4.1 作为数据存储群晖/威联通 NAS默认开启需手动开启并配置权限另一个容易被人忽略的点是自动发现。SMB 在局域网里通过 WS-Discovery、NetBIOS 广播能让电脑自动看到共享资源这对家庭和办公用户非常友好。NFS 没有任何自动发现机制你必须手写服务器 IP、导出路径、挂载点。好处是 NFS 在无人值守环境里更可预期——不会因为自动发现多冒出什么暴露服务脚本化、配置化都很好做。3.4 运维复杂度到底差多少这个问题没有绝对答案完全取决于你站在哪一边。Windows 运维点两下就能建共享Linux 运维觉得 Samba 的 smb.conf 是种修行反过来 Linux 运维写一行 exports 就能导出目录Windows 运维要启用 NFS 客户端还要折腾mount -o参数和权限映射。我的建议分两种内网私有化基础设施前面全是 Linux 服务器那 NFS 运维成本最低配置可脚本化、日志可 grep、故障可复现只要有 Windows 参与就默认 SMB 生态——Samba 能配合 AD、能解决 SID 映射Windows 端网络驱动器映射体验也比任何 NFS 客户端方案都好。别在一个混合环境里强行让 Windows 去迁就 NFS。4. 典型场景逐个拆嵌入式、虚拟化、移动端、混合环境选型这件事说一千道一万落到具体场景你就知道该用什么了。我按最常见的几种环境拆开讲。4.1 嵌入式 Linux 开发NFS v3 挂载根文件系统几乎是标准答案热搜里有 rk3568 根文件系统、嵌入式 Linux 用 NFS v3这说明很多做 ARM 板子的朋友都被这个问题困扰过。瑞芯微 RK3568 这类板子在开发阶段最常见的做法就是让 Linux 内核从开发机的 NFS 目录启动根文件系统。uboot 启动时给内核传 bootargsroot/dev/nfs nfsroot192.168.1.100:/srv/nfs/rootfs ip192.168.1.50:192.168.1.100::255.255.255.0::eth0:off nfsvers3这里几个参数说明一下root/dev/nfs告诉内核根设备走网络协议栈nfsroot服务器IP:导出路径指定远程根目录ip是客户端 IP、服务器 IP、网关、掩码的固定写法nfsvers3强制用 v3。开发机 Ubuntu 上开启 NFS 服务大概是这样apt install nfs-kernel-server mkdir -p /srv/nfs/rootfs echo /srv/nfs/rootfs 192.168.1.0/24(rw,sync,no_root_squash,no_subtree_check) /etc/exports exportfs -ra systemctl enable --now nfs-server为什么嵌入式根文件系统几乎不用 SMB因为内核启动早期就要挂根文件系统虽然 cifs 驱动也能编进内核但它需要 TCP/IP 栈就绪、加载 keyring 和相关模块整个启动链状态太多、复杂度大。NFSv3 客户端简单、无状态、内核支持最悠久一个nfsroot参数就够。Buildroot、Yocto 这些工具链的默认模板也几乎都选 NFS v3不是没道理的。有个开发期常踩的坑exports 里默认开 root_squash会把客户端的 root 映射成 nobody板子上 root 用户写远程根文件系统就会报 Permission denied。开发阶段临时改成no_root_squash能少很多麻烦但做产品时要小心这个安全口子。4.2 虚拟化平台ESXi 选 NFSHyper-V 选 SMB3虚拟化领域的选型很有意思两类方案完全是生态绑定的结果。VMware ESXi 官方原生支持 NFSv3 和 NFSv4.1 作为数据存储。很多中小机房没买共享存储时就是一台 NAS 开 NFS然后让多台 ESXi 挂载同一个导出目录。NFSv4.1 在 ESXi 里还支持 ACL 和 Kerberos但配置复杂度高实际部署多数还是 v3 居多。微软 Hyper-V 走的是另一条路官方主推 SMB3 做共享存储。Windows Server 故障转移集群里SMB3 配合 CSV 共享目录存 VHDX多通道和故障转移特性天然对齐微软的集群模型。KVM/QEMU 两边都行。我见过很多 KVM 环境直接用 NFS 共享镜像简单方便如果对性能有硬要求还是要上 iSCSI 或本地存储。SMB 在 KVM 里反而少见除非你的存储阵列只支持 SMB。一句话看你的 hypervisor 厂商再选协议而不是拿着协议去套平台。4.3 移动端和家庭 NASTermux 这类场景为什么 SMB 是主角热搜里 termux smb 很能说明问题。Termux 是 Android 上的终端模拟器里面可以用pkg install smbclient访问 Windows/Linux 上的 SMB 共享也可以跑一个轻量 SMB 服务让电脑访问手机目录。这种玩法在折腾党里非常普遍。NFS 在 Android 里基本是能看不能用即便 Termux 里有 mount.nfs想挂载内核态 NFS 也得有 root而多数人手机没 root。所以移动端生态天然倒向 SMB——各种文件管理器、电视盒、智能电视全部支持 SMB 协议去网络邻居里直接就能发现 NAS。家庭 NAS 场景群晖、威联通也一样默认开启 SMB电视、手机、笔记本全都走 SMBNFS 要在控制面板手动开启通常是留给 Linux 服务器、ESXi 这类专业客户端用的。普通家庭用户完全不用碰 NFS。4.4 Windows 与 Linux 混合办公环境默认 SMB 更现实公司里一半 Windows 一半 Linux最主流拓扑就是Linux 用 Samba 提供共享给 WindowsWindows 上做网络驱动器映射\\samba_server\shareWindows 共享出去的目录Linux 端这样挂mount -t cifs //192.168.1.10/share /mnt -o usernamexxx,vers3.0为什么不反过来用 NFS核心原因是 Windows 自带的 NFS 客户端实在不够成熟默认不安装挂载后 NTFS 权限、ACL 容易错乱git、office 文件锁也常出问题。第三方 NFS 客户端又是一笔费用安装维护还麻烦。macOS、Windows、Linux 三端混合时默认 SMB 同样是最稳的macOS Finder 对 SMB 友好对 NFS 的支持很弱。5. 从共享文件夹访问失败和NFS 挂载不上说开去排查链路复盘网上有个热梗说共享文件夹访问失败时先排查 SMB 协议没错但大多数场景问题根本不在协议。这句话方向对但只说了前半句。我把两边完整排查链路都写出来。5.1 SMB 访问失败先查协议层没错但不能只停在协议层我见过太多人一遇到共享失败就怀疑协议版本后来发现只是网络或权限问题。完整排查顺序应该是网络层先ping通主机再确认 445 端口通不通nc -vz 192.168.1.10 445。共享名和服务Windows 的C$、ADMIN$管理共享需要管理员凭据普通共享名写错会报找不到共享。协议版本协商Windows 10/11 默认禁用 SMB1老打印机、老 NAS 可能只有 SMB1客户端和服务端支持集合没交集就会协商失败。旧设备建议升级或单独隔离网络不要轻易在公网上开 SMB1。签名和加密要求服务端强制签名而客户端能力不足会看到 STATUS_INVALID_SIGNATURE 之类的错误事件查看器里有记录。认证和 guest 策略Windows 默认禁 guestLinux Samba 默认可能允许 guest域环境和工作组环境的认证方式也不同。共享权限和 NTFS 权限两层权限都要放行才能写入。Linux 端排查 SMB 有个好用工具是 smbclient先smbclient -L //192.168.1.10/看共享列表再smbclient //192.168.1.10/share -U 用户名连进去就能把认证和共享名是否正常分开验证。5.2 NFS 挂载不了的完整排查链路NFS 挂载失败也很常见热搜里有人问nfs 怎么开启说明入门级问题也大量存在。先给一个 Ubuntu 上开启 NFS 服务的最小可运行流程apt install nfs-kernel-server mkdir -p /srv/nfs echo /srv/nfs 192.168.1.0/24(rw,sync,no_root_squash,no_subtree_check) /etc/exports exportfs -ra systemctl enable --now nfs-server客户端验证apt install nfs-common showmount -e 192.168.1.100 mount -t nfs 192.168.1.100:/srv/nfs /mnt/nfs如果挂载失败按下面链路查服务端 NFS 服务状态systemctl status nfs-serverrpcinfo -p 127.0.0.1确认端口映射正常。导出列表服务端exportfs -v看 exports 是否生效客户端showmount -e看能否列出。看不到导出列表问题就在 exports 文件或服务状态。exports 语法路径不能有空格括号选项用逗号分隔IP 段写法要和服务端网络匹配。防火墙NFSv4 只用到 2049/tcpNFSv3 还要 111 端口和 lockd/statd 的动态端口防火墙没放行会出现Connection timed out或Connection refused。版本匹配客户端挂载时指定vers3服务端只开了 v4会报 No such file 或 mount.nfs: Connection refused。用mount -t nfs -o vers4或vers3对号入座。权限问题root_squash 把客户端 root 映射成 nobody 导致写入被拒客户端和服务端 uid/gid 不一致导致其他用户无法读写。服务端日志/var/log/syslog和客户端 dmesg 通常都会给出明确提示。我这里还要强调一个经验NFSv3 的无状态设计让服务器重启后自动恢复很爽但也正因为无状态锁和权限的问题要靠额外的守护进程配合。如果只是内网开发调试v3 简单够用如果要求锁、加密、更现代的语义必须上 v4.1 并做好 idmap 配置。5.3 我惯用的一个排查顺序和几个小习惯我的习惯是两层日志加分步验证。两层日志就是客户端和服务端各开一份日志SMB 看 Windows 事件查看器或 Linux smbd 日志NFS 看 dmesg 和 syslog分步验证就是网络、服务、导出、版本、认证、权限一层层确认每层都有明确输出再往下走。不要一上来就改配置改坏了反而更难定位。如果遇到性能问题而不是连接问题优先怀疑三件事签名和加密是否开启、网卡 MTU / offload 设置、客户端缓存策略。抓包tcpdump 抓 445 或 2049 端口能一眼看出协商阶段在磨蹭什么比盲目调参数高效得多。6. 选型决策速查表直接照着选附一点个人经验最后给一张能直接抄的决策表按你所在的环境对号入座。场景首选协议理由纯 Windows 办公文件共享SMB原生协议权限、发现、加密生态完整Linux 服务器之间日志/构建产物共享NFS配置简单内核客户端成熟性能好嵌入式开发根文件系统NFS v3内核启动期加载简单bootargs 直接可用ESXi 数据存储NFSVMware 官方原生支持Hyper-V 故障转移集群SMB3微软官方共享存储方案KVM/QEMU 挂载镜像NFS 或 iSCSINFS 方便追求稳定性能用 iSCSIWindows/Linux 混合互访SMBWindows 的 NFS 客户端长期不好用macOS/Android/电视访问 NASSMB客户端生态全面支持跨机房或互联网访问共享SMB over QUIC 或专业远程工具NFS 默认明文且对延迟敏感数据库文件放在共享目录都不建议锁、缓存、原子写语义不可靠6.1 几个容易被网上结论带偏的点第一NFS 一定比 SMB 快只在一部分负载上成立。大文件顺序读写两者差异很小小文件高并发 NFS 占优但纯 Windows 环境里 SMB 的稳定性和锁表现反而更让人省心。网上很多对比是用 Linux 客户端挂 SMB 去和 Linux 挂 NFS 比忽略了真实 Windows 用户的体验权重。第二SMB 不安全是历史惯性。SMB1 时代确实漏洞多SMB3 引入 AES 加密和签名后安全性已经有了质的提升。如果你需要跨不可信网络传输SMB3 的加密特性反而比 NFS 默认明文更让人放心前提是你能接受 Linux 侧 cifs 的配置工作量。第三NFS 配置简单只限于 v3 和简单场景。一旦 NFSv4 引入 Kerberos、idmap、ACL复杂度会直线上升。选 v3 还是 v4 要看实际诉求内网无域环境v3 足够要状态锁、要加密、要多客户端并发上 v4.1 更合理。6.2 拿不准就自己测一轮协议对比文章能给的是方向真正的答案要靠在你自己机器上跑一轮实测。方法很简单用 fio 分别测顺序读写和随机读写同一份数据分别挂载 SMB 和 NFS 跑三遍取中位数注意两边都关闭系统缓存干扰观察 CPU 占用和 IO 延迟别只测一个大文件要建几千个 4KB 小文件测试随机创建、删除、读取。如果测下来两边差距不大那运维顺手程度、客户端生态、权限体系就是决定因素如果结果完全一边倒数据已经帮你选好了。这几年 SMB 和 NFS 我都在生产环境里踩过坑最终的体会就是没有全能最优只有对当前环境最顺。硬要浓缩成一句个人建议的话——全 Windows 就无脑 SMB全 Linux 就 NFS混合环境默认走 SMB嵌入式开发保留 NFS v3剩下的边界情况回到这张表里自己判断。最后再分享一个小技巧无论你最终选了哪一个都先把共享目录的权限模型和锁语义写进团队文档。我见过太多故障最后排查一圈发现是权限和锁的理解不一致不是协议本身的问题。工具选对了把边界和规矩立清楚才能少在深夜被叫起来修共享。
