我将 Windows 10 和 Windows Server 2016 设置为 NFS 客户端，并使用 -anon 选项从外部存储阵列挂载 NFS 共享。有时它会在 99% 时出现延迟，然后完成。从 Wireshark 中，我可以看到虽然它使用 2049（NFS）传输数据，但客户端仍尝试连接到端口 139（NETBIOS）和 445（SMB/CIFS），外部存储没有监听端口，因此它拒绝并导致延迟。我的问题是为什么除了 2049 之外它还使用 TCP 139 和 445？
答案1
不会。几乎在任何情况下，我看到这种延迟都是应用程序（访问共享的应用程序）的错误。Windows 只是将共享映射到驱动器，但很多应用程序尝试以传统的 UNC 方式访问它，这会触发 CIFS 客户端首先尝试它。
例如，Word (2010) 不会（自愿）将文件存储在 R:\ 上，而是存储在 \server\ressource 上。您可以在调试文件并搜索 UNC 引用（如“上次打印设置”或“临时文件删除”）时看到这一点，它们都将指向 UNC 引用。我不知道这种遗留行为从何而来，但这样做的应用程序大多使用 win32 API。
NFS 客户端本身不会显示此行为，或者我只是无法重现它。