User can cd but can't ls directory

Question

This directory had ACL and UNIX permissions set on it.

I've reset the directory's UNIX and ACL to the minimum, but the user cannot list the contents. Other users with similar group memberships CAN access and list it.

We are using a Samba 4 Active Directory domain. But, again, working and non-working users seem to be set up identically.

root@FileServer:/share# ls -lad ./Konstruktion/
drwxrwx--x 16 superuser konstrukteure 22 Jun 24 17:49 ./Konstruktion/
root@FileServer:/share# getfacl ./Konstruktion/
# file: Konstruktion/
# owner: superuser
# group: konstrukteure
user::rwx
group::rwx
other::--x

With a known-good user:

root@ClientComp:~# su - gooduser
You're using Valerij-enabled extensions of MiraculiX
gooduser@ClientComp:~$ groups
domain users BUILTIN+users staff konstrukteure vgroup hgroup gooduser dialout video
gooduser@ClientComp:~$ cd /share/Konstruktion/
gooduser@ClientComp:/share/Konstruktion$ ls -la
total 3442
drwxrwx--x 16 superuser konstrukteure      22 Jun 24 17:49  .
drwxrwx--x 70 superuser staff              82 Jun  3 10:08  ..
drwxrwxr-x 12 someuser      konstrukteure      16 Apr  9 11:44  Dokumente
(...snip...)
-rw-rwx---  1 someuser     staff             261 Jun 12 16:50  std.out
gooduser@ClientComp:/share/Konstruktion$ 

ShouldBeAllowedUser should have permissions, but doesn't:

root@ClientComp:~# su - ShouldBeAllowedUser
ShouldBeAllowedUser@ClientComp:~$ groups
domain users BUILTIN+users staff konstrukteure ShouldBeAllowedUser dialout video
ShouldBeAllowedUser@ClientComp:~$ cd /share/Konstruktion
ShouldBeAllowedUser@ClientComp:/share/Konstruktion$ ls -la
ls: cannot open directory '.': Permission denied
ShouldBeAllowedUser@ClientComp:/share/Konstruktion$ 

ShouldBeBlockedUser shouldn't have permissions and doesn't:

root@ClientComp:~# su - ShouldBeBlockedUser
-su: /opt/ros/indigo/setup.bash: No such file or directory
ShouldBeBlockedUser@ClientComp:~
~$ groups
domain users BUILTIN+users staff vgroup hgroup ShouldBeBlockedUser dialout video
ShouldBeBlockedUser@ClientComp:~
~$ cd /share/Konstruktion
ShouldBeBlockedUser@ClientComp:/share/Konstruktion
Konstruktion$ ls -la
ls: cannot open directory '.': Permission denied
ShouldBeBlockedUser@ClientComp:/share/Konstruktion
Konstruktion$ 

I'm not sure where to look for the issue. Can someone offer guidance?

EDITS

@Isaac What are the permissions of /share (output of ls -la /share and getfacl /share)?

root@FileServer:/# ls -ladn /share/
drwxrwsr-x+ 20 2126 2133 30 Jun 17 13:56 /share/
root@FileServer:/# getfacl /share
getfacl: Removing leading '/' from absolute path names
# file: share
# owner: superuser
# group: staff
# flags: -s-
user::rwx
group::rwx
group:no-common-share-access:---
mask::rwx
other::r-x
default:user::rwx
default:group::rwx
default:group:no-common-share-access:---
default:mask::rwx
default:other::r-x

@András Korn Check the numeric IDs on the group memberships and the directory. Maybe you have two konstrukteure groups (one in AD, one in /etc/group) with different group IDs.

I checked this on two client computers. They all seem to have the same GID, and neither machine has a local "konstrukteure"

ShouldBeAllowedUser@ClientComp:~$ id
uid=127427(ShouldBeAllowedUser) gid=1513(domain users) groups=1513(domain users),1001(BUILTIN+users),2133(staff),2574(konstrukteure),127427(ShouldBeAllowedUser),128080(dialout),128081(video)

root@FileServer:/share# ls -ladn Konstruktion/
drwxrwx--x 16 2126 2574 22 Jun 24 17:49 Konstruktion/

root@ClientComp:/share# ls -ladn Konstruktion/
drwxrwx--x 16 2126 2574 22 Jun 24 17:49 Konstruktion/
root@ClientComp:/share# grep -i "konst" /etc/group
(no output)

root@ClientComp2:/share# ls -ladn Konstruktion/
drwxrwx--x 16 2126 2574 22 Jun 24 17:49 Konstruktion/
root@ClientComp2:/share# grep -i "konst" /etc/group
(no output)

Additional update
If I set the other to r-x (Not just r-- and not just --x) the user can then list the contents but still cannot write a new file/directory.

Of course we want neither of these. We DO want members of "konstrukteure" group to be able to list, read, and write. We DO NOT want other to be able to do anything.

Again, it seems like his effective identity is being seen as other, at least as it relates to this directory.

ALSO, using setfacl to extend the specific user full permissions does nothing (he is still locked out in the same way).

I.e.

setfacl -m "u:ShouldBeAllowedUser:rwx" ./Konstruktion