How can I make Windows modify CIFS/ZFS ACLs 'correctly'

5,989

So I've not really dealt much with any of this, and I may be seriously wrong, but here's a few bits that might explain it:

  • NFSv4 ACLs are similar but not quite like Windows/CIFS/NTFS ACLs.

    For example, the Windows ACL format does not distinguish between 'user' or 'group' or 'special' SIDs at all. Since the NAS doesn't know what accounts your Windows system has, it cannot determine which SIDs are users and which are groups – it has to guess.

  • However, while NFSv4 ACLs do not support POSIX-style 'default ACEs', they do support the Windows/CIFS-style 'inheritable' ACEs; that is, each entry can be inheritable or not.

    In the FreeBSD getfacl, you can see the f and d flags which correspond to "inheritable by files" and "inheritable by directories".

    There is also an "inherit-only" flag i, which is practically an exact equivalent to 'default' ACEs in POSIX ACLs – that is, the ACE is only inherited, but isn't used for the directory itself.

  • When creating a file, it is always owned by the user who created it. It's not inheritable.

    If the CIFS server were running Windows Server, it'd have an option to make the built-in "Administrators" group the default file owner (again note how it lets the owner be either a user or a group, and lacks 'group ownership').

Share:
5,989

Related videos on Youtube

Samuel Harmer
Author by

Samuel Harmer

Updated on September 18, 2022

Comments

  • Samuel Harmer
    Samuel Harmer over 1 year

    I have a FreeNAS (FreeBSD) system with a CIFS share (called "library") backed by a ZFS file system. The share is set up as per the FreeNAS GUI to use "Windows / Mac" ACLs which I'm led to believe means NFSv4 ACLs.

    This is how I want the basic ACLs to be:

    nas# getfacl /mnt/big/library/test
    # file: /mnt/big/library/test
    # owner: DOMAIN\administrator
    # group: DOMAIN\domain admins
                owner@:rwxpDdaARWcCo-:fd----:allow
                group@:rwxpDdaARWcCo-:fd----:allow
             everyone@:r-x---a-R-c---:fd----:allow
    

    Which from the Windows 7 GUI appears as "Full control" for "DOMAIN\administrator" and "DOMAIN\Domain Admins" and "Read & execute" for "Everyone" inherited from the root of the share. Windows even recognises the owner as the "Administrator" correctly.

    I'm having two problems which I believe might be related.

    Firstly if I modify or create an ACE on an existing object (file or directory) Windows replaces the owner@ ACE with one for group:DOMAIN\administrator and in the case of adding, it creates a group ACE for group:DOMAIN\joe for the user. I don't so much mind the fact it thinks a user is a group (so long as it works), but replacing the owner ACE is a pain because now if I change the owner of the object the ACE will still exist for the previous owner.

    The second annoyance is when creating a new object the ACL looks like this:

    nas2# getfacl /mnt/big/library/test/New\ folder/
    # file: /mnt/big/library/test/New folder/
    # owner: DOMAIN\joe
    # group: DOMAIN\domain users
                owner@:rwxpDdaARWcCo-:fd----:allow
                group@:rwxpDdaARWcCo-:fd----:allow
             everyone@:r-x---a-R-c---:fd----:allow
    

    Although it seems to have inherited ACEs correctly, it hasn't kept the owner or group of the parent directory. Is there a way to have it created with the properties of the containing directory?

    Looking at the setfacl manpage it states:

     -d      The operations apply to the default ACL entries instead of access
             ACL entries.  Currently only directories may have default ACL's.
             This option is not applicable to NFSv4 ACLs.
    

    Which to me implies that NFSv4 ACLs don't support default ACEs which would seem to be what I need to fix my second issue. Does anyone know if that is correct?

  • Samuel Harmer
    Samuel Harmer over 8 years
    "the NAS doesn't know what accounts your Windows system has" -- actually it does. The NAS is the Samba AD DC for "DOMAIN", which the Windows 7 machine is also joined to. So in theory it has full access, should it wish, to determine which SIDs are users and which are groups. I'm actually looking at the same problem again in a slightly different environment so hopefully I can make better progress with what I've learned since 2014!