Samba extended ACLs restricting user even though they are in an authorized AD group for the share?

Have Samba extended ACLs (https://wiki.samba.org/index.php/Set...ed_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/Set...sions_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...
Code:/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?

----------------------------------------

For reference...

(though I don't think anything is wrong here), my /etc/samba/smb.conf file looks like...
Code:[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...

Code:[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