I am having trouble with setting up a system for multiple users accessing the same set of files. I've read tuts and docs around and played with ACLs but haven't succeeded yet.


Have multiple users, for example, user1 and user2, which is belong to a group called sharedusers. They must have all WRITE permission to a same set of files and directories, say underlying in /userdata/sharing/.

I have the folder's group set to sharedusers and SGID to have all newly created files/dirs inside set to same group.

ubuntu@home:/userdata$  ll
drwxr-sr-x  2 ubuntu sharedusers 4096 Nov 24 03:51 sharing/

I set ACLs for this directory so I can have permission of sub dirs/files inheritted from its parents.

ubuntu@home:/userdata$  setfacl -m group:sharedusers:rwx sharing/
ubuntu@home:/userdata$  setfacl -d -m group:sharedusers:rwx sharing/

Here's what I've got:

ubuntu@home:/userdata$   getfacl sharing/
# file: sharing/
# owner: ubuntu
# group: sharedusers
# flags: -s-

Seems okay as when I create new folder with new files inside and the permission is correct.

ubuntu@home:/userdata/sharing$ mkdir a && cd a
ubuntu@home:/userdata/sharing/a$ touch a_test
ubuntu@home:/userdata/sharing/a$  getfacl a_test 
# file: a_test
# owner: ubuntu
# group: sharedusers
group::r-x                  #effective:r--
group:sharedusers:rwx       #effective:rw-

As you can see, the sharedusers group has effective permission rw-.

HOWEVER, if I have a zip file, and use unzip -q command to unzip the file inside the folder sharing, the extracted folders don't have group write permisison. Therefore, the users from group sharedusers cannot modify files under those extracted folders.

ubuntu@home:/userdata/sharing$  unzip -q Joomla_3.0.2-Stable-Full_Package.zip 
ubuntu@home:/userdata/sharing$  ll
drwxrwsr-x+  2 ubuntu sharedusers    4096 Nov 24 04:00 a/
drwxr-xr-x+ 10 ubuntu sharedusers    4096 Nov  7 01:52 administrator/
drwxr-xr-x+ 13 ubuntu sharedusers    4096 Nov  7 01:52 components/

You an spot the difference in permissions between folder a (created before) and folder administrator extracted by unzip. And the ACLs of a files inside administrator:

ubuntu@home:/userdata/sharing$  getfacl administrator/index.php 
# file: administrator/index.php
# owner: ubuntu
# group: ubuntu
group::r-x                #effective:r--
group:sharedusers:rwx     #effective:r--

It also has ubuntu group, not sharedusers group as expected.

Could someone please explain the problem and give me advice? Thank you in advance!

1 Answer 1


This behavior is the ACL_MASK at work. Looking at the index.php file, it does theoretically get the intended permission group:sharedusers:rwx, but effectively another one #effective:r--. This is because the theoretic value gets XOR'd with the mask::r-- to give the effective one, which is what you see with ls -l (or ll).

Now the ACL_MASK of mask::r-- is in fact a security feature of ACL, keeping you from giving access where you didn't intend to: When adding an existing file (as opposed to creating a new one), ACL sets the ACL_MASK to the former value of the file, which in this case was r--.

This isn't limited to unzip. This applies whenever you add a file as opposed to create it. You could try cp or tar for example, and would end up with the same result.

In fact the documentation (man 5 acl) states in the paragraph OBJECT CREATION AND DEFAULT ACLs that the default values only apply for object created with any of the following system calls: creat(), mkdir(), mknod(), mkfifo(), or open().

Therefore I can't give you a good solution, as you won't be able to use the ACL default mechanism for what you're doing.

  • Thank you @aldavud so much. That explains the case. In fact, I should have read the doc more careful. It helps me understand the "strange" and examine some workarounds for the scenario as it would be on my own control. Thanks again!
    – Ngoc Pham
    Nov 28, 2012 at 0:35
  • 3
    What is the difference between "adding" and "creating"? Which system call do you think that cp and tar use? I'm pretty sure that cp and tar use open() or creat(). The reason that the mask is restrictive is that cp/tar supply a more restricted mode argument to open() and/or change the permissions afterwards with chmod()/fchmod() (the group perms are mapped to the mask).
    – pelle
    Oct 15, 2014 at 8:11

You must log in to answer this question.

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