Я установил свои Windows 10 и Windows Server 2016 в качестве клиента NFS и подключил общий ресурс NFS из внешнего массива хранения с параметром -anon. Иногда бывает задержка на 99%, а потом заканчивается. Из Wireshark я вижу, что хотя он использовал 2049 (NFS) для передачи данных, клиенты все еще пытались подключиться к порту 139 (NETBIOS) и 445 (SMB / CIFS), внешнее хранилище не прослушивало порты, поэтому оно отклонено и вызвал задержку. У меня вопрос, почему он все еще использует TCP 139 и 445 помимо 2049?
Это не так. Практически в любом случае я видел эту задержку, это ошибка приложения (приложения, которое обращается к общему ресурсу). Windows просто отображает общий ресурс на диск, но много приложений пытается получить доступ к нему старым-добрым UNC-способом, который запускает клиент CIFS, чтобы попробовать его первым.
Word (2010), например, не (добровольно) хранит файлы на R: \, например, а на \ server \ ressource. Вы можете увидеть это при отладке файла и поиске по ссылкам UNC (например, «последние параметры печати» или «удаление файла tmp»), все они будут указывать на ссылку UNC. Я не знаю, откуда взялся этот устаревший bahaviour, но приложения, делающие это, в основном используют Win32 API.
Сам NFS-клиент не демонстрирует такого поведения, или мне просто никогда не удавалось его воспроизвести.