I think ACLs are sporadically supported in various ways within NFS. See this article on the NFS project's website.
If this isn't the issue, then I'd be extremely suspicious of cp
. I seem to recall a Q&A regarding the command cp
not fully copying the ACLs irregardless of the targeted mount type.
I believe it was this U&L Q&A titled: Using setfacl to allow group members to write to any file in a directory which led me to this SF Q&A titled: Why does cp not respect ACLs?.
Ironically our own @Gilles wrote an answer on that SF Q&A which explains why cp
doesn't support the propagation of ACLs. I believe this is still the current situation!
excerpt from @Gilles answer
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 foo/baz.
Example
I setup the following file, afile
and added an ACL to it.
$ touch afile
$ setfacl -m user:sam:rwx,group:users:rwx afile
We now have:
$ getfacl afile
# file: afile
# owner: root
# group: root
user::rw-
user:sam:rwx
group::r--
group:users:rwx
mask::rwx
other::r--
When I copy these files to an NFSv3 share:
$ cp afile ~sam/
$ getfacl ~sam/afile
getfacl: Removing leading '/' from absolute path names
# file: home/sam/afile
# owner: root
# group: root
user::rw-
group::rwx
other::r--
ACLs were lost. Trying to use the --preserve
switches to cp
:
$ cp --preserve afile ~sam/
cp: preserving permissions for `/home/sam/afile': Operation not supported
cp: preserving ACL for `/home/sam/afile': Operation not supported
Enabling ACL on NFS
Enabling ACL on the NFS mount seem to have no effect either:
mulder:/export/r1/home/sam on /home/sam type nfs (rw,intr,tcp,nfsvers=3,acl,rsize=16384,wsize=16384,addr=192.168.1.1)
$ cp --preserve afile ~sam/
cp: preserving permissions for `/home/sam/afile': Operation not supported
cp: preserving ACL for `/home/sam/afile': Operation not supported
Same HDD worked
Interestingly the --preserve
switch did work when copying the file locally on the same EXT4 mounted drive.
$ cp --preserve afile afile2
$ getfacl afile2
# file: afile2
# owner: root
# group: root
user::rw-
user:sam:rwx
group::r--
group:users:rwx
mask::rwx
other::r--
Path forward?
In my research and experimentation it would appear that anything below NFSv4 does not support ACLs. The cp
command seems able to preserve the ACLs as long as the underlying filesystem supports ACLs.
I found this article: Projects: NFS Version 4 Open Source Reference Implementation, which discusses the use of ACLs within NFSv4. So I would expect that copying ACLs to an NFSv4 share might be possible, I don't believe it's possible using NFSv2 or NFSv3 though.
References
--preserve
switch tocp
? – slm Nov 13 '13 at 23:02cp --perserve=all
andcp --perserve=xattr
. Same result. I'm a bit confused by how this is supposed to work. Source file has permissions-rw-------
and those seem to be taking precedence. I want the ACL to override that. Is there a way to tellcp
to ignore the source attributes and permissions and only preserve the extended attributes? From your comments that seems to be what I'm looking to do. – embedded.kyle Nov 14 '13 at 01:31cp
command doesn't propagate EAs (Extended Attributes) of which ACLs is a part of. You could try using another method for copying the files viarsync
. – slm Nov 14 '13 at 01:47