Did you make the registry changes?
One quickly sees that the Client for NFS software is intended for use in an organization which supports that client with Active Directory’s Identity Management for UNIX component (which extends the directory schema to allow for mapping Windows user and group identities to UNIX UIDs and GIDs) or a User Name Mapping service (which runs on Windows Server). Using the client as a stand-alone solution for a personal network or even within an organization which doesn’t support the client with formal infrastructure is difficult. You’d think simple, local UID/GID mapping would be supported, but it is not.
However, there is a means by which we can goad Windows into effectively allowing us to mount NFS shares on single-user systems. The solution is no good for systems with multiple users (in fact, it’s a horrible security flaw, since the solution forces every user on the Windows system to access the NFS share using the same UID/GID). Fortunately for me, I have just such a single-user system from which I’d like access to my NFS data.
The trick is to instruct the Client for NFS to use the intended UID/GID combination as its “anonymous” account values. This way, you don’t instruct the system to conduct any mapping between your Windows identity and the proper UNIX identity, rather, you just tell it to always use the same UID/GID combination when connecting to NFS. The means by which to do this is not well documented (surprise, surprise), but is accomplished by adding two DWORD values to a registry key which should already exist:
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default
REG_DWORD: “AnonymousGid”
REG_DWORD: “AnonymousUid”
Within those two DWORD values, place the desired UID and GID. Restart the Client for NFS service, and you should now be able to mount your NFS shares.