nfs 、smb不要混用，推荐linux使用nfs ，windows使用smb

遇到个case，挂nfs协议的cfs在win10上使用，业务每15分钟会remount一次

专门抓包看了下，如下面两张图，在12:51:35写操作之后就没有再发起write call，中间有尝试连接445端口，并且发起了remount export call ；从端口51646看，remount后，TCP连接没有断，而remount之前有smb请求被rst，rst后才remount的，remount后过10秒多业务就恢复正常写操作了（这里篇幅所限，只展示了一次remount，其实每次remount都是这个特征）

客户端机器是域成员机，业务不变的情况下，如果用smb协议的cfs，没有15分钟remount一次cfs的问题，用nfs协议的则会每15分钟remount一次cfs。微软论坛搜到1篇帖子，描述的问题好像一样，但是没有解决方案

https://social.technet.microsoft.com/Forums/en-US/eca1fa69-a9da-4908-81df-532f4e15e140/windows-server-as-nfs-client-remount-issue?forum=winserverfiles

nfs server没有445端口，结合抓包，发现客户端会请求445端口，这很奇怪。确认只用smb协议的cfs没问题。我查了资料，一般建议linux客户端用nfs协议的存储、windows客户端用smb协议的存储，混合协议可能会有问题。所以，我先关闭这台机器的smb client（即关闭 LanmanWorkstation 服务）或者参考https://docs.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3 关闭客户端的smb协议试试。

LanmanWorkstation这个服务默认是开机启动的，设置为开机禁止启动，重启机器后验证业务正常了。

后来想着既然是请求445造成的，那能不能在防火墙上阻止出向445端口的流量，试了下，不行，加不加这个防火墙规则，结果都是一样，看来出现问题并不是流量出去了，而是因为产生了445端口的出向请求，这才是关键。

添加防火墙规则的命令：

netsh advfirewall firewall add rule name=block445 protocol=TCP dir=out remoteport=445 action=block remoteip=cfsIP profile=any

例如：

netsh advfirewall firewall add rule name=block445 protocol=TCP dir=out remoteport=445 action=block remoteip=10.255.4.21 profile=any

netsh advfirewall set allprofiles state on

如此看来，只有一个办法，那就是禁止smb client，让它发不了455请求，即禁止LanmanWorkstation服务或禁止smb协议。得到这个方案，完全是从这里突破的：nfs server没有445端口，结合抓包，发现客户端会请求445端口，这很奇怪。所以关闭smb client （LanmanWorkstation服务）来验证nfs协议的cfs不夹杂445请求 是否能正常，验证正常。但为了nfs协议的cfs能在这个业务场景的使用，要禁掉smb client未免有点因噎废食了。最好的方案还是使用cifs/smb协议的cfs，毕竟smb是windows原生的，兼容性是最好的。

推荐linux 使用nfs ，windows 使用smb

NFS 和 SMB 都是经过实战考验的通过网络共享数据的解决方案。虽然 NFS 在基于 Linux 的环境中最容易使用，而 SMB 在 Windows 上最简单，但这两种协议都可以在任何主流操作系统上运行。尽管如此，重要的是要考虑与这两种协议相关的潜在配置和兼容性挑战，并评估商业文件共享平台是否是更好的选择。

NFS 与 SMB：网络文件共享速成课程

https://www.writeclick.co.il/nfs-vs-smb-a-crash-course-on-network-file-sharing/

网络共享：NFS 和 SMB 之间的性能差异

https://ferhatakgun.com/network-share-performance-differences-between-nfs-smb/