设置组内文件共享目录的常用方法是：
$ mkdir foo $ chgrp felles foo $ chmod g+ws foo $ setfacl -m group:felles:rwx foo $ setfacl -dm group:felles:rwx foo 这可以确保在foo创build的任何文件都可以被组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
但是，如果将文件复制到foo ，则不应用默认ACL：
$ 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--
为什么会发生这种情况，有没有办法解决这个问题？
（ 将文件移动到目录中并不尊重ACL或组的所有权，但我可以理解为什么：您可能不希望文件的权限因为您更改其名称而改变。）
如果cp创build目标文件，它会复制源文件的权限，除了在umask中设置的位。 这是标准行为（参见例如Single Unix v3（POSIX 2001）规范中的步骤3.b。
为什么cp是这样devise的？ 因为在很多情况下这种行为是可取的，例如在原始权限是限制性的情况下保留文件的隐私，并且保持可执行性几乎总是正确的。 然而不幸的是，甚至连GNU cp都没有closures这个行为的选项。
大多数复制工具（例如pax，rsync）的行为方式都是一样的。 您可以通过将源文件与目标文件解耦，例如用cat <baz >foo/baz来确保文件的默认权限。
那么，一个三岁多的问题，但仍然相关。 对于将来的读者，我想补充一点，预计mv，cp命令不会跟随目标目录的ACL。 吉勒的答案都很好，但最后一句话。 将目标ACL应用于复制/移动文件的更好的方法是这里提到的方法：
如果将来链接断开，我在这里粘贴内容：
getfacl <file-with-acl> | setfacl -f - <file-with-no-acl>
使用getfacl和setfacl将一个文件的ACL复制到另一个文件
警告：现有ACL将会丢失。
我有一个rsynced文件在目标子目录中缺less正确的默认ACL的类似问题。 Cp没有设置目标权限的方法。 但是，rsync使用--chmod=ugo=rwx标志。 在这里看到我的答案。
ACL正确传播，但默认掩码似乎不正确。 你可能希望你的默认掩码是rwX。
setfacl -dm m::rwX foo
如果这不起作用，请发布foo的ACL。
您的文件系统是否启用了“ACL”选项？
/dev/sda4 /wherefolderislocated ext3 defaults,acl 1 2
如果没有，则更改然后重新安装。
mount -o remount /wherefolderislocated
从我看到你是cp之前和之后的文件所有者（bhm）。 由于目录列表显示所有者具有读取和写入访问权限！
您需要使用-p或--preserve与cp 。
从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 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.