New files and folders on a Linux client mounting a Windows 2012 Server for NFS share do not inherit Owner and Group when SetGID bit set RRS feed

  • Question

  • Problem statement

    When I mount a Windows NFS service file share using UUUA and set the Owner and Group, and set the SetGID bit on the parent folder in a hierarchy. New Files and folders inside and underneath the parent folder do not inherit the Owner and Group permissions of the parent.

    I am given to understand from this Microsoft KnowledgeBase article ( the problem is due to the Windows implmentation of NFS Services not supporting the Solaris SystemV or BSD grpid "Semantics"

    However the article says the same functionality can acheived by using ACE Inheritance in conjunction with changing the Registry setting for "KeepInheritance" to enable Inheritance propagation of the Permissions by the Windows NFS Services.

    1. The Precise location of the "KeepInheritance" DWORD key appears to have "moved" in  Windows Server 2012 from a Services path to a Software path, is this documented somewhere? And after enabling it, (or creating it in the previous location) the feature seems non-functional. Is there a method to file a Bug with Microsoft for this Feature?

    2. All of the references on demonstrating how to set an ACE to achieve the same result "currently" either lead to broken links on Microsoft technical websites, or are not explicit they are vague or circumreferential. There are no plain Examples. Can an Example be provided?

    3. Is UUUA compatible with the method of setting ACE to acheive this result, or must the Linux client mount be "Mapped" using an Authentication source. And could that be with the new Flat File passwd and group files in c:\windows\system32\drivers\etc and is there an Example available.


    Windows Server 2012 Standard

    File Server (Role)

    +- Server for NFS (Role) << -- installed

    General --

    Folder path: F:\Shares\raid-6-array

    Remote path: fs4:/raid-6-array

    Protocol: NFS

    Authentication --

    No server authentication

    +- No server authentication (AUTH_SYS)

    ++- Enable unmapped user access

    +++- Allow unmapped user access by UID/GID

    Share Permissions --


    Permissions: Read/Write

    Root Access: Allowed

    Encoding: ANSI

    NTFS Permissions --

    Type: Allow

    Principal: BUILTIN\Administrators

    Access: Full Control

    Applies to: This folder only

    Type: Allow


    Access: Full Control

    Applies to: This folder only

    -- John Willis, Facebook: John-Willis, Skype: john.willis7416

    • Edited by jwillis84 Tuesday, October 29, 2013 6:49 PM
    Tuesday, October 29, 2013 2:50 PM

All replies

  • I'm making some "major" progress on this problem.

    1. Apparently the "semantics" issue to honor SGID or grpid in NFS on the server side or the client side has been debated for some time. It also existed as of 2009 between Solaris nfs server and Linux nfs clients. The Linux community defaulted to declaring it a "Server" side issue to avoid "Race" conditions between simultaneous access users and the local file system daemons. The client would have to "check" for the SGID and reformulate its CREATE request to specify the Secondary group it would have to "notice" by which time it could have changed on the server. SUN declined to fix it.. even though there were reports it did not behave the same between nfs3 vs nfs4 daemons.. which might be because nfs4 servers have local ACL or ACE entries to process.. and a new local/nfs "inheritance" scheme to worry about honoring.. that could place it in conflict with remote access.. and push the responsibility "outwards" to the nfs client.. introducing a race condition, necessitating "locking" semantics.

    This article covers that discovery and no resolution -

    2. A much Older Microsoft Knowledge Based article had explicit examples of using Windows ACEs and Inheritance to "mitigate" the issue.. basically the nfs client "cannot" update an ACE to make it "Inheritable" [-but-] a Windows side Admin or Windows User [-can-] update or promote an existing ACE to "Inheritable"

    Here are the pertinent statements -

    "In Windows Services for UNIX 2.3, you can use the KeepInheritance registry value to set inheritable ACEs and to make sure that these ACEs apply to newly created files and folders on NFS shares."

    "Note About the Permissions That Are Set by NFS Clients

    The KeepInheritance option only applies ACEs that have inheritance enabled. Any permissions that are set by an NFS client will only apply to that file or folder, so the resulting ACEs created by an NFS client will not have inheritance set."


    If you want a folder's permissions to be inherited to new subfolders and files, you must set its permissions from the Windows NFS server because the permissions that are set by NFS clients only apply to the folder itself.";en-us;321049

    3. I have set up a Windows 2008r2 NFS server and mounted it with a Redhat Enteprise Linux 5 release 10 x86_64 server [Oct 31, 2013] and so far this does appear to be the case.

    4. In order to mount and then switch user to a non-root user to create subdirectories and files, I had to mount the NFS share (after enabling Anonymous AUTH_SYS mapping) this is not a good thing, but it was because I have been using UUUA - Unmapped Unix User Access Mapping, which makes no attempt to "map" a Unix UID/GID set by the NFS client to a Windows User account.

    To verify the Inheritance of additional ACEs on new subdirectories and files created by a non-root Unix user, on the Windows NFS server I used the right click properties, security tab context menu, then Advanced to list all the ACEs and looked at the far Column reflecting if it applied to [This folder only, or This folder and Subdirectories, or This folder and subdirectories and files]

    5. All new Subdirectories and files createdby the non-root user had a [Non-Inheritance] ACE created for them.

    6. I turned a [Non-Inheritance] ACE into an [Inheritance] ACE by selecting it then clicking [Edit] and using the Drop down to select [This folder, subdirs and files] then I went back to the NFS client and created more subdirs and files. Then back to the Windows NFS server and checked the new subdirs and folders and they did Inherit the Windows NFS server ACE! - However the UID/GID of the subdirs and folders remained unchanged, they did not reflect the new "Effective" ownership or group membership.

    7. I "believe" because I was using UUUA and working "behind" the UID/GID presentation layer for the NFS client, it did not update that presentation layer. It might do that "if" I were using a Mapping mechanism and mapped UID/GID to Windows User SIDs and Group SIDs. Windows 2008r2 no longer has a "simple" Mapping server, it does not accept flat text files and requires a Schema extension to Active Directory just to MAP a windows account to a UID/GID.. a lot of overhead. Windows Server 2012 accepts flat text files like /etc/passwd and /etc/group to perform this function and is next on my list of things to see if that will update the UID/GID based on the Windows ACE entries. Since the Local ACE take precedence "over" Inherited ACEs there could be a problem. The Inheritance appears to be intended [only] to retain Administrative rights over user created subdirs and files by adding an additional ACE at the time of creation.

    8. I did verify from the NFS client side in Linux that "Even though" the UID/GID seem to reflect the local non-root user should not have the ability to traverse or create new files, the "phantom" NFS Server ACEs are in place and do permit the function.. reconciling the "view" with "reality" appears problematic, unless the User Mapping will update "effective" rights and ownership in the "view"

    -- John Willis, Facebook: John-Willis, Skype: john.willis7416

    Thursday, October 31, 2013 5:47 AM
  • Hello,
    I tried the steps provided by the article but failed to find a possible cause. Thus I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.
    Thank you for your understanding and support.

    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time.
    Thanks for helping make community forum a great place.

    Thursday, October 31, 2013 11:13 AM
  • Hi,

    I reviewed the article.

    It seems windows server 2012 may do not support the registry value KeepInheritance under HKEY_LOCAL_MACHINE\Software\Microsoft\Server for NFS\CurrentVersion\Mapping

    since we have no NFS environment as yours, you can manually create these missing values. then test if it can work or not.



    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, November 1, 2013 10:50 AM
  • I would like to add that I am experiencing similar problems.

    I am using mapped user access and have tested successful mounts using both  AUTH_SYS and KRB5.

    I am trying to utilize the setgid bit or a similar functionality to ensure that all files created under a specific nfs directory are assigned the same group.

    The documentation for NFS is horribly scattered over many years and locations and there doesn't seem to be a comprehensive reference that discusses the correct way to do permissions since 2008.

    Registry keys which are said to have been defunct since SFU 2.3 are still present in 2012 R2.

    The best reference I can find to setting permissions is the so-so explanation of the nfsfile command:

    Obviously, those looking to use Windows NFS are looking to expose files to *both* Windows and Linux clients.  There is virtually no documentation that speaks as to how to manage the coexistence of both unix/nfs and NTFS permissions.

    However, even when disregarding the NTFS permissions, and trying to simply setup NFS access, basic functionality like the setgid fails to work.

    I have sent several emails to the but it seems no one may be manning that address.

    Can a MSFT employee perhaps ask Ziquan Zhu to visit this thread and provide some answers?  He has written some excellent material for the 2012 NFS server, but unfortunately it does not cover these topics.

    thank you

    Friday, November 1, 2013 11:18 PM
  • I think the behavior is "as intended". As discussed above, it seems a decision was made by Microsoft to make the server "Prioritize" serveer side ACE control behavior over "Client" management of the behavior to avoid "race conditions" between a client and a server applying the permissions propagation.

    As reported by Solaris NFSv4 Sun MicroSystems who invented the NFS protocol, between NFSv3 and NFSv4 also introduced server side ACE entry and changed the behavior to Prioritize ACE behavior over Client behavior.

    In the Linux Community they continued to follow NFSv3 behavior even when NFSv4 protocol became available.

    While a "Bug" was filed with various Linux distros, a fix was declined without comment.

    The "Fix" would seem to be adding a Sematic to "Lock" the folder or file by the Client while checking for SetGID and updating the permissions, however "Locking" could introduce other abberant behavior between clients and the server.

    Or "more simply" adding an "Alternative NFSv3 behavior" to Prioritize NFS Client permissions over Windows ACE permission propagation.

    -- John Willis, Facebook: John-Willis, Skype: john.willis7416

    • Edited by jwillis84 Tuesday, November 5, 2013 3:07 PM
    Tuesday, November 5, 2013 3:05 PM
  • The "KeepInheritance" registry key seems intended "only" to Propagate server side Windows ACE entries (NTFS ACE entries). This is much like Solaris NFSv4 ACE entries by Sun Microsystems.

    While using the directions for Microsoft Service for UNIX 2.3 to turn on "KeepInheritance" it [would] and [did] propagate the Windows NTFS ACE, however this was not reflected in the UID/GID presentation to the "NFS Client".

    Further testing revealed the Windows NTFS ACE was [in force]  or "in other words" even though the UNIX permissions "Denied" access; the NFS Client was "Allowed" access to the file or folder.

    This was "unacceptable" behavior as the Client would then have to have its "rights" view manually updated using the auxilary commandline tools from the Windows operating system commandline. The Microsoft Knowledgebase article "explicitly" states


    Any permissions that are set by an NFS client will only apply to that file or folder, so the resulting ACEs created by an NFS client will not have inheritance set.


    Under Windows "Inheritance == Propagate Permissions "


    Or in otherwords


    Any permissions that are set by an NFS client will only apply to that file or folder, so the resulting ACEs created by an NFS client will not "propagate permissions".


    Instead, we deployed a Virtual Machine running Linux [on top] of the Windows File Server which served as a Virtual Machine backend file system host in a VHD, and shared "native" NFS services because the Microsoft Windows Services for UNIX were inadequate to support current UNIX/Linux conventions.


    SFU is currently not usable in Windows Server 2012 with any UNIX/Linux client for Read-Write service.


    It might be of some use in Read-Only situations "only"

    • Edited by jwillis84 Tuesday, November 5, 2013 3:38 PM
    Tuesday, November 5, 2013 3:17 PM
  • "The documentation for NFS is horribly scattered..."


    I could not agree more.

    It appears to be a case of a Product that was acquired, and then not maintained as a feature.

    A guess would be that it is currently in the process of being deprecated and will not be part of the Microsoft family of services much longer.

    • Edited by jwillis84 Tuesday, November 5, 2013 3:33 PM
    Tuesday, November 5, 2013 3:32 PM
  • I think there are some production situations where this can be implemented beyond "read-only" but, calling this NFS is really stretching it based on how differently it functions from native unix/linux (any flavor).  It is as if it has taken the worst out of all scenarios.

    I am using it mostly in a lab environment (read-only) and decided to utilize it as a fully functional NFS server rather than build up another linux box.  I can see now that it isn't going to work well from that perspective.

    I don't think I agree that this product is going to be appears to me that there as been effort to at least maintain (if not even enhance) much of the functionality of SFU (including identity mapping and NFS) but unfortunately the fall short leaving this (NFS) little more than a toy.

    Additionally, the implementation of only NFS 4.1 and not 4.0 seems to restrict older OS systems from accessing kerberized NFS (RHEL/Centos 5.x systems which don't support minorversion parameter).

    And while the setup is certainly easier than a native linux configuration - the troubleshooting and logging is much more obscured.

    I think we'll agree that no one looking for serious NFS services should consider this.  With the acceleration of the SAMBA team's development efforts, it is likely more productive to use a linux NFS server with SAMBA for sharing between environments.

    Thursday, November 7, 2013 6:42 PM
  • Hi,

    Your question falls into the paid support category which requires a more in-depth level of support.  Please visit the below link to see the various paid support options that are available to better meet your needs.;en-us;offerprophone



    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Wednesday, November 13, 2013 7:07 AM
  • "The documentation for NFS is horribly scattered over many years and locations and there doesn't seem to be a comprehensive reference that discusses the correct way to do permissions since 2008."

    To which nobody can disagree. There is next to no documentation, and now I know why.

    We had krb5 NFS between client and server working within 30 mins of starting (we had estimated a week). However soon as we applied any real world scenarios to the  file server, its limitations was clear for all to see.

    I suppose if you wish to share a read only folder to linux users, it is of use, for but home and group folders etc, forget it. Seriously forget it, its not up to the job.

    A real pity because it all works very well apart from the fundamental issue of inheritance. If this service makes it to the next version I'll eat my hat. 

    And before anyone replies with "its in the NFS specification ", yeah yeah, as I said "forget it its not up to the job". We switched to rhel6 and its nfsv4 services behave as expected.


    • Edited by Joe Darkman Wednesday, June 18, 2014 12:00 PM
    Wednesday, June 18, 2014 11:54 AM
  • I wish we had seen this thread six months ago.

    Extremely frustration that Microsoft have obviously been developing the product (although interesting the client is not NFS version 4 compatible).

    It really looks like development was pulled and they just had enough to release "something". Unfortunately that "something" is rather like a car that can't steer, it could have a use but to all intents and purposes its useless. Actually the car analogy explains the frustration. Its a car that can go from 0 to sixty in X amount of seconds., top speed of Y, Z miles to the gallon and really comfy seats! However just as you are about to drive off  the salesman  tells you the manufacturer didn't design in any steering.

    Tuesday, June 24, 2014 9:05 PM
  • Hi Ben

    I've been struggling to setup NFS mount on Ubuntu using mapped users,  Auth_sys and/or KRB5

    Can you please share how can I make it work?



    Monday, July 17, 2017 2:39 PM
  • I have the same issue using docker. Any update?
    Friday, October 6, 2017 12:54 PM