企业官网建设流程全解析

NFS和SMB不要混用，这句话我在好几个生产环境里摔过跟头之后才真正听懂。今天把这段经历掰开揉碎聊一聊，希望你能少交点学费。

先说结论：SMB适合Windows客户端访问，NFS适合Linux/Unix客户端访问，同一个共享目录同时通过NFS和SMB暴露，短期用着没毛病，长期跑下来全是坑。这篇文章会从协议原理、混用踩坑实录、正确的分包方案、以及问题排查技巧几个角度完整讲清楚，运维、开发、自建NAS的玩家都能直接参考。

1. 为什么会有“不要混用”这个结论

1.1 先搞懂NFS和SMB各自的“性格”

NFS（Network File System）是Sun公司在1984年搞出来的，一开始就是为Unix到Unix的文件共享设计的。它天然继承了Unix文件系统的各种特性，比如inode、权限位（rwx）、uid/gid映射，甚至文件锁都跟POSIX的语义深度绑定。你在一台Linux服务器上挂载NFS，本地文件系统长什么样，挂载后就是什么样，几乎无感知。

SMB（Server Message Block）最早是IBM在1983年提出的，后来微软把它发扬光大，成了Windows网络共享的事实标准。SMB协议从设计之初就考虑PC场景，它带着Windows注册表、NTFS ACL、文件流（ADS）这些Windows特有的概念。Windows机器访问SMB共享，跟你访问本地C盘没有本质区别，完全无缝。

这两个协议没有谁绝对更好，它们只是“原生适配”各自生态。问题就出在：很多人一台NAS或者服务器同时开NFS和SMB服务，同一个目录共享给混合环境的客户端，然后就开始踩坑。

1.2 混用的本质问题：一台服务器要同时跟两套协议打交道

当一个共享目录同时通过NFS和SMB暴露时，服务器端要做大量转换工作。NFS请求进来，内核直接按Unix语义处理；SMB请求进来，Samba（或Windows Server）要把Windows语义翻译成Unix语义，再落到本地文件系统。

关键问题出现在文件锁、权限映射和缓存一致性这三个点。SMB客户端加锁时用的是Windows的锁语义，NFS客户端加锁时用的是POSIX锁语义，两个锁在服务器端如果不做协调，就会出现A客户端明明锁住了文件，B客户端照样能写进去的诡异情况。我见过好几次多人协作时文件互相覆盖，最后查出来就是锁语义冲突。

再比如权限。NFS默认按uid/gid直接映射，你服务器上有个用户uid=1000，客户端Linux上只要是uid=1000的用户，天然就当作同一个用户。SMB则要经过Samba的user映射配置，搞不好同一台机器的同一个共享，Linux用户创建的目录，Windows用户进不去，或者进去后没有写权限。

注意：这不是NFS或SMB本身有bug，而是两套协议在同一个共享资源上交替工作时，服务器端要做超过它预期的兼容性适配。绝大多数混用问题都属于这种“契约不一致”的范畴。

1.3 什么时候可以“临时妥协”，什么时候千万别混

如果只是家里NAS，两台设备一个Linux一个Windows，图省事混用了，最多就是偶尔文件权限不对，改一改还行。但生产环境我强烈建议别这么干，尤其是以下场景：

• 多用户并发读写同一批文件（比如开发团队共享代码目录、CI构建产物、数据库备份目录）
• 对文件锁有严格要求（比如数据库文件直接放在网络共享上）
• 有大量小文件读写（比如代码仓库、静态资源目录）
• 需要稳定权限控制（比如审计要求、多租户隔离）

这些场景只要混用，大概率出问题。相反，如果只是单向地把文件从Windows传到Linux，或者偶尔从Linux往Windows共享扔个文件，那混用不混用无所谓。

2. 混用踩坑实录：我真实遇到过的问题

2.1 权限和文件所有者一团乱

这是我最早踩的坑。一台Ubuntu服务器，装了NFS和Samba，同一个共享目录/media/nas/team。Linux客户端用NFS挂载，Windows客户端用SMB访问。

Linux客户端创建的文件，owner显示是uid=1001。Windows客户端在SMB里看到的owner是“UNIX USER\1001”，能不能删改取决于Samba配置，默认情况下经常没法删。反过来，Windows客户端创建的文件，在Linux上owner显示成root或nobody，然后Linux用户在NFS里根本没法写。

更麻烦的是，Windows会把NTFS ACL写进文件扩展属性（user.NTACL），这些扩展属性在NFS客户端上完全不可见、不可控，但是又真实存在。一旦某个文件的ACL在没有GUI的情况下出错，你只能在命令行里抓瞎。

2.2 文件锁和并发写入的诡异失败

有一次在跑一个基于文件的同步任务，两个Linux客户端同时从NFS读写，一个Windows客户端通过SMB往里扔文件。结果Windows端报“文件被占用”，但Linux端明明没有进程打开那个文件。

查了很久，发现是Samba的锁映射和NFS的锁机制互相干扰。NFSv4的锁状态由内核管理，SMB锁得通过Samba进程处理，两边默认没有做协调。Windows端锁上的文件，NFS端完全感知不到。这类问题如果不看协议层日志，光看应用层，完全无从下手。

2.3 大小写敏感问题：文件“消失”了

还有一次，一个同事用Windows向共享目录上传了一个Readme.MD，Linux侧原本已经有一个README.md。Windows上看起来是上传成功，Linux客户端一刷新目录，发现文件还在，但是内容被覆盖了。

在Windows的NTFS文件系统里，文件名不区分大小写；在Linux的ext4/xfs里，文件名严格区分大小写。同一个共享目录同时支持两种语义，服务器端默认只能按Linux的语义来，Windows上传的Readme.MD和README.md被视为同一个文件，直接静默覆盖。这种问题一旦出现，数据丢失了都不一定有日志。

2.4 性能落差：小文件场景直接崩溃

我们曾经在一个共享目录上跑前端构建任务，构建机是Linux，NFS挂载，构建产物是几千个小文件。同一时刻有几个Windows同事在浏览这个目录，结果NFS客户端的读取速度慢得离谱。

后来分析原因，SMB客户端浏览目录时，会频繁查询目录元数据、缩略图、ACL等，这会让服务器端的Samba进程产生大量inotify事件和元数据读取，挤占了NFS请求的处理能力。两套协议在同一个存储池上抢I/O，性能互相拖累，最后谁都不快。

3. 正确分包实践：Linux用NFS、Windows用SMB

3.1 Linux侧：NFS服务端配置实操

以Ubuntu/Debian为例，先装NFS服务端：

apt update apt install nfs-kernel-server -y

编辑/etc/exports，把需要共享的目录按实际网段和需求开放。我的经验是永远不要写*，一定要限定网段或IP，否则容易出安全问题。

/data/nfs 192.168.1.0/24(rw,sync,no_subtree_check,insecure,fsid=0)

关键参数解释：

• rw：读写挂载。
• sync：写入同步，防止异常掉电丢数据。追求性能可以换async，但生产环境我建议保持sync。
• no_subtree_check：避免目录重命名时的部分检查，提升稳定性。
• insecure：允许客户端使用非保留端口挂载，很多现代客户端需要这个，否则挂载失败。
• fsid=0：如果要做NFSv4根目录，建议设置。

改完配置后：

exportfs -ra systemctl restart nfs-kernel-server

Linux客户端挂载：

mount -t nfs4 192.168.1.100:/ /mnt/data -o rw,vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2

注意挂载参数里的rsize和wsize，默认值可能偏低。设置成1MB在千兆网络下实测性能更好。hard表示网络抖动时客户端不会静默失败，而是持续重试，配合timeo=600（60秒超时）能有效避免NFS挂起后自动断连的问题。

3.2 Windows侧：SMB共享配置实操

Windows之间共享SMB最简单的方法是直接用Windows自带的文件共享功能。在文件夹属性里选“共享”，添加需要授权的用户，设置读取/写入权限即可。

但更常见的是Linux服务器上启用Samba来模拟SMB服务端，Windows客户端直接访问\\192.168.1.100\share。Samba配置的核心在/etc/samba/smb.conf。我的推荐配置：

[global] workgroup = WORKGROUP server min protocol = SMB2 server max protocol = SMB3 log file = /var/log/samba/log.%m max log size = 1000 security = user passdb backend = tdbsam [share] path = /data/share valid users = @smbgroup read only = no browseable = yes create mask = 0664 directory mask = 0775 force create mode = 0664 force directory mode = 0775

其中server min protocol和server max protocol很关键。旧设备如果只支持SMB1，建议单独开兼容，但能用SMB2/3就坚决用新的，性能和安全都更好。

Samba用户和Linux系统用户是两套账密体系，需要单独添加：

groupadd smbgroup useradd -M -s /sbin/nologin smbuser # 创建无登录shell的用户 usermod -a -G smbgroup smbuser # 加入smb组 smbpasswd -a smbuser # 设置SMB密码（独立于系统密码）

Windows客户端访问时，在资源管理器输入\\服务器IP\share，用smbuser账户登录即可。

3.3 需要跨协议访问时怎么办：桥接方案

如果确实存在“同一批文件既要被Linux客户端批量读写，又要被Windows客户端用SMB访问”的硬需求，怎么办？

我的建议是：以NFS为主共享给Linux，然后单独开一个Samba专用共享目录，里面用rsync或inotify同步任务，把NFS上需要给Windows的文件定时/实时复制过去。

/data/nfs/ <---- Linux客户端通过NFS挂载 /data/smb_bridge/ <---- Windows客户端通过SMB访问 /data/nfs --> /data/smb_bridge/ 同步脚本（单向同步）

这样既避免两套协议直接操作同一批文件，又把混用的冲突限定在可控范围内。代价是多一份磁盘空间和同步延迟，但换来的是稳定性。

如果不想用同步方案，也可以考虑只做单向权限控制。比如NFS共享目录对Windows的SMB只开放只读权限，这样权限冲突的概率大大降低。但锁冲突和元数据竞争仍然存在，只能说“不会更糟”，不能说“没问题”。

4. 常见问题排查与性能调优实录

4.1 问题速查表

4.2 性能调优经验

NFS和SMB遇到性能问题时，别上来就怀疑协议本身，先排查网络和存储层。我最近一次调优，把NFS挂载的rsize/wsize从默认值调到1MB后，大文件读写速度直接翻倍。小文件场景则要看服务器的inode和元数据性能，建议把NFS共享目录放在SSD上，而不是机械盘。

SMB侧性能优化，重点在Samba配置。read raw = yes和write raw = yes在较新的Linux内核和Samba版本上默认开启，能启用大块读写，大幅减少小包交互。另外把socket options设置成TCP_NODELAY能降低传输延迟，实测对RTT较高的跨网段访问有明显改善。

[global] read raw = yes write raw = yes socket options = TCP_NODELAY use sendfile = yes

另外把Samba的日志级别调低（log level = 1），避免大量I/O日志拖慢服务端。

4.3 我走过的弯路和最终心得

最开始我在同一个共享目录上开着NFS和SMB，图省事。后来在一次团队协作中，两个同事一个Linux一个Windows，在同一批文件上操作了一个下午，结果文件owner全乱套、锁冲突频发，最后只能靠备份恢复数据。那次之后我才下了决心做协议拆分。

如果你现在正在评估要不要混用，我的建议是：
先问问自己，这批文件的主要消费者是Linux还是Windows？
如果主要消费者是Linux，就只开NFS，Windows偶尔要访问就临时用SFTP或者网页版文件管理器。
如果主要消费者是Windows，就只开SMB，Linux偶尔要访问就用cifs-utils挂载SMB共享，而不是反过来同时开NFS。

注意：一支Linux机器通过cifs挂载Windows共享是完全正常且推荐的做法，这不属于“混用”，因为共享目录协议的提供方只有SMB一个，只是客户端类型不同。

说到底，“NFS给Linux、SMB给Windows”这句话不是一句口号，而是把协议语义冲突降到最低的最优解。网络文件系统这个东西，稳定比功能多重要得多。分开跑，两边都稳；硬凑在一起，迟早有一天要付出代价。