ACLs apply differently for user/group?

[Steiner-SE]

Ok, to figure out permissions and ACLs I've made an experimental share that I keep changing the ACL entries to (restarting service after each change)
On the Windows side I disconnect the share and remaps it for each change to see differences, I try both mapping directly (windows credentials) and using different credentials (using the truenas account name/pass, but really the same as the windows credential).
I noticed that using owner@ and group@ adds additional permission entries on the windows side so I'm now setting the specific user and group and only get those two entries on the windows side.
Now here what has me confused. On the windows side no matter how I map the share (windows authentication or truenas credentials) and despite having set up permissions identically for user and group in TrueNAS what I see are two completely different things.
For the group entry (which always takes a bit longer to populate) when I select the security tab and click on the group all check marks except "Full Control" are set, as expected.
I'd expect the same to be true for the user entry (which is always populated, no delay), but when I click on that entry no check marks expect "special permissions" are set. With identical ACls set in the NAs shouldn't they appear the same here? This is the same regardless of how I map the share as mentioned.

I have taken the NAS of the domain but that lab machine is still in the domain, might this account for the discrepancy (despite using explicit TrueNAS credentials)?

I hope I made this understandable and clear enough?

 

[c77dk]

Are you using FreeNAS or TrueNAS BETA? If it's TrueNAS BETA, ensure it's BETA2, as it have a lot of fixes with ACL management.

 

[Steiner-SE]

Are you using FreeNAS or TrueNAS BETA? If it's TrueNAS BETA, ensure it's BETA2, as it have a lot of fixes with ACL management.

It was TrueNAS Core Beta 1, now it's Beta 2! :) (Beta 2 wasn't out when I posted)

 

[c77dk]

It was TrueNAS Core Beta 1, now it's Beta 2! :) (Beta 2 wasn't out when I posted)

Saw that after posting Did BETA2 solve the problem?

 

[Steiner-SE]

Saw that after posting Did BETA2 solve the problem?

I think part of the problem was applying permissions recursively and I haven't had time to test all that yet. prior to update I redid all but one of my datasets and made new shares with different settings and everything seems to be working atm. (but there's definitely files and folders not having the new permissions all over the place. Just on one of the subfolders in my media library have 7 sets of permissions attached, and the new owner group is NOT one of them)

 

[c77dk]

I think part of the problem was applying permissions recursively and I haven't had time to test all that yet. prior to update I redid all but one of my datasets and made new shares with different settings and everything seems to be working atm. (but there's definitely files and folders not having the new permissions all over the place. Just on one of the subfolders in my media library have 7 sets of permissions attached, and the new owner group is NOT one of them)

setting recursive permissions is one of the notable fixes - @anodos had done some last minute changes breaking recursion before BETA1 was rolled, but it should be fixed in BETA2

 

[Steiner-SE]

My new procedure I follow for each dataset is to create it as SMB, not generic. Then I immediately change owner and group. Set it to restrictive and make it user and group ACLs (not the @ variants) and nothing else.
I apply this recursively. Then when creating the share don't apply any profile and just set name/comment and finish.