Windows NFS: Don’t Forget .maphosts
I recently mentioned that I was trying out NFS Services on Windows 2003. It actually has been working quite well for me – faster and less CPU than NFS to my OpenFiler server, in fact. OK, to be fair, the OpenFiler server is a bit older and running a pair of hyper-threaded Xeons while the Windows server sports a much newer 2.66 Quad core. Perhaps the processor makes a difference?
Anywho, on the Windows server I’m using the User Name Mapping service to map *nix user accounts to Windows user accounts. There are other ways to do this, but it seemed the simplest and easiest for my purposes. I just mapped the root user from the ESXi server to my domain account and then use NFS shares from Windows for backup purposes (using ghettoVCB).
Last week I thought it would be prudent to ensure that I could actually do something with these backups I’m stacking up. Since they’re already on an NFS share I figured I’d just connect to that share with my Windows 7 machine running VMware Workstation.
There is a NFS client is built-in to Windows 7 (I’m unsure of which editions though – Enterprise and Ultimate maybe?) and just needs to be activated via the “Turn Windows features on/off” control panel applet. Check the boxes, wait a few moments and you’re good to go.
Oh, and reboot. I didn’t get prompted to reboot but it definitely didn’t start working until I did so!
Once that’s all done just a bit of configuration needs to happen. First, launch the “Services for Network File System” app on the Windows 7 machine. Right click on “Services for NFS” and click on Properties. In the resulting dialog check User Name Mapping and specify the server running the service. That’s really about all you need to do.
Now just type “servername:/sharename” into an Explorer address bar and you’ll see your stuff. You can map from there as well. Or drop to a command prompt and use the mount command.
But it wouldn’t work for me. I’d get connected but clearly had authority issues (ain’t that a lifelong issue..?). Turns out I had one more little step to go – one frequently glossed over.
By default the User Name Mapping service (on the server) is only able to accept requests from the machine on which it is running. So when my Windows 7 machine tried to use it nothing would happen. It was blocked. Fortunately, I found a technet article that explained what was going on and what I needed to change.
On the server I had to edit the %windir$\msnfs\.maphosts file (use the text editor of your choice). Specifically, I had to add one line to the bottom that listed my Win7 client’s name. Restarted the service and everything works great now!
You control which computers can access User Name Mapping by editing a file named .maphosts in the %windir%\msnfs directory of the computer User Name Mapping. By adding entries in this file, you can easily permit or deny access by any other computer to User Name Mapping. If the .maphosts file is present but not empty, then only those computers allowed access by entries in the file can access User Name mapping. If the .maphosts file is present but empty (the default), no computers except the computer running User Name Mapping itself can access User Name Mapping. If the .maphosts file is not present, no computers (including the computer running User Name Mapping) can access User Name Mapping.
Now I realize it is a bit odd to use NFS between Windows computers, but it was a fun challenge getting it all working. At some point I might try to do some benchmarking to see how NFS maps compare to normal SMB shares.
Possibly Related posts:
- Wrestling with ESXi Client Backups
- Windows 7 Beta
- Windows Live Mesh or DropBox?
- Windows Update / Hotfix Conundrum
- Finding Uptime for Windows
Comments
Leave a Reply
Referrals and Ads
Flair and Sparklies
