2

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
  • What are the permissions of /share (output of ls -la /share and getfacl /share)? –  Jun 24 '19 at 17:02
  • @Isaac oh, huh, there are three users there. I only noticed the first and the last. – muru Jun 24 '19 at 20:00
  • 3
    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. – András Korn Jun 24 '19 at 21:36
  • (1) You have the -s- permissions set on the /share directory, that makes the directory owner to be inherited to newly created directories. That doesn't affect nor solve your problem (I don't see a problem in the permissions of that directory), just worth noting (2) You've checked that the filesystem has some GID numbers assigned to the directories/files, but you have not checked what the number(s) of the users/groups is. What's the output of id ShouldBeAllowedUser?, for example. Do the GID numbers match? –  Jun 25 '19 at 17:53
  • @Issac Sorry for being unclear. Yes, the UID and GID match. It seems to be something about the account. Last night I created a new testuser account in the domain, and configured it with the same groups - and it worked fine. I've solved the issue by just creating a new user and I'll t5ransfer ownership of all the files. But I would like to find out why this bug happened. – BurningKrome Jun 26 '19 at 06:54

0 Answers0