Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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
0022
$ 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
user::rw-
group::rwx          #effective:r--
group:felles:rwx        #effective:r--
mask::r--
other::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.)

share|improve this question
    
serverfault.com/a/452678/46333 this answer contains a good explanation. –  Kaan Dec 28 '13 at 9:41

7 Answers 7

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.

share|improve this answer
    
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 Sep 23 '10 at 22:07

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.

share|improve this answer
    
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 Sep 23 '10 at 22:04

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

share|improve this answer

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:

http://www.commandlinefu.com/commands/view/4281/copy-acl-of-one-file-to-another-using-getfacl-and-setfacl

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.

share|improve this answer

Is your filesystem mounted with the "ACL" option enabled?

/dev/sda4        /wherefolderislocated         ext3        defaults,acl     1   2

If not, make the change then remount.

mount -o remount /wherefolderislocated
share|improve this answer
    
It was mounted with the acl option, yes. –  bhm Sep 23 '10 at 22:05

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!

share|improve this answer
    
Perhaps I was unclear: I want the group ("felles") to be able to (read and) write the file. –  bhm Sep 23 '10 at 21:57

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

From man 5 acl:

CHANGES TO THE FILE UTILITIES

 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
     string.

 ·   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
 the access ACL is described in CORRESPONDENCE BETWEEN ACL ENTRIES AND
 FILE PERMISSION BITS.
share|improve this answer
    
Not exactly. He wants the file to have the same permission as the target folder. –  luckytaxi Sep 22 '10 at 23:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.