Trying to understand 'local_users' in SCALE

[shimian5]

I have my username (mbaran) and a group I use for read/write access called RW (to which I add other usernames based on their requirements. This is how my setup was always configured in CORE and had no issues.

In a brand new share, with fresh ACLs set (mbaran/RW)

I see correctly at the root of the share that these permissions are set

However - If I create a folder as user 'mbaran' the permissions on that folder (and all subsequent data) is mbaran:local_users (and in some cases, builtin_users, though I can't pinpoint why)

The unix permissions reflect the same...

Any idea what might be going on here? Thanks!

 

[KrisBee]

That permissions editor screen grab looks like your using POSIX ACLs ( zfst get acltype on the dataset will confirm). Perhaps you need NFSv4 ACLs.

 

[anodos]

Can you post contents of `midclt call smb.groupmap_list | jq`? Might be an artifact of nscd caching some nss_winbind results. If you run command `getent group NAS2\\local_users` it will probably return same gid as builtin_users. You can probably just `service nscd restart` and clear the nscd cache.

 

[shimian5]

Can you post contents of `midclt call smb.groupmap_list | jq`?

Code:

{
  "builtins": {
    "90000003": {
      "nt_name": "Guests",
      "sid": "S-1-5-32-546",
      "gid": 90000003,
      "group_type_int": 4,
      "comment": "",
      "unix_group": "BUILTIN\\guests",
      "group_type_str": "Local Group"
    },
    "90000001": {
      "nt_name": "Administrators",
      "sid": "S-1-5-32-544",
      "gid": 90000001,
      "group_type_int": 4,
      "comment": "",
      "unix_group": "BUILTIN\\administrators",
      "group_type_str": "Local Group"
    },
    "90000002": {
      "nt_name": "Users",
      "sid": "S-1-5-32-545",
      "gid": 90000002,
      "group_type_int": 4,
      "comment": "",
      "unix_group": "BUILTIN\\users",
      "group_type_str": "Local Group"
    }
  },
  "local": {
    "1002": {
      "nt_name": "Backup",
      "sid": "S-1-5-21-306908099-456363784-1364118082-1003",
      "gid": 1002,
      "group_type_int": 4,
      "comment": "",
      "unix_group": "Backup",
      "group_type_str": "Local Group"
    },
    "1001": {
      "nt_name": "RW",
      "sid": "S-1-5-21-306908099-456363784-1364118082-1002",
      "gid": 1001,
      "group_type_int": 4,
      "comment": "",
      "unix_group": "RW",
      "group_type_str": "Local Group"
    }
  },
  "local_builtins": {
    "544": {
      "nt_name": "local_administrators",
      "sid": "S-1-5-21-306908099-456363784-1364118082-512",
      "gid": 544,
      "group_type_int": 4,
      "comment": "",
      "unix_group": "builtin_administrators",
      "group_type_str": "Local Group"
    },
    "545": {
      "nt_name": "local_users",
      "sid": "S-1-5-21-306908099-456363784-1364118082-513",
      "gid": 545,
      "group_type_int": 4,
      "comment": "",
      "unix_group": "builtin_users",
      "group_type_str": "Local Group"
    },
    "546": {
      "nt_name": "local_guests",
      "sid": "S-1-5-21-306908099-456363784-1364118082-514",
      "gid": 546,
      "group_type_int": 4,
      "comment": "",
      "unix_group": "builtin_guests",
      "group_type_str": "Local Group"
    }
  },
  "invalid": [],
  "localsid": "S-1-5-21-306908099-456363784-1364118082"
}

 

[anodos]

Yeah, looks like nscd is caching results of an nss_winbind lookup. NAS2\\local_users == builtin_users == gid 545. OS is only concerned with GIDs. You're fine here.

 

[shimian5]

Doesn’t that technically grant a wider group role than just my defined group of ‘RW’ though? Isn’t every locally defined group now a member of that builtin group?

 

[anodos]

Doesn’t that technically grant a wider group role than just my defined group of ‘RW’ though? Isn’t every locally defined group now a member of that builtin group?

Yeah, combination of linux behavior difference on new file creation (compared with FreeBSD) with how we're constructing tokens in samba. builtin_users is currently mapped to RID 513 (users) in our local domain, but this appears to alter primary group on file creation (which makes sense because <domain>-RID 513 is always a user's primary group SID for their SAM Account. I'm investigating fix. We need some of this group mapping stuff so that granting permissions to S-1-5-32-545 (Users) is sufficient to allow local users access to the share.

 

[anodos]

NAS-112257 / 21.10 / Fix issue unix tokens for local users by anodos325 · Pull Request #7508 · truenas/middleware

github.com

 

[shimian5]

Thanks! Is there a way to test this PR without moving to the nightly branch?

 

[anodos]

Thanks! Is there a way to test this PR without moving to the nightly branch?

You can probably copy the referenced file over /usr/lib/python3/dist-packages/middlewared/plugins/smb_/groupmap.py and restart the middlewared service (probably make a backup first).

 

[anodos]

Otherwise you can probably set the setgid bit on the root of your share.

 

[shimian5]

hate to bump an old thread anodos, but I am still having the exact same issue on 22.02RC2. File/Folder creations from windows are being created with the group "builtin_users" rather than the users primary/only group.

I even created a brand new share, new ACLs, verified nfsv4 permissions, new user and new groups. Same behavior.

 

[anodos]

hate to bump an old thread anodos, but I am still having the exact same issue on 22.02RC2. File/Folder creations from windows are being created with the group "builtin_users" rather than the users primary/only group.

I even created a brand new share, new ACLs, verified nfsv4 permissions, new user and new groups. Same behavior.

Probably stale groupmap info or pdb info.

 

[shimian5]

have done many updates in between/reboots. Is there any way to forcefully clear these and re-test.

 

[shimian5]

This issue is because my group name was using capital letters. Reverting to lowercase letters (i.e. rw instead of RW) resolves my issue. I have an open JIRA ticket where hopefully the GUI is updated to reflect that only lowercase letters can be used.