I'm trying to create a segregated workspace for multiple groups, each group member should only be able to read, write and view their associated shared folder.

I've created 2 user groups groupATeam and groupBTeam to handle the permissions of users. I've also assigned the group permissions to the relevant project folders groupA and groupB.

#Check project folder permissions
admin@computer:/folder/data$ ls -al /folder/data | grep groupA
drwsrws--x 2 root groupATeam 4096 Jun 24 11:56 groupA
admin@computer:/folder/data$ ls -al /folder/data | grep groupB
drwsrws--- 2 root groupBTeam   4096 Jun 24 11:38 groupB

For the admin user who is in both groups, I can access both folders and subsequently read and write without issue.

#Check groups
admin@computer:/folder/data$ getent group groupATeam
admin@computer:/folder/data$ getent group groupBTeam

#Check admin can access and write to groupA folder
admin@computer:/folder/data$ cd groupA/
admin@computer:/folder/data/groupA$ ls
admin@computer:/folder/data/groupA$ cd ..

#Check admin can access groupB folder 
admin@computer:/folder/data$ cd groupB/
admin@computer:/folder/data/groupB$ ls

People in the groupA also seem to have the correct permissions, being able to access, read and write to their folder but not groupBs folder.

# Worker 3 is part of groupA team and therefore should only be able to interact with groupA folder but not groupB
worker_3@computer:~$ cd /folder/data/groupA/
worker_3@computer:/folder/data/groupA$ touch test_file101.txt
worker_3@computer:/folder/data/groupA$ ls
test_file.txt  test_file101.txt 
worker_3@computer:/folder/data/groupA$ vim test_file.txt

#Check non group member can acccess restricted groupB folder
worker_3@computer:~$ cd /folder/data/groupB/
bash: cd: /folder/data/groupB/: Permission denied
# This is the correct behaviour I'm looking for

The issue seems to be with users of the groupBTeam.

# Worker 1 is part of groupB team and therefore should only be able to interact with groupB folder but not groupA
worker_1@computer:/folder/data$ cd groupB/
worker_1@computer:/folder/data/groupB$ ls
worker_1@computer:/folder/data/groupB$ touch test_file101.txt
worker_1@computer:/folder/data/groupB$ ls
test_file.txt  test_file101.txt 

worker_1@computer:~$ cd /folder/data/groupA/    #This shouldn't work
worker_1@computer:/folder/data/groupA$ ls
ls: cannot open directory '.': Permission denied
worker_1@computer:/folder/data/groupA$ cd ..

# Incorrect behavior, I can access the groupA folder even though worker_1 isn't part of 
# this group

Members of groupBTeam can access groupA folder, which isnt the desired behavior.

Can anyone explain why I'm not getting the expected behaviour and how I can rectify it?

Fore refence, I followed these steps to set up the groups and folder permissions - https://www.tutorialspoint.com/how-to-create-a-shared-directory-for-all-users-in-linux

  • 1
    Apart from using the build in permission system you also might be interested to get in touch with ACL Access Control Lists Commented Jun 27, 2022 at 10:55
  • 1
    See my updated answer. I changed it to keep the set-gid and added an option to not recurse into the directory if it's not wanted. Either of the first two options will do what you need. I added the second one in case you actually want it to recurse. It's up to you. Commented Jun 27, 2022 at 11:59
  • @AlexOnLinux Thanks for the pointer, will definitely get to grips with ACL's
    – Zizi96
    Commented Jun 27, 2022 at 13:45

1 Answer 1


You have the execute bit set for others on the groupA directory:

drwsrws--x 2 root groupATeam 4096 Jun 24 11:56 groupA

That allows everyone to traverse the directory regardless of group membership. If you'll notice, there are no bits set for others on the groupB directory where members of groupATeam can't access it:

drwsrws--- 2 root groupBTeam   4096 Jun 24 11:38 groupB

To get what you want, remove the execute bit from the groupA directory with either of the following commands

chmod 2770 /path/to/groupA

chmod o-x /path/to/groupA

Neither the users in groupBTeam or anyone else will be able to access it.

If you want it to affect everything inside the directory including files:

chmod -R 2770 /path/to/groupA

chmod -R o-x /path/to/groupA
  • 2
    @A.B I saw the get-gid bit later and added 2770 and an option without -R. If no one other than the group is meant to access the directory, then removing permission bits recursively from others inside of the directory won't matter but it's decided otherwise, one can use the second option. Commented Jun 27, 2022 at 11:56
  • @NasirRiley I was actually going to ask about Setgid bit but you beat me to it with your update. i now got the functionality I'm after, at the moment the directories are empty but the recursive behavior is useful to know!
    – Zizi96
    Commented Jun 27, 2022 at 13:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .