[ My Topic has been lifted from: http://social.answers.microsoft.com/Forums/en-US/w7network/thread/bc00b585-579b-43b3-8efb-e227047921cc I was advise to seek assistance from the TechNet forums. ] I have Windows 7 Ultimate, 64bit Edition, I am able to successfully mount new drives N: (readonly server:/data) and O: (readwrite server:/data/subdir) locally to two remote NFS server shares on the LAN. There was an issue for a while where my script needed "START /WAIT" to the "mount.exe" command to ensure the correct readonly/readwrite status was setup on each. However.... I have been unable to find any way to control the UID and GID mappings used by the client to present to the server. I do not have and will not be installing any Windows Server system to act as a mapping server or Active Directory PDC. My requirements are VERY simple, I just want to map one Windows 7 local user to a specific UID number. If possible the same with the GID but I don't think this would be a show stopper. Because of the above oversight in Windows 7 NFS client implementation, I have been able to configure up the server to always force the UID and GID mapping to a specific value/number, regardless of what the Windows 7 client specifies. So this means now that the Windows 7 system can create files/directories and the correct Unix ownership is set on them. All files and folders in Exporer.EXE have the "Read-Only" attribute set (when right clicking Properties), this is the MSDOS read-only attribute, the one that it queries with the Win32 API GetFileAttributes()http://msdn.microsoft.com/en-us/library/aa364944(VS.85).aspx andhttp://msdn.microsoft.com/en-us/library/ee332330(v=VS.85).aspx how do I get Windows 7 to stop doing this. The mount/share is read-write and the Unix permissions (NFS permissions) of the files/folders clearly indicate write access is permitted. Windows 7 has a mount option for "-o fileaccess=###" it also seems to be a complete oversight by Microsoft that directory creation does not have the same Unix permissions as file creation. So a single all or nothing "fileaccess" option is of little use to anyone. Common with many Unix based NFS clients is the ability to independantly overwrite the default permission mode in just the way "fileaccess" tried to provide. The Window 7 client should allow the options "-o fileaccess=664" and "-o diraccess=775" applying to respective value to files or directories accordingly. Is it likely that any future service pack will see these two major issues fixed? Issues... The ability for a single installation and standalone Windows 7 Ultimate system to setup a system-wide default UID or a per local-user UID to present over NFS for file ownership tokens. Support for "-o diraccess=775" to relate to Folders, leaving the existing "-o fileaccess=664" to relate to anything that is not a Folder. All folders have the read-only MSDOS attributes set, not the files, I am setting readonly file append errors from MSYS tooling (a version of CYGWIN and the enviroment for such things as Mozilla Firefox browser). I have not confirmed this is the cause of those errors but its clearly throwing permission denied errors for file append operations. Also issues with the MMC snap-in stop/start of NFS services giving errors and changes expected after a restart never showing up (after maybe more than 10 restarts over many hours) but a reboot fixed the registry tweak AnonymousUID change. Thanks

Bump. Original thread from w7network has been marked as "Answered" (I guess by a zombie keeping their stats up "questions v answers"), the problem has not been answered only a redirect to this forum. Or maybe you know of a good independant 3rd party NFS Client product that works with Win7 ?

We are using a third party NFS Client product and are still having these issues - I was wondering if you ever found a solution to any of this? Thanks!