WindowsNFSクライアントがまだ接続する理由TCP 139＆445？
Windows10とWindowsServer 2016をNFSクライアントとしてセットアップし、-anonオプションを使用して外部ストレージアレイからNFS共有をマウントしました。 99％の遅延があり、その後終了する場合があります。 Wiresharkから、データの転送に2049（NFS）を使用したにもかかわらず、クライアントがポート139（NETBIOS）および445（SMB/CIFS）に接続しようとしたが、外部ストレージがポートをリッスンしなかったため、拒否されたことがわかります。遅延を引き起こしました。私の質問は、なぜそれが2049以外にTCP 139と445を使用するのですか？
そうではありません。私がこの遅延を見たほとんどの場合、それはアプリケーション（共有にアクセスするアプリ）の障害です。 Windowsは共有をドライブにマップするだけですが、lotのアプリが古き良きUNCの方法で共有にアクセスしようとします。これにより、CIFSクライアントが最初に共有を試行します。
たとえば、Word（2010）は、ファイルを（任意に）R：\に保存しませんが、\ server\ressourceに保存します。これは、ファイルをデバッグし、UNC参照（「最後の印刷設定」または「tmpファイルの削除」など）を検索するときに確認できます。これらはすべてUNC参照を指します。このレガシー動作がどこから来ているのかわかりませんが、これを行うアプリは主にwin32APIを使用します。
NFSクライアント自体はこの動作を示していないか、再現できませんでした。