NFS mounts don't properly reconnnect at startup
I've setup NFS support in my installation of Windows 7 RC by adding Services for NFS and Subsystem for UNIX Based Applications as described here http://blogs.msdn.com/sfu/archive/2007/05/01/unix-interoperability-and-windows-vista.aspx. I also did the registry hack to modify the AnonymousUID and AnonymousGID as described here http://blogs.msdn.com/sfu/archive/2009/03/27/can-i-set-up-user-name-mapping-in-windows-vista.aspx so that I don't need to run an Active Directory server on my network (one UID/GID works fine for my purpose of mounting shares off of my Linux file server). The problem I'm having concerns drives that I've mounted and configured to reconnect on Windows startup. On startup, one of the drives appears connected, while the others appear unconnected (red X through them in the Explorer window). The drive that appears connected, really isn't, and you can't access it. When you click on it, you get an error 'The filename, directory name or volume label syntax is incorrect'. The other drives with the red x's can be accessed by clicking on them, after which they connect and work fine (files can be both read and written). The one that has the error can never be accessed. Depending on how many drives I map, one of them will always fail (not always the same mount point). In other words, if I have one drive mapped, it will fail with that error. Two drives mapped, one will fail, one won't. Three drives mapped, one out of three fails. I'm mapping the drives using the following syntax. 10.10.10.1:/mountpoint. If I have no drives mapped to start and mount three drives, all will be accessible until I reboot, at which point one will fail, and the other two will be disconnected until I visit them in the Explorer. I really think something is wonky with the NFS negotiation that occurs for that first drive as the system comes up. It fails in some way that can't be resolved by Windows and stays that way, while the others either don't get tried, or fail in some other way. Note that this entire NFS setup works fine from WindowsXP for two other computers on the same network (and this computer too, when I have it booted to XP), using the same mount syntax and SFU 3.5. Any ideas? Best regards, -Jim Heck
June 16th, 2009 5:40am

Jim Did you ever get any kind of answer on this. I am experiencing the same exact thing. Greg Hamilton
Free Windows Admin Tool Kit Click here and download it now
March 14th, 2011 6:08pm

I am also having the same issue. If anyone has a resolution to this problem, it would be greatly appreciated if they could share. The most annoying part about this is that you can't seem to remove or remount the mapping that fails.
March 24th, 2011 5:23am

A quick and dirty batch script for mount on startup (mount.bat under Startup folder) @echo off ECHO Checking connection, please wait... :TRYAGAIN PING -n 1 www.google.com | find "Reply from " >NUL IF NOT ERRORLEVEL 1 goto :SUCCESS IF ERRORLEVEL 1 goto :TRYAGAIN :SUCCESS C:\Windows\System32\mount.exe -u:USER -p:PASSWORD server:/share X:
Free Windows Admin Tool Kit Click here and download it now
June 8th, 2011 11:38pm

I am also having the same issue. If anyone has a resolution to this problem, it would be greatly appreciated if they could share. The most annoying part about this is that you can't seem to remove or remount the mapping that fails. For removing stale shares I did the following (after creating restore point); * deleted HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\{the share name that wouldn't go away} * deleted HKEY_CURRENT_USER\Network\{offending drive letter} * Restarted, and all was well
June 8th, 2011 11:54pm

I had further issues after applying SP1 for Windows Ultimate x64 and followed this procedure to get my mounts back ... http://www.networkedmediatank.com/wiki/index.php/NFS_Windows7 Further to this, as I am running NFS across a LAN only, for performance I did the following: Under Services for Network File System->Client for NFS(right-click)->properties Set Transport Protocol(s) to UDP This upped my read access from 5-6MB/s to 30MB/s Question for Windows Devs - Why do I have to go through this work around? Please patch this. NOTE: after following the procedure linked above, I was able to mount using my batch script on subsequent restarts.
Free Windows Admin Tool Kit Click here and download it now
June 19th, 2011 7:00pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics