The users on this system are careful and have their umasks set to the very private 0077. However, the users would like to have group specific directories, where files may be copied so as to explicitly share them just among other group members. There may be multiple such share directories though each is specific to a group.

Setting the group sticky bit on a given directory to be used for sharing is not enough. Although setting the sticky bit causes the group ownership to be correct on files placed in the directory, the permissions on said files are often set such that the files can not be read or edited, i.e. can not actually be shared. They just appear in the directory listing. This is because some users either don't think to, or don't know how to, manually make the required group permissions adjustment to allow read and write. We can give them a break on this because users are not admins, after all. acls can be used to specify that a particular group has access to the files in the share directory, independent of what the group permissions would have been without acls. That is the perfect solution, but it is not quite working.

In the following, the shared group is 'customer_gateway' and the example user trying to share a file is 'svw'. As can be seen in the transcript, the svw user is a member of the customer_gateway group. The directory where sharing is to occur is also called 'customer_gateway/'

The following uses acls. I set the group permissions, the default group permissions, the mask and the default mask. It works well for files created in the directory, or for files moved there via cat (or tar), but strangely, not for files that 'cp'ed there:

# rm -r customer_gateway/
# umask
# cat ~/script1

mkdir customer_gateway
chown :customer_gateway customer_gateway/
chmod g+rwx  customer_gateway/
setfacl -m group:customer_gateway:rwX customer_gateway/
setfacl -m d:group:customer_gateway:rwX customer_gateway/
setfacl -m m::rwX customer_gateway/
setfacl -m d:m::rwX customer_gateway/
getfacl customer_gateway
cd customer_gateway
touch cga
cat << EOF > cgb
c g b
ls -l

# . ~/script1
# file: customer_gateway
# owner: root
# group: customer_gateway

total 4
-rw-rw----+ 1 root root 0 Mar  2 20:43 cga
-rw-rw----+ 1 root root 6 Mar  2 20:43 cgb

# su - svw

(note umask is 0077)

> cd /share/customer_gateway/
> groups
svw adm dip video plugdev google-sudoers customer_gateway
> cat >> cga
e f g
> cat > cgc
c g c
> ls -l
total 12
-rw-rw----+ 1 root         root         6 Mar  2 20:44 cga
-rw-rw----+ 1 root         root         6 Mar  2 20:43 cgb
-rw-rw----+ 1 svw svw 6 Mar  2 20:44 cgc
> ls ~/dat
ta  tb  tc
> cat ~/dat/ta > ta
> cp ~/dat/tb tb
> ls -l
total 20
-rw-rw----+ 1 root         root         6 Mar  2 20:44 cga
-rw-rw----+ 1 root         root         6 Mar  2 20:43 cgb
-rw-rw----+ 1 svw svw 6 Mar  2 20:44 cgc
-rw-rw----+ 1 svw svw 4 Mar  2 20:45 ta
-rw-------+ 1 svw svw 4 Mar  2 20:45 tb
> getfacl ta
# file: ta
# owner: svw
# group: svw
group::rwx          #effective:rw-
group:customer_gateway:rwx  #effective:rw-
> getfacl tb
# file: tb
# owner: svw
# group: svw
group::rwx          #effective:---
group:customer_gateway:rwx  #effective:---

What this shows is that when a file is created in the directory then it receives the default permissions and is sharable. But users don't always create their files there, commonly they cp them there.

But doing a copy is the same thing, because to do a copy we must first create a new file. We are talking about a plain copy here, not a preserve permissions copy. It is the same as the following form, which, btw does work and copies a file which will be sharable in the directory independent of its original group permissions:

cat < data.in  > shared/data.out

works just fine, piping through tar also works, but the form

cp data.in shared/data.out

fails. The cated file gets the default mask and default permissions. The cped file preserves its permissions in the acl mask and the group permissions, as though it was a cp -p (but it wasn't), and thus the effective permissions read like the original file, not the what the acls have been set to.

As a second try I ran this experiment with the group sticky bit, chmod g+rwxs, along with the facl changes, and got the exact same results. Although the directory listings are prettier due to the group ownership showing for all shared files. I also ran it with just the group sticky bit being set, without the setfacl. It also had the same result for copied files (so facls look fairly useless for a directory where files are copied in to be shared).

On what basis and with what justification does linux facls distinguish between different forms of creating data? Why force cp to preserve permissions when it hasn't been told to do this? What reason would justify the confusion caused by this distinction between cat and piping through tar working but cp not working? Am I missing a magic incantation that would make this distinction evaporate?

Is this summary correct: facls will allow you to overcome ownership to share files, it will make permissions more permissive than the umask when 'creating' files, unless that creation is due to the cp command and for good reason because ... because why?

  • 1
    What operating system (linux distro and version) and which file system are you using? Would it be OK to make people use cat, maybe via a dedicated shellscript for this purpose?
    – sudodus
    Commented Mar 2, 2020 at 22:00
  • Do you intend that any user in the group can modify or delete any file, or should only the creator have such permissions? In other words only read permissions (and maybe execute permissions) for the other users.
    – sudodus
    Commented Mar 2, 2020 at 23:17
  • 1
    Debian 10. Because file creation works I've been piping copies through tar. I'll package that up as a proj_cp command in /usr/local/bin. However, if a user has to use a special copy command, then one could just go with the group sticky bit without facls and set the permissions. I want to know how to set the acls so that cat tar and cp work. I'm thinking there is a problem with acls with cp, as they are doing the cp -p behavior instead of the cp behavior. I'm looking forward to hearing from permissions experts.
    – user314968
    Commented Mar 3, 2020 at 10:14
  • 1
    Group share is a recurring problem with variations, as you point out. In this instance, software developers have access to the test release directory. It is theirs to muck with. They can work in that directory, push, pull, install in the virtual environment etc. The problem comes when they copy things in from another area they have been working in, and their umasks are not set with group permissions. It is confusing to them because file creation and copy by tar works fine. It is also funny that I have to give them a copy script that just does what cp does. 'acls' they are magic I say LOL
    – user314968
    Commented Mar 3, 2020 at 10:28
  • I am no permissions expert, but I hope that my questions and your answers can help the experts give you relevant answers.
    – sudodus
    Commented Mar 3, 2020 at 13:29

4 Answers 4


All answers so far have given advice on how to deal with sharing file via group directories. Non has answered you main question, I think, which was: Why does cp a b behave as if cp -p a b was specified? The man page does not talk about it, indeed, but texinfo has the details. info coreutils 'cp invocation' shows:

 Preserve the specified attributes of the original files. ...

 In the absence of this option, the permissions of existing
 destination files are unchanged.  Each new file is created with the   <===
 mode of the corresponding source file minus the set-user-ID,          <===
 set-group-ID, and sticky bits as the create mode; the operating
 system then applies either the umask or a default ACL, possibly
 resulting in a more restrictive file mode.

So, if the destination exists, the content is replaced, but the mode bits are not changed. If the destination does not exist, mode bits are copied from source.


This fact of making a directory where users can go into is pretty simple and can easily be done.

  • Firstly you will need to find an appropriate place to make this directory, I reccomend making it under a directory which is accessible to all (for the moment). Use the command sudo mkdir to create your new directory.

  • Secondly you need to make a group, a group is simply a collection of users which are rounded up in order to restrict or access certain parts of a linux system. You may have seen groups when typing the ls -l command which lists something like this:

rwxrwxrwx 3 root admins 4736 Oct 24 12:32 File1.doc

The part that says root is the owner and **admins ** is the group which owns the file. Groups ensure an easy way to allow certain people to view files. To make a group type the "sudo groupadd , this will be the group used for the directory.

  • Once the groups been made you can add users to it which you want to access the directory, by using the following command sudo adduser This will allow you to add users you can verify if the user is in the group with the group command.

Once this is done browse to the directory you created and set the group permission to 7 (rwx) remember you can adjust these to your preferences but 7 gives users of the group full permissions to the directory, you can do this by typing "sudo chmod 770"

Next you need to change the group ownership of the directory, so the group owner of the directory is the group you made, do this with with the following command "sudo chown -R :groupname .

Once this has all been done you can now add whomever you wish to the group and they will have access to copy and share files as long as they are in that specific group to access the directory. Please let me know if you found this helpful !!!!!!

  • Thanks, I clarified the original post to explain why I didn't use this manual approach.
    – user314968
    Commented Mar 3, 2020 at 10:44

I would remove all acl's and just use user and group permissions. Then chmod 777 the folder you want everyone to have access to. Then test your access.

Then chmod 770 the folder test access again.

When this work as it should then add acl's back in one at a time.

If they do not need execute perms you could reduce it even lower to rw*,rx*,*** with chmod 660 foldername

Remember for the period where you have no acl's and chmod 777 permissions your folder will be wide open to all so don't leave it like that.

  • Not everyone, just people in a particular group. I could set the group sticky bit on the directory. The problem is that then users put files in the directory, and the group is correct but they either don't know to, or forget, to set the group access. acls can be used to specify that a particular group has access to the files independent of their group permissions. That is the perfect answer. Problem is that acls have a mask, and cp is clearing the acl mask to match the users umask, so the effective permissions do not allow the files to be read.
    – user314968
    Commented Mar 3, 2020 at 10:32

I tried it. It seems that the umask is clobering the group permissions, as the group permissions are the mask of the ACL. It is blocking all groups and ACLs.

A work around is to make the umask less restrictive. To do this safely you need to add a group for each user, and make this group the default group. (see Why does every user have their own group? ).

This is not ideal, as there is still a case for different umasks (g=rx, and g=rwx). This strategy only removes the need for no group permissions.

  • 1
    Yes, that is what I had done, I set user masks to 007 instead of 077 as a workaround. It isn´t perfect however, as many files still have lesser permissions and get copied in. The thing I hoped to learn here was why cp is behaving this way. It seems to me this should be the cp -p behavior. I had hoped that someone here could explain it.
    – user314968
    Commented Mar 27, 2020 at 0:09

You must log in to answer this question.