SMB Windows Domain Users Access Denied after 11.3 Update

[Michael Hanna]

I'll first start by saying I'm certain this is caused by changes made with this update as I've been reading through recent posts regarding this. I'm not familiar enough with what is being is being discussed to determine what I need to do to resolve my issue. I have multiple SMB shares that have been setup for years with the same permissions with no issues. I have active directory groups such as domain admins that have full control, modify, read & execute, list, read, write permissions on on the share and all sub directories and files but whenever I try from Windows 10 create new files or folders or rename anything I get an access denied error. These shares were all originally setup from a Windows client as FreeNAS did not have the ability to edit the ACL via the GUI at the time they were created. When I look at the ACLs in freenas the look right but I'm sure I'm missing something. I would be grateful if anyone could work with me to determine where something has broken.

 

[jzollo]

Same issue here. All shares are now giving me access denied errors. I'm just now getting into the debug process.

 

[anodos]

Try clearing the idmap cache. midclt call idmap.clear_idmap_cache. This will stop samba, remove caches, and restart it (service disruption).

 

[Michael Hanna]

Not sure if this helps but I certainly find it interesting. In Windows 10 if I "add a network location" and point it to one of my shares using the freenas IP address/share name I get the access denied errors when I do anything other than view the files. If I "add a network location" and use the freenas hostname/share I get no permission issues... everything works as expected.

 

[ozoo]

Hi
Same issue here (except I can't access the share even when I use the 'add a network location')
Upgrade to 11.3 broke my AD connection, so I installed 11.3 from scratch.
Now AD connection seems to be ok (no errors raised, Domain users listed properly, etc)
I created the SMB share, once again everything seems to be ok
But I keep having permission denied when trying to access the share (even from the domain administrator)

Samba's log keeps spitting messages like

2020/02/06 20:48:02.871318, 0] ../../source3/smbd/uid.c:448(change_to_user_internal)
change_to_user_internal: chdir_current_service() failed!

I'm obviously missing something in the config, but I can't pinpoint it.
Any clues about what's could be missing in the config ? or any troubleshooting tips ?

 

[geoff.jukes]

@ozoo I am having the same issue. Everything was fine on 11.2, but broke on update to 11.3 - but only on one of our servers.
I have the same spam in the samba log - but I believe it abated somewhat after I reset the ACLs on my most problematic dataset.
we have nested datasets, and only some are being problematic.
I have noticed that restarting samba fixes the issue for a while. I’m not sure if the log spam is indicating an issue that eventually overwhelms Samba.

 

[geoff.jukes]

@ozoo as I’m digging around the boards and cross-referencing my dataset ACLs, I’m finding a common theme.
I am assuming that after your rebuild, the ACLs were left unchanged (they’re in the filesystem, not FreeNAS). So rebuilding fixed the AD binding (and name resolving) but not the ACLs themselves.
The most common issue my datasets (now) seem to have, is 2 entries for ‘everyone’, one with some access, and one with none. This may or not be related, but certainly as I am having ‘access denied’ issues, the ACLs seem to be the thing to check.

 

[ozoo]

@ozoo as I’m digging around the boards and cross-referencing my dataset ACLs, I’m finding a common theme.
I am assuming that after your rebuild, the ACLs were left unchanged (they’re in the filesystem, not FreeNAS). So rebuilding fixed the AD binding (and name resolving) but not the ACLs themselves.
The most common issue my datasets (now) seem to have, is 2 entries for ‘everyone’, one with some access, and one with none. This may or not be related, but certainly as I am having ‘access denied’ issues, the ACLs seem to be the thing to check.

Thanks for the follow-up
In the end, I deleted the root pool, recreated it. Recreated the sub pools and the shares, and now it's working magically.
I was just experimenting with freenas so far, and got a bit scared of those non-seamless upgrades. (moving from Windows-based NAS with RAID card)
A lot of people seem to have issues related to Samba and AD then moving to 11.3
Would have been nice if freenas could self-diagnose those sharing issues.

 

[geoff.jukes]

@ozoo No worries. You’ve actually confirmed my suspicions and so I’m going to double check the ACLs.
Regarding the upgrades - this is the first time I’ve had an issue since first installing version 9, many years ago. This update made some big (and overdue) changes to the way permissions are handled. This is likely the source of my issues.
So don’t be too scared. The jump from Windows+RAID to BSD+ZFS is a big one. I’m glad I did it. You will too.

 

[anodos]

Hi
Same issue here (except I can't access the share even when I use the 'add a network location')
Upgrade to 11.3 broke my AD connection, so I installed 11.3 from scratch.
Now AD connection seems to be ok (no errors raised, Domain users listed properly, etc)
I created the SMB share, once again everything seems to be ok
But I keep having permission denied when trying to access the share (even from the domain administrator)

Samba's log keeps spitting messages like

2020/02/06 20:48:02.871318, 0] ../../source3/smbd/uid.c:448(change_to_user_internal)
change_to_user_internal: chdir_current_service() failed!

I'm obviously missing something in the config, but I can't pinpoint it.
Any clues about what's could be missing in the config ? or any troubleshooting tips ?

This typically means that you lack permissions to traverse to the path in question. May be an ACL issue with parent directory.

 

[geoff.jukes]

Yup. I've confirmed that something in the ACLs of the newer server didn't get upgraded/is incompatible with 11.3.

 

[anodos]

Yup. I've confirmed that something in the ACLs of the newer server didn't get upgraded/is incompatible with 11.3.

The default settings for `nfs4:mode` changed between 11.2 and 11.3. See release notes:

The default nfs4:mode was changed from “special” to “simple”. This change is recommended as it synchronizes with Samba defaults and provides a better user experience. If the legacy behavior is required, add the following auxiliary parameter to all SMB shares: nfs4:mode=special. It is important that all shares have the same nfs4:mode setting as they share a common caching backend for SID to ID lookups.

 

[geoff.jukes]

@anodos I'm not sure why only one of the servers is affected. I've also found that if I don't have at least read permissions for everyone@, the Wndows clients cannot enter a location (despite being members of a suitable group with permissions). Any thoughts? I'm testing removing from AD, reapplying ACL, etc

 

[anodos]

@anodos I'm not sure why only one of the servers is affected. I've also found that if I don't have at least read permissions for everyone@, the Wndows clients cannot enter a location (despite being members of a suitable group with permissions). Any thoughts? I'm testing removing from AD, reapplying ACL, etc

General rule of thumb is that ACLs will always behave correctly. I've only seen a couple of actual ACL bugs over the course of the past decade.

You can use wbinfo to confirm gid-to-sid and sid-to-gid mapping for the groups / users that seem problematic. Confirm that the values you see are also consistent with getent output. It might be a caching issue for ID mapping.

 

[geoff.jukes]

@anodos I've just proved, without a doubt, that restarting SMB fixes the "permission denied' issue for a period of time.
I feel like I've hijacked this thread (sorry). Should I create a new one?
Also - why would `everyone@` required? I am a user, in the owning group, with permission to modify the dataset. Without `everyone@` I get a WIndows error. With `everyone@` I am able to browse (but I am unable to write)

 

[anodos]

@anodos I've just proved, without a doubt, that restarting SMB fixes the "permission denied' issue for a period of time.
I feel like I've hijacked this thread (sorry). Should I create a new one?
Also - why would `everyone@` required? I am a user, in the owning group, with permission to modify the dataset. Without `everyone@` I get a WIndows error. With `everyone@` I am able to browse (but I am unable to write)

I'd probably start by verifying that you're actually authenticating as the user you think you are (you can add an aux param "log level = 1 auth_audit:5" to Services->SMB and watch /var/log/samba4/log.smbd, and also verify the SID<->ID mapping.

 

[geoff.jukes]

@anodos I increased the log level, and this is what I see in the log when I try to create a folder:

Code:

[2020/02/06 22:54:38.768671,  2] ../../source3/smbd/service.c:851(make_connection_snum)
  172.16.1.36 (ipv4:172.16.1.36:51561) connect to service working initially as user DOMAIN\geoff.jukes (uid=21389, gid=20513) (pid 10471)
[2020/02/06 22:54:39.676266,  2] ../../source3/smbd/open.c:4056(open_directory)
  open_directory: unable to create partner/New folder. Error was NT_STATUS_ACCESS_DENIED

and getfacl for that location gives me:

Code:

# file: /mnt/tank/import/partner/
# owner: DOMAIN\auto.smb
# group: DOMAIN\asset importer
group:BUILTIN\administrators:rwxpDdaARWcCo-:fd----I:allow
            owner@:rwxpDdaARWcCos:fd----I:allow
            group@:rwxpDdaARWc--s:fd----I:allow
user:DOMAIN\catalog:rwxpDdaARWc--s:fd----I:allow
         everyone@:r-x---a-R-c---:fd----I:allow
         everyone@:--------------:fd----I:allow

and my user account is a member of the `asset importer` group.

 

[geoff.jukes]

@anodos Definitely authenticating as myself:

Code:

[2020/02/06 23:16:39.921812,  4] ../../auth/auth_log.c:751(log_successful_authz_event_human_readable)
  Successful AuthZ: [SMB2,krb5] user [DOMAIN]\[Geoff.Jukes] [S-1-5-21-969874171-2959213616-2054178002-1389] at [Thu, 06 Feb 2020 23:16:39.921701 PST] Remote host [ipv4:172.16.1.36:25725] local host [ipv4:172.16.1.25:445]

 

[Johnny Fartpants]

Just for info, I have also noticed some strangeness/differences with ACL permissions in 11.3 so I am watching this thread very closely. I won't confuse matters with exactly what I've seen as it all sounds very similar but I just wanted to say I think it needs some close attention.

 

[anodos]

@anodos Definitely authenticating as myself:

Code:

[2020/02/06 23:16:39.921812,  4] ../../auth/auth_log.c:751(log_successful_authz_event_human_readable)
  Successful AuthZ: [SMB2,krb5] user [DOMAIN]\[Geoff.Jukes] [S-1-5-21-969874171-2959213616-2054178002-1389] at [Thu, 06 Feb 2020 23:16:39.921701 PST] Remote host [ipv4:172.16.1.36:25725] local host [ipv4:172.16.1.25:445]

SSH into the server, then su DOMAIN\\Geoff.Jukes, cd into the share's connectpath, and try create a new file.