刘新征家里那台NAS、办公室的共享目录、开发板上的根文件系统，凡是涉及“把文件借给别人访问”的场景，几乎都会撞上两个老熟人：SMB 和 NFS。一个在 Windows 生态里家喻户晓，一个在 Unix/Linux 世界里闷声干活。我这些年折腾共享存储，从给家庭 NAS 配共享文件夹，到给 RK3568 开发板挂 NFS 根文件系统，再到帮同事排查公司共享目录访问失败，最后发现所有踩坑经历其实都在回答一个问题：到底该选 SMB 还是 NFS，以及出问题的时候先从哪儿查起。这篇文章不打算把协议报文格式逐条搬出来，而是站在实际使用的角度，把 SMB 和 NFS 的优缺点、适配场景、搭建步骤和排障经验一次讲透。
1. 先搞清楚，SMB 和 NFS 到底在帮你干什么
1.1 SMB：从局域网“网上邻居”走出来的老牌协议
SMB 全称 Server Message Block，最初由 IBM 在 1983 年提出，后来被微软大量使用并逐渐发展成 Windows 网络共享的核心协议。早期它依赖 NetBIOS，端口 139 是常客；后来随着 Windows 2000 之后的演进，SMB 开始直接跑在 TCP 445 端口上，不再需要 NetBIOS 这个“中间商”。你打开“网络”看到那些带共享图标的机器，或者在资源管理器里输入 \\192.168.1.100\share，走的都是 SMB。
它的工作方式可以类比成“和银行柜台办业务”：客户端发起一个请求，SMB 服务端响应，一来一回之间还要处理身份验证、文件锁、打开句柄这些“业务凭证”。每次读写文件都像递了一次单据，规则清晰、流程完整，但交互过程自然比裸奔要重一些。SMB 的核心优势也很明显：它对用户极其友好，Windows 下鼠标右键就能共享，Mac 和 Linux 也都能当客户端接入，而且天然支持打印机共享、用户级权限和域认证这些“办公味”很足的功能。
1.2 NFS：为 Unix/Linux 世界而生的远程文件访问协议
NFS（Network File System）则是 Sun Microsystems 在 1984 年搞出来的，一开始就是为了解决无盘工作站的环境——机器没有本地磁盘，启动和读写都得指望服务器上的文件系统。NFS 的哲学更像“自动售货机投币取货”：客户端内核里直接挂了远程路径，随后通过 RPC（远程过程调用）发 READ、WRITE、LOOKUP 这类请求，服务端执行完把结果丢回来，过程轻快直接。
早期 NFS v2/v3 是无状态设计，服务器崩了重启，客户端重试请求就能继续，这在那个机器动不动就宕机的年代是巨大优势。后来 NFS v4 引入了有状态的特性和更完善的安全模型，但内核里那份“把远程目录当成本地目录”的核心体验一直没变。以至于到现在，Linux 服务器之间共享目录、嵌入式开发板挂载根文件系统、虚拟化平台的存储后端，NFS 都是默认候选之一。可以说，SMB 赢了普通用户的心，NFS 赢了技术人手的活儿。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. SMB 的优点、痛点与关键细节
2.1 为什么说 SMB 是对用户最友好的共享协议
SMB 最大的优点是“开箱即用”。在一台安装了 Windows 的机器上，文件夹右键属性里的“共享”选项卡就是全部入口，不需要懂任何命令行。客户端更不用说，Windows 自带、Mac 支持、Linux 用 cifs-utils 挂载也方便，甚至安卓手机上的文件管理器都能直接访问 SMB 共享，这也解释了为什么 Termux 玩家会在手机端折腾 smbclient 访问 NAS 上的文件。
SMB 在认证与权限这块做得比较“正经”：支持用户密码、域认证（Active Directory）、Kerberos 票据，还能配置细粒度的 ACL 权限。办公环境里经常会遇到“某个人对共享目录只有读取权限，另一个人能写入但删不掉别人文件”这种需求，SMB 的权限体系能很顺地承接。再加上它原生支持文件和打印共享，办公室里一两台 Windows 机器稍微配置一下，整个部门就都能用了。
从协议演化来看，SMB 也是下了功夫的：SMB 2.0 开始引入租约和复合请求，减少“一问一答”的往返次数；SMB 3.0 带来了端到端加密、多通道、持久句柄和 RDMA 支持，在 Windows 存储场景里已经接近“数据中心级”的能力。SMB 3.1.1 还加入了更安全的协商机制，防止中间人降级攻击。
2.2 SMB 的隐藏成本：协议开销、兼容性与安全陷阱
SMB 的复杂度是它的双刃剑。因为历史包袱太重，SMB 1.0 时代留下的兼容性噩梦至今还在坑人。想当年 WannaCry 勒索病毒打穿大量 Windows 机器，主要依靠的就是 SMBv1 的漏洞。现代环境里我建议直接禁用 SMB1，但有些老打印机、老 NAS 设备只认 SMB1，这就导致兼容性难以两全。在 Windows 里可以通过 PowerShell 一行命令禁用 SMB1，发现问题再针对性排查，而不是默认开着这个“定时炸弹”。
SMB 的性能也不是白来的。因为协议交互重，单线程拷贝大文件时往往跑不过 NFS，尤其是跨平台场景：Linux 挂载 Windows 共享、Windows 访问 Linux Samba，版本协商和加密一旦开启，CPU 开销会明显上升。很多人遇到“共享文件夹访问失败”第一反应是怀疑 SMB 协议配置，但根据我的经验，真正的问题往往在防火墙、凭据、端口或共享权限上，协议本身通常只是“背锅侠”。SMB 的许可证和专利生态也偏封闭，微软的 SMB 实现不可替代，开源社区只能靠 Samba 逆向兼容，某些特殊功能（比如部分 SMB 3.x 特性）在 Samba 上始终落后一拍。
2.3 SMB 版本差异：从 CIFS 到 SMB 3.1.1
平时我们经常听到有人把 SMB 叫 CIFS，严格来说 CIFS 只是 SMB 的一个早期方言，现在说的 SMB 3.x 早就不是那回事了。选择协议的时候，尽量让客户端和服务端都走向 SMB 3.0 以上，特别是开启了加密和多通道之后，传输效率和安全性都有明显提升。
| 协议版本 | 出现背景 | 关键特性 | 现代建议 |
|---|---|---|---|
| SMB 1.0 / CIFS | 早期 Windows 网络共享 | 基于 NetBIOS、安全性差 | 关闭 |
| SMB 2.0 / 2.1 | Windows Vista / 7 时代 | 复合请求、租约缓存 | 能用但尽量升级 |
| SMB 3.0 | Windows Server 2012 时代 | 加密、多通道、RDMA | 优先开启 |
| SMB 3.1.1 | Windows 10 / Server 2016 时代 | 安全协商升级、完整性校验 | 现代环境首选 |
对普通用户来说，记住最实用的一条就够：别再用 SMB1。只要还有设备在跑 SMB1，它就像共享网络里的一扇破窗，谁都能钻进来。
3. NFS 的优点、局限与你必须接受的“任性”
3.1 NFS v3 为什么在嵌入式世界里这么吃香
NFS v3 出来到今天已经有二十多年，但它在嵌入式 Linux 开发里依然是绝对的王者。为什么？因为简单、够用、内核原生支持。局域网内开发 RK3568、全志、树莓派这类板子时，最常见的调试流程就是让板子不烧写根文件系统，而是通过 NFS 直接从主机挂载 rootfs，改完代码立即生效，省去反复打包烧录的功夫。这背后依赖的是内核内置的 NFS 客户端，不需要在板子上跑额外的服务，也不依赖 Samba 那套用户态组件，资源开销非常小。
NFS v3 的无状态特性也是嵌入式场景的“保命符”。开发板上电、断网、强制重启，挂载的 NFS 连接可能瞬间失效，但重新挂载或重试后就能恢复，服务器端不会因为客户端异常崩溃而残留锁状态。配合 no_root_squash 这个导出参数，开发板上的 root 用户就能像操作本地目录一样直接读写根文件系统，权限问题少很多。这也是为什么热词里“rk3568 nfs 根文件系统”“嵌入式 linux 根文件系统挂载 使用 nfs v3”会扎堆出现：因为 V3 版本在嵌入式交叉编译工具链、老内核和 U-Boot 环境里兼容性最好，资料也最全。
3.2 NFS v4 带来什么：安全、锁与状态的回归
NFS v4 和前面几个版本最大的不同是“有状态”。它把文件锁、挂载协议、安全机制全整合进了协议本身，不再依赖独立的 rpc.mountd 和 NLM（Network Lock Manager），还引入了 COMPOUND 复合流程，一次 RPC 里能干更多事情，高延迟链路上的效率比 v3 显著提升。RPCSEC_GSS 安全层允许通过 Kerberos 做认证，这是 NFS 从“局域网信任模式”走向“安全可信模式”的关键一步。
听起来很美，但为什么很多人还是不敢在嵌入式环境直接上 NFS v4？原因在于 v4 引入了“状态”和锁语义，客户端异常退出后需要回收锁状态，这个过程一旦出问题，挂载点可能永久等待。嵌入式开发场景里板子经常硬断电、重启，NFS v4 的状态恢复反而容易变成新的故障源。所以我个人的经验是：纯生产环境的 Linux 服务器之间共享存储，NFS v4 值得用；开发调试、板子供根文件系统这种“怎么糙怎么来”的场景，老老实实用 NFS v3 反而更省心。
3.3 NFS 的性能特性：速度、缓存与高并发
NFS 的底层性能底子其实相当能打。因为它直接走内核 RPC 路径，没有 SMB 那套复杂的会话管理，顺序大文件读写往往比 SMB 更有优势。尤其是在 Linux 到 Linux 的纯内网环境里，nfsstat 看过去，吞吐量数据通常很好看。不过 NFS 也有自己的“性格”：它对网络抖动比较敏感，hard 挂载配合网络断开会让进程卡在不可中断的 D 状态，这是 Linux 里比较经典的问题；而 soft 挂载虽然不会卡死进程，但超时后会导致 I/O 错误，对数据库这类应用就是灾难。
缓存机制也是双刃剑。NFS 依靠内核 page cache 做读写缓存，读性能非常好，但写缓存配合 async 导出参数虽然快，掉电或服务器崩溃却可能丢数据；sync 保证数据落盘的可靠性，但性能会打折。这个选择没有标准答案，取决于你的数据重要程度和存储设备的可靠性。
4. 场景对照：什么时候闭眼选 SMB，什么时候闭眼选 NFS
4.1 家用 NAS、办公与多系统混合：拿 SMB 就够了
如果你要服务的主要对象是“人”，而不是“服务器”，SMB 是几乎没有悬念的选择。家里一台群晖或者自组 NAS，要共享给 Windows 笔记本、MacBook、安卓手机和平板，SMB 客户端遍布所有平台，几乎没有设备缺席。办公场景里需要给不同部门/同事分别设置读写权限，SMB 的思路也更贴近日常操作。
很多人喜欢问“Windows 挂 Linux 共享用什么”，我基本只推荐 SMB。虽然 Windows 也自带 NFS 客户端，但那个实现始终有点“异类”，文件名编码、符号链接、权限映射时不时出现诡异问题，日常使用体验远不如 SMB。反过来，Linux 挂载 Windows 共享用 mount -t cifs //server/share /mnt -o username=xxx，配合 vers=3.0 和 credentials=/etc/cred，稳定性相当不错。所以说，只要场景里有 Windows 或者移动设备，SMB 都是稳妥的起点。
4.2 Linux 集群、虚拟化与容器：NFS 的主场
换到“机器服务机器”的场合，NFS 就开始展露优势。虚拟机平台像 Proxmox VE、VMware ESXi 都支持把 NFS 当作共享存储，多个宿主机挂载同一个 NFS 导出的存储池，虚拟机磁盘文件可以 live migration。容器场景里的 Kubernetes 也常用 NFS 提供 ReadWriteMany 的 PV，让多个 Pod 同时读写同一个持久化目录。这些场景的共同点是：客户端全是 Linux 内核、对性能有要求、需要长时间稳定运行，NFS 的低开销和成熟度正好合适。
有人会问“为什么不用 SMB 做服务器共享存储”？技术上 SMB 3.0 加 SMB Direct 完全可以支撑工作负载，Windows 故障转移集群里就这么干。但一旦脱离 Windows 生态，问题就来了：Linux 上跑 Samba 很难完整复刻微软 SMB 的多通道和 RDMA 特性，故障排查也更复杂；而 NFS 是内核原生实现，工具链出身干净，对于互联网公司的海量 Linux 服务器来说，可维护性高得多。这也是为什么 Linux 生态里 NFS 始终是主流水道。
4.3 嵌入式开发板挂载根文件系统：为什么非 NFS 不可
针对热词里反复出现的“rk3568 nfs 根文件系统”和“嵌入式 linux 根文件系统挂载 使用 nfs v3”，这里单独解释。嵌入式开发最难受的就是反复烧写 flash，动辄几分钟甚至十几分钟，而 NFS 把整块 rootfs 放在开发主机上，板子通过网络挂载启动，文件改完立即生效。U-Boot 启动参数里加一句 root=/dev/nfs nfsroot=192.168.1.10:/srv/nfs/rootfs rw nfsvers=3 ip=dhcp，内核就会自动解析并挂载。
为什么不用 SMB 做同样的事？因为嵌入式 Linux 跑 SMB 客户端只能靠用户态工具（比如 smbclient 或内核 CIFS 模块），不仅配置繁琐，而且挂载根文件系统这件事发生在内核早期启动阶段，用户态工具根本来不及介入。而 NFS 客户端直接编进内核，U-Boot 传参后内核原生支持，流程天然闭环。再叠加 v3 无状态、no_root_squash 的权限宽松特性，嵌入式调试它就是不二之选。
4.4 决策速查：一张表看懂适用场景
| 维度 | 优先选 SMB | 优先选 NFS |
|---|---|---|
| 主要使用者 | 个人用户、Windows、Mac、手机 | Linux 服务器、嵌入式板卡 |
| 权限模型 | 用户级认证、ACL、域集成 | 主机/网络信任，root squash 控制 |
| 安全性需求 | 高，支持加密和 Kerberos | 默认弱，v4 后可上 krb5p |
| 性能追求 | 中规中矩，加密后开销明显 | 内核路径快，大文件吞吐有好底子 |
| 嵌入式调试 | 不推荐 | 默认方案，v3 最稳 |
| 容器/虚拟化存储 | 少见 | 主流方案之一 |
| 跨平台家庭共享 | 无脑选它 | 除非是用来喂 Linux 服务器 |
记住这条思路就行：服务“人”选 SMB，服务“内核”选 NFS。当你的客户端是用户桌面，SMB 省心；当你的客户端是另一个系统内核，NFS 高效。
5. 实操：服务端/客户端搭建与挂载要点
5.1 Ubuntu 上搭建 NFS 服务端，几行命令搞定
很多热词都在问“nfs 怎么开启”，这里以 Ubuntu 22.04/24.04 为例，完整跑通一遍。首先安装服务器包，名字不要弄混：
bash复制sudo apt update
sudo apt install -y nfs-kernel-server
然后创建一个共享目录并授予适当的属主：
bash复制sudo mkdir -p /srv/nfs/share
sudo chown nobody:nogroup /srv/nfs/share
sudo chmod 755 /srv/nfs/share
真正核心的是编辑 /etc/exports，这个文件决定了谁可以挂载、挂载后什么权限。举个例子：
bash复制/srv/nfs/share 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
rw表示可读写，ro就是只读。sync表示数据先落盘再响应，安全性好；async速度快一些，但掉电可能丢数据，新手建议先用 sync。no_root_squash允许客户端的 root 用户保留 root 权限。嵌入式调试场景几乎是必须的，但普通共享建议不用它，改回默认的root_squash更安全。no_subtree_check可以减少文件系统变更时的导出检查开销，像/srv/nfs/share这种独立目录直接加上没毛病。
编辑完之后执行：
bash复制sudo exportfs -rav
sudo systemctl restart nfs-server
确认导出是否成功：
bash复制showmount -e localhost
如果本机都看不到导出，那多半是 exports 语法或者权限范围写错了；如果服务跑不起来，用 journalctl -u nfs-server 查日志。另外别忘防火墙：NFS 涉及 2049 端口和 rpcbind（111），以及 mountd 的随机端口。最省事的调试办法是先在无防火墙或内网环境跑通，再收紧规则。
5.2 客户端挂载与开机自动挂载
Linux 客户端需要先装工具包：
bash复制sudo apt install -y nfs-common
手动挂载的写法：
bash复制sudo mount -t nfs 192.168.1.10:/srv/nfs/share /mnt/nfs
这是默认 NFSv4 挂载。如果想强制 v3，就用：
bash复制sudo mount -t nfs 192.168.1.10:/srv/nfs/share /mnt/nfs -o nfsvers=3,tcp
嵌入式开发场景建议加上 noatime 减少读元数据带来的写操作，hard 表示网络恢复后自动重试而不是报 I/O 错误。不过要记住 hard 可能造成进程 D 状态，权衡之后再决定。开机自动挂载就写进 /etc/fstab：
bash复制192.168.1.10:/srv/nfs/share /mnt/nfs nfs defaults,noatime,nfsvers=3,tcp 0 0
挂载之后可以用 df -h 和 mount | grep nfs 确认状态。频繁切换网络的环境不建议写 fstab，开机时服务器不在线会导致启动卡顿，那种情况用 autofs 按需挂载更舒服。
5.3 RK3568 嵌入式开发板挂载 NFS 根文件系统实战
如果你拿的是 RK3568 这类 Linux 开发板，根文件系统挂载 NFS 的完整套路先按五步走：
第一步：准备 rootfs 目录
把交叉编译好的根文件系统或某个发行版镜像解压到开发主机的 /srv/nfs/rootfs，比如：
bash复制sudo mkdir -p /srv/nfs/rootfs
sudo tar -xzf ubuntu-rootfs.tar.gz -C /srv/nfs/rootfs
第二步：配置 exports
/srv/nfs/rootfs 的导出项里一定要写 no_root_squash，否则板子的 root 用户会被降权，很多系统初始化操作会失败：
bash复制/srv/nfs/rootfs *(rw,sync,no_subtree_check,no_root_squash)
这里的 * 表示允许任意客户端 IP，开发环境图省事可以这样用，生产环境务必收紧网段。
第三步：确认内核支持
开发板 Linux 内核需要打开 CONFIG_NFS_FS、CONFIG_NFS_V3、CONFIG_ROOT_NFS 这些选项，SDK 默认配置一般都有。如果编译内核时没勾选，板子启动会卡在 VFS: Unable to mount root fs。这个步骤很容易被忽略，但确实是很多新手卡壳的地方。
第四步：修改 U-Boot 启动参数
在 U-Boot 或 extlinux.conf 里把 bootargs 改成类似这样：
bash复制root=/dev/nfs nfsroot=192.168.1.10:/srv/nfs/rootfs rw nfsvers=3 ip=dhcp
root=/dev/nfs 是让内核走 NFS 根文件系统逻辑的“暗号”，后面 nfsroot= 指定服务端 IP、导出路径。ip=dhcp 表示板子启动时动态获取 IP，如果你习惯静态地址，就写 ip=192.168.1.50:192.168.1.10::255.255.255.0::eth0:off 这种完整格式。
第五步：验证
板子起来后用 mount 命令看根目录挂载信息，应该能看到 192.168.1.10:/srv/nfs/rootfs 挂在 / 上。整个流程跑通一次，后面开发效率会起飞：改完 rootfs 里任何文件，板子上立刻生效，省掉烧写等待时间。
5.4 Termux 与手机场景下的小型 SMB 共享
顺手聊一下热词里“termux smb”的场景。很多人想在安卓手机上通过 Termux 访问电脑共享目录，最常见的是这两条路：一是安装 SMB 客户端工具，二是用文件管理器直接连。
Termux 里装 samba 工具包后，可以用命令行访问：
bash复制pkg install samba
smbclient //192.168.1.100/share -U username
进去之后就是 ls、get、put 这一套命令，适合脚本化操作或临时拉文件。不过日常更推荐直接换用支持 SMB 的安卓文件管理器（比如 Solid Explorer、Mixplorer），图形界面输入地址、账号、密码，一次保存就能随时访问。Termux 的优势是把 SMB 访问写进脚本，比如定时拉取 NAS 上的数据备份，这在纯命令行的自动化环境里很有用。
还有个容易踩的坑是手机和电脑不在同一网段，比如电脑在公司内网、手机连着热点，SMB 广播和 IP 路由都走不通。先确认两边能互相 ping 通，再谈协议和凭据问题，这是所有共享访问的第一前置条件。
6. 常见故障排查心得
6.1 SMB 共享访问失败：别一上来就怀疑协议
碰到“共享文件夹访问失败”这个问题，很多人第一反应是去查 SMB 协议，也确实经常能发现服务器把 SMB1 关了、客户端又默认只发 SMB1，导致版本协商失败。但根据我的经验，真正高频的原因其实是防火墙拦截、凭据过期、共享权限和 NTFS 权限不一致，协议版本反而不是大头。比较典型的排查顺序是：先确认网络通了，再看服务端口（445 或 139），然后验证账号凭据，最后才去抓协议细节。
Linux 上排查 Samba 内网共享，可以用：
bash复制smbclient -L //192.168.1.100 -U user
能看到共享列表就说明端口、认证基本没问题。服务器端用 testparm 检查 Samba 配置，smbstatus 查看当前连接状态。Windows 那端查看事件日志里的网络访问错误，通常能定位到是密码错误还是权限不足。协议层面要尝试验证的话，Windows 上在 cmd 里跑：
bash复制net use \\192.168.1.100\share /user:user pass
或者直接查看已建立的 SMB 连接状态：
bash复制Get-SmbConnection
Linux 挂载 CIFS 时建议显式指定协议版本：
bash复制sudo mount -t cifs //192.168.1.100/share /mnt/smb -o username=user,password=pass,vers=3.0
显式指定 vers=3.0 能避开很多版本协商坑。顺便说个常见误区：很多人觉得 SMB 访问慢是共享协议不行，实际上多半是服务器端磁盘读写慢或者千兆网线降级到了百兆，先查物理链路再谈协议。
6.2 NFS 挂载卡死、权限拒绝与 rpc 排查
NFS 的故障图谱和 SMB 不太一样，常见有三类：
第一类是挂载权限被拒。mount.nfs: access denied by server while mounting 这条报错通常是因为客户端 IP 不在 exports 允许列表里，或者参数里写了 root_squash 导致 root 权限被压掉。先在服务端执行 exportfs -v 查看实际导出参数，再检查 exports 行写的网段到底对不对。用 showmount -e 服务端IP 也能直接看到允许导出的目录。
第二类是挂载后卡死。大部分是服务端离线或网络中断，配合 hard 挂载，进程在等 NFS 响应时进入不可中断睡眠。临时恢复办法是赶紧修好网络，或者用 umount -f 强制卸载；长期用建议评估网络环境，如果弱网环境比较多，考虑 soft,intr 参数组合，不过要接受 I/O 错误的风险。看是否卡死可以用 ps -ef | grep D 查 D 状态进程。
第三类是“看起来挂上了但写不进去”。这种绝大多数是权限和属主问题，常见于嵌入式开发：rootfs 里的文件属主是手机电脑上的用户 UID，跟板子上进程的 UID 对不上。建议调试阶段直接在 exports 里用 no_root_squash，再配合目录权限 chmod 777 或把属主改成 nobody，能少很多神烦问题。
NFS 服务端的服务栈依赖 rpcbind、nfsd、mountd 一堆服务，排查时常看：
bash复制rpcinfo -p 服务端IP
systemctl status nfs-server
journalctl -u nfs-server -f
其中 rpcinfo 能看到 rpcbind 是否注册了 nfs（版本 3/4）和 mountd 服务，缺了哪个就说明对应服务没起来。跑通一次之后你会发现，NFS 排障只要把“网络可达、导出正确、权限到位、服务注册”这四件事理顺，绝大多数问题都会迎刃而解。
6.3 协议选型与运维的几条个人经验
踩过这么多坑，我沉淀了几条自己的处理原则。第一，能用 SMB 解决的日常共享不要硬上 NFS，比如“我要让办公室所有人访问一个目录”这种情况，用 SMB 能省掉后续一堆“为什么 Windows 挂不上”的疑问；第二，纯 Linux 服务和嵌入式调试优先 NFS，性能和维护成本都占优；第三，如果有 Windows 域环境、要求高度集成认证，那就别折腾开源方案，老实买商业 NAS 或者 Windows Server，微软自家 SMB 实现最省心。
另外还要提醒一点，不管是 SMB 还是 NFS，协议选型只是第一步，后续的版本选择、权限规划、备份策略才是大头。特别是“版本”，每次看到有人还在内部网络偷偷开着 SMB1，我都有点捏把汗；NFS 方面，能上 v4 的正式环境就不要纠结 v3，但嵌入式调试除外。顺带，如果你想在开源的 Linux 存储组合里找平衡，也可以考虑 NFS 做内核级共享、SMB 做终端用户入口的混合架构，前面用户友好、后面性能高效，两头都不耽误。
我个人在实际操作中的体会是：共享存储这件事，很少有一劳永逸的标准答案，关键在于想清楚“谁在用”和“用来干嘛”。家里 NAS 给全家老少共享影片照片，SMB 是最低摩擦的路径；调试一块 RK3568 开发板或者给几台 Linux 服务器做共享存储，NFS v3 或 v4 各有各的舞台。真到了报错那一刻，也不必慌，按照网络、服务、权限、协议的顺序一层层排查，大多数问题其实都藏在最简单的环节里。最后再分享一个小技巧：每次改完 exports 或 Samba 配置，先把服务端状态和 showmount/smbclient -L 的结果确认一遍，再去客户端挂载，能帮你把“配置时的问题”和“连接时的问题”干净地分开，少走不少弯路。