For a bit more insight, these entries were created using
this guide on the forums for home directories on Windows.
Hah! So I'm to blame. :D
If I'm not mistaken, when you use ADUC to create home directories it assigns the user who is running the ADUC process as the Owner overriding anything else.
For the most part, NFSv4 ACLs and NTFS ACLs are identical, but there are some differences. NFSv4 ACLS have the concept of 'special' ACEs (owner@, group@, everyone@), which are compatible with user, group, other in traditional posix mode bits. Windows doesn't have these. As a result samba has two different methods for translating these 'special' ACEs to make an NTFS ACL.
Method 1 - "nfsv4:mode=special". This translates the 'Special' ACE into an explicit NTFS ACE. For instance, the owner is "Bob" and owner@ has "full control", samba will present "Bob:full control" to Windows Clients. Samba will also show that "Bob" is the owner of the file.
Method 2: "nfsv4:mode=simple". Samba creates a non-inheriting ACE for the UID associated with owner@. Samba will also map the owner@ and group@ entries to inheriting "creator-owner" and "creator-group" NTFS ACEs.
FreeNAS defaults to Method 1. The side-effect of this is that deleting the NTFS Access Control Entry (bob in the above example) at the root of the share \\FreeNAS\Users will potentially affect the permissions of the owners of directories further down the tree. An additional side-effect of FreeNAS using "Method 1" is that the "creator-owner" NTFS ACE doesn't work (there's probably a reason why it has been deprecated). This is a fundamental defect in my how-to guide, which was largely based a samba project wiki entry.
So, if 'John' used ADUC to create a home directory for user 'Jane', John is actually the Owner not Jane. Mind you, I could change the Owner back to 'root' every time I create a new user, it's no big deal but is this really correct? Don't get me wrong I can redo them with ease but in practice this would seem wrong no?
I see this as a problem as well. I need to look into it and experiment more. If this is the case, you could probably create a powershell script to automate the process. As things currently stand, it may be a better idea to use the traditional [homes] shares with AD. [homes] will dynamically generate unique user shares as users authenticate to the server. You might be able to set it as the home directory in ADUC, but it seems like you might have an interesting race condition (I believe home directories can be accessed via \\freenas\homes as well as \\freenas\bob). Once again, I'll need time to poke around and see what works. You might also be able to use group policy preferences to have windows automatically map \\freenas\%USERNAME%. Home shares by default have a share definition access control set so that users can only access their own home shares.
So tl;dr I put a disclaimer at the top of my guide.
Maybe its be due to autorid using 20,000-90,000,000 yet CIFS uses 90,000,001-100,000,000? When I saw the CIFS idmap I really wondered how this would work on the client side.
There are two idmap ranges and backends for a domain-joined FreeNAS server. One is backed by a tdb file and contains user/group mappings for Windows built-in / well-known SIDS. The other is for your domain users / groups. I simplify things by using the same idmap settings for all domain joined Linux servers. Since idmap_rid is deterministic this has the effect of providing the same UIDs and GIDs for all domain users and groups on all *nix servers.
In fact, I'm still unsure about how the additional idmap range works into the mix when using a CIFS client.
It should 'just work'.
Disabling the ACL made no impact (specified 'noacl') but I will keep this in mind for testing now. Thanks!
PS: The CIFS client also complains about the service inode number but I've been ignoring this thus far.
