A common way to set up a directory for file sharing within a group, is:

$ mkdir foo
$ chgrp felles foo
$ chmod g+ws foo
$ setfacl -m group:felles:rwx foo
$ setfacl -dm group:felles:rwx foo

This ensures that any files created in foo is readable and writable by the group felles:

$ umask
$ echo hi > foo/bar
$ ls -l foo
total 4
-rw-rw-r--+ 1 bhm felles 3 2010-09-23 00:18 bar

However, if you copy a file into foo, the default ACLs are not applied:

$ echo you > baz
$ cp baz foo/
$ ls -l foo
total 8
-rw-rw-r--+ 1 bhm felles 3 2010-09-23 00:18 bar
-rw-r--r--+ 1 bhm felles 4 2010-09-23 00:19 baz
$ getfacl foo/baz
# file: foo/baz
# owner: bhm
# group: felles
group::rwx          #effective:r--
group:felles:rwx        #effective:r--

Why does this happen, and is there a way around it?

(Moving a file into the directory does not respect either ACLs or group ownership, but I can understand why: you might not want the permissions of a file to change simply because you change its name.)


6 Answers 6


If cp creates the destination file, it replicates the permissions of the source file, except for the bits that are set in the umask. This is standard behavior (see e.g. step 3.b in the Single Unix v3 (POSIX 2001) specification.

Why was cp designed this way? Because there are many cases where this behavior is desirable, for example preserving a file's privacy when the original permissions are restrictive, and preserving executability is almost always the right thing to do. It is however unfortunate that not even GNU cp has an option to turn this behavior off.

Most copy tools (e.g. pax, rsync) behave in the same way. You can ensure the file will be created with the default permission by decoupling the source from the destination, for example with cat <baz >foo/baz.

  • 1
    Well, that at least explains the motivation for it. (Strange, though, that the group ownership is allowed to change to "felles", giving potentially more people read access to the file.)
    – bhm
    Commented Sep 23, 2010 at 22:07
  • I would like to point out that the problem is real. Can you help us solve it? unix.stackexchange.com/questions/711319 Commented Jul 26, 2022 at 14:27

Well, a three-year old and more question but still relevant. For future readers, I want to add that it is expected that mv, cp commands do not follow destination directory's ACL. Gilles's answer is all fine but the last sentence. The better way to apply the destination's ACL to the copied/moved file is the way mentioned here:


In case the link is broken in future, I paste the content here:

getfacl <file-with-acl> | setfacl -f - <file-with-no-acl>

copy ACL of one file to another using getfacl and setfacl

WARNING: Existing ACL will get lost.


I had a similar problem with rsynced files lacking the proper default ACLs in the target subdirectory. Cp does not have a way of setting the permissions on the target. But, rsync does, using the --chmod=ugo=rwx flag. See my answer here.


You need to use -p or --preserve with cp.

From man 5 acl:


 On a system that supports ACLs, the file utilities ls(1), cp(1), and
 mv(1) change their behavior in the following way:

     For files that have a default ACL or an access ACL that contains more
     than the three required ACL entries, the ls(1) utility in the long
     form produced by ls -l displays a plus sign (+) after the permission

     If the -p flag is specified, the cp(1) utility also preserves ACLs.
     If this is not possible, a warning is produced.

       The mv(1) utility always preserves ACLs. If this is not possible, a
     warning is produced.

 The effect of the chmod(1) utility, and of the chmod(2) system call, on

For reverse behavior, GNU coreutils provides the --no-preserve flag. This is the default behavior but sometimes it's useful to specify particular attributes to preserve or not preserve.

              preserve the specified attributes

              don't preserve the specified attributes
       ATTR_LIST is a comma-separated list of attributes. Attributes are
       'mode' for permissions (including any ACL and xattr permissions),
       'ownership' for user and group, 'timestamps' for file timestamps,
       'links' for hard links, 'context' for security context, 'xattr'
       for extended attributes, and 'all' for all attributes.
  • 8
    Not exactly. He wants the file to have the same permission as the target folder.
    – sdot257
    Commented Sep 22, 2010 at 23:35
  • 1
    This answer should not have any thumbs up. The OP was not asking how to make the cp command preserve a files permissions. The OP was asking why ACLs are not applied to the copy of the file that the cp command made. Commented Apr 1, 2023 at 17:03
  • @FlexMcMurphy, the answer is fixed, so thumbs up are valid now. Though, I'm not sure on the default behavior. My current Ubuntu on WSL has opposite default and requires --no-preserve flag. I haven't found out the reason yet Commented Jun 18 at 16:25

The ACLs are propagating correctly, but the default mask doesn't seem to be correct. You probably want your default mask to be rwX.

setfacl -dm m::rwX foo

If that doesn't work, please post the ACL for foo.

  • That did not work. The ACL for foo (both prior and after your command) is# file: foo # owner: bhm # group: felles # flags: -s- user::rwx group::rwx group:felles:rwx mask::rwx other::r-x default:user::rwx default:group::rwx default:group:felles:rwx default:mask::rwx default:other::r-x
    – bhm
    Commented Sep 23, 2010 at 22:04

From what I see you are the owner of the files (bhm) before and after the cp. As the directory listing shows the owner has read and write access!

  • 1
    Perhaps I was unclear: I want the group ("felles") to be able to (read and) write the file.
    – bhm
    Commented Sep 23, 2010 at 21:57

You must log in to answer this question.

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