Среда: локальная частная сеть, клиенты Windows Server 2016 NFS, сервер CentOS 7 NFS nfsd (который, похоже, не является источником проблемы).
Ситуация: несколько хостов Windows подключены к общему ресурсу, размещенному на хосте Linux, через NFS. С самим доступом все в порядке, но в случае отсутствия запросов к смонтированному диску со стороны Windows, последующий (или первый после перезагрузки ОС Windows) доступ к смонтированному тому по NFS приводит к попытке Windows подключиться к хосту по SMB (TCP-порт 445, обнаруженный в Wireshark)! Ресурс явно монтируется через NFS-клиент, почему *** винда пытается сначала зайти туда по SMB? Хост, естественно, возвращает отказ ICMP, Windows пытается снова через 3 секунды, затем еще через 6, затем ждет еще немного (12 секунд, всего 21 секунда), прежде чем, НАКОНЕЦ, попытаться выполнить команду NFS READDIRPLUS, которая, конечно, работает отлично.Последующие запросы поступают прямо к NFS, но меня больше озадачивает то, что перед тем, как я попытаюсь открыть подключенный диск, я сначала открываю «Этот компьютер», и Wireshark отображает правильные запросы NFS типа FSSTAT для определения размера тома. ПОЧЕМУ тогда Windows игнорирует провайдера монтирования и все еще пытается использовать LanmanWorkstation?
Я также попытался решить проблему, изменив порядок привязки сетевого протокола, чтобы сначала перечислить NFS, затем RDP, затем SMB, и проверил перезапуск хоста Windows - без игры в кости, самый первый запрос к содержимому тома по-прежнему выполняется через неудачную процедуру подключения SMB, указанную выше. . До сих пор я обходил проблему, открывая 445/tcp на хосте Linux (убедившись, что там ничего не прослушивается), чтобы Windows получала пакеты с пометкой RST, указывающие на «нет обслуживания» вместо «тайм-аут», поскольку, по-видимому, она не может понять отклонение ICMP. , вместо этого сокращая начальное время для получения списка каталогов до 1,2 с, но все же ... Как я могу заставить Windows даже не пытаться подключить этот ресурс через SMB?
