Have Samba extended ACLs (https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs#Samba_Extended_ACL_Support) via SMB+WinBind set for a CentOS 7 file server to mount shares on a Windows 10 desktop (specifically, a Citrix VDI desktop). Yet when trying to access some shares (but not all), I see that my user access is denied (getting errors like "The handle is invalid" or "Windows cannot access" for folders and "Access denied" files) even though my test user is part of the AD groups for the shares Security properties (per the docs, https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs#Setting_Share_Permissions_and_ACLs).
When logging into the smb linux server itself, I can see that the output of the groups command shows that the test user is indeed in all of the required AD groups (yet even on the server itself, I cannot access some folders that I ostensibly have AD permissions for (eg. nav to lower level folders or run head -n 10 <filename> on files)).
Eg. I have folders set up as SMB shares like...
/datastore <----share
/data
/dataset1 <----share
...
<data files and folders>
/dataset2 <----share
...
<data files and folders>
/dataset3 <----share
...
<data files and folders>
...and have /datastore, and all the /datastore/data/dataset... folders as smb shares and my test user added to the groups w/ Read access for the shares referring to datastore, dataset1, and dataset2 on the Computer Mgmt UI connecting to the smb server (per the Samba extended ACLs docs). (I found that you need give users NTFS/Security permission for parent level folders if you want to set finer-grained share perms for lower-hierarchy share folders as they need to be able to have access all the way down the path (LMK if this is wrong and could be causing the problems)).
When mounting the datastore share on Windows, I find that my test user can open content in /datastore/data/dataset1 and (as expected) can't open content in /datastore/data/dataset3, but also cannot access /datastore/data/dataset2. (I have triple-checked and do appear to be listed as a member in the AD group that is listed in the share's Security tab).
Anyone with more experience with this have any ideas as to what could be happening? Any more debugging info that this post should contain?
(Note: I posted a similar question here, but was for an almost totally opposite problem (have not yet posted an answer there as this is part of that same testing process, so the exact diagnosis of all these hangups is still unclear))
For reference...
(though I don't think anything is wrong here), my /etc/samba/smb.conf file looks like...
[root@myserver ~]# cat /etc/samba/smb.conf
[global]
security = ads
# password server = adcontrollerserver.myorg.local
# dedicated keytab file = /etc/krb5.keytab
encrypt passwords = yes
log file = /var/log/samba/%m.log
log level = 3
winbind refresh tickets = yes
vfs objects = acl_xattr
map acl inherit = Yes
# the next line is only required on Samba versions less than 4.9.0
# store dos attributes = Yes
winbind use default domain = yes
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
idmap config * : backend = tdb
idmap config * : range = 10000000-10999999
idmap config MYDOMAIN : backend = ad
idmap config MYDOMAIN : schema_mode = rfc2307
idmap config MYDOMAIN : range = 10000-20000
idmap config MYDOMAIN : unix_nss_info = yes
# idmap config MYDOMAIN : unix_primary_group = no
username map = /usr/local/samba/etc/user.map
winbind enum users = yes
winbind enum groups = yes
# Template settings for login shell and home directory
template shell = /bin/bash
template homedir = /home/%U
kerberos method = system keytab
workgroup = MYDOMAIN
realm = MYDOMAIN.LOCAL
winbind offline logon = yes
# all the various share names, eg...
[datastore__data__dataset1]
path = /datastore/data/dataset1
read only = no
.
.
.
and appear to have all the ACLs prerequisites...
[root@myserver ~]# smbd -V
Version 4.9.1
[root@myserver ~]# smbd -b | grep HAVE_LIBACL
HAVE_LIBACL
[root@myserver ~]# cat /etc/samba/smb.conf | grep "vfs objects"
vfs objects = acl_xattr
[root@myserver ~]# cat /etc/samba/smb.conf | grep "map acl inherit"
map acl inherit = Yes
UPDATE:
Tried mounting again today and suddenly started working (can access those previously inaccessible folders and files in accordance with the share's NTFS/Secutiry permissions), IDK why. I will note that in the previous test, I could not Disconnect the share and now is only the second time I tried (thus I suspect that Disconnecting and reconnecting again may have helped (agian, IDK why so if this gives anyone a hunch do LMK)).
Worse still, I cannot retroactively see how samba was processing the access requests to that particular folder when it was denying me because the /var/log/samba/<myclientIP>.log file only contains logs dated from today (wherein I am not currently experiencing the problem).
Will continue to monitor, but if this gives anyone any further hunches about what could have been going on please do LMK.
