I was reading some old emails and I'd like to share one more case that I worked. It was an interesting case where we have 2 scenario and 2 separates solution. Unfortunately one hasn’t solution found.
We have a Windows Server running 'Client for NFS' (Windows 2K8R2 SP1) and a File Server running UNIX OS (NFS). When some user log onto Windows Server the end user needs to map the Unix File Shared using one letter. When that end user select the option for map an UNIX NFS server with the "Reconnect at logon" the message below is displayed if tries use the mapped drive letter after logoff/logon is done.
"Z:\ is not accessible. The filename, directory name, or volume label syntax is incorrect".
Actions and Solution PART I=======================
- First action is use the article KB2025723 to review the Security Option.
- Client for NFS on Windows 2008 R2 does not work properly
- The resolution is to select only “sys” option and reboot the system.
- After that you should deploy the KB2485529 to fix the error message "Z:\ is not accessible. The filename, directory name, or volume label syntax is incorrect" and for best practices update the Windows Server with the KB2580164.
- Now we have fix the error message and the drive Z:\ can be accessible.
- Now the interesting part ... After logoff and logon the mapped drivers (Z:) is working however just if we click again in Explorer Window on the drive letter Z:\
- Now we see after logon the driver letter is being displayed with Red Cross. "X"
- Event Viewer
Event 16397, NfsClnt
Windows(R) Lightweight DirectoryAccess Protocol (LDAP) failed a request to connect to Active Directory Domain Services(R) for Windows user< BLABLA\XYZ.ABC>.
Without the corresponding UNIX identity of the Windows user, the user cannot access Network File System (NFS) shared resources.
Verify that the Windows user is in Active Directory Domain Services and has access permissions.
- Found the article blog "Getting Red X sign on mounted NFS volume from Windows client " - http://blogs.technet.com/b/sfu/archive/2011/09/20/getting-red-x-sign-on-mounted-nfs-volume-from-windows-client.aspx
Windows NFS client is known not to handle multiple path NFS shares. The issue is by design and comes when the client is mounting an NFS share which is more than 26 characters in length.
Users would be able to access the NFS shares after mounting it to a drive letter but a red X (disconnected) sign would be there on the mounted volume. The NFS mounted drives will be in connected state even if UI shows disconnect.
The recommendation would be to have a single path nfs share like “\\servername\sharename” or a multipath NFS share having less than 25 characters.
- In that case the number of characters was 20.
- No more actions to do. This is by design.
Solution PART II==============
NFS share are session specific and are not persistent mount. Even if we check the persistent mapping option while doing a Map network driver or put the parameter persistent=yes with the mount command.
Unlike CIFS shares where the drive mapping is persistent, NFS is not. So once the user logs off and logs back in, he will see the disconnected sign on the drive. The same observation would be there, if he runs the mount command from the cmd.
This is a known behavior.
Hope it helps!