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
ls -la /share
andgetfacl /share
)? – Jun 24 '19 at 17:02konstrukteure
groups (one in AD, one in /etc/group) with different group IDs. – András Korn Jun 24 '19 at 21:36-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 ofid ShouldBeAllowedUser
?, for example. Do the GID numbers match? – Jun 25 '19 at 17:53testuser
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