Environment: Local private network, Windows Server 2016 NFS clients, CentOS 7 NFS server nfsd (which seems to not be the source of a problem).
Situation: Several Windows hosts are connected to a shared resource hosted on a Linux host via NFS. Access itself is OK, but in case there were no requests to the mounted drive from Windows side, subsequent (or first after a Windows OS restart) access to the NFS mounted volume results in Windows trying to connect to the host via SMB (TCP port 445, as detected in Wireshark)! The resource is explicitly mounted via NFS client, why the *** Windows tries to first access there with SMB? Host naturally returns a ICMP reject, Windows tries again after 3 seconds, then again after 6 more, then waits some more (12s, totaling 21s) before FINALLY trying with NFS READDIRPLUS command, which of course works perfectly. Subsequent requests do come up straight to NFS, but what puzzles me more, is that before I try to open a mounted drive I first open "This computer" and Wireshark displays correct NFS requests of type FSSTAT to determine volume size. WHY then Windows ignores the mounting provider and still tries using LanmanWorkstation?
I have also tried to remedy the problem by changing network protocol binding order to first list NFS then RDP then SMB, and verified by Windows host restart - no dice, the very first request to volume contents still goes via the failed SMB connection procedure listed above. So far I worked around the problem by opening 445/tcp on Linux host (ensuring nothing listens in there) so that Windows gets RST-flagged packets indicating "no service" instead of "timeout" as apparently it can't understand an ICMP reject, reducing the initial time to get directory list to 1.2s instead, but still... How can I make Windows to not even try connecting that resource via SMB?
