3

I have an Arch Linux box that has a folder from an Ubuntu server mounted via NFS. I've set up an Access Control List on the folder on the server such that any new files should have their permissions set -rwx-r-x---.

user1@ubuntu:~$ getfacl home/user2/shared/
# file: home/user2/shared/
# owner: user2
# group: remoteusers
user::rwx
group::r-x
other::---
default:user::rwx
default:user:user2:rwx
default:group::r-x
default:group:remoteusers:r-x
default:mask::rwx
default:other::---

If I create a file the permissions are set fine:

userA@arch:~$ touch ubuntuNFS/test.txt

userA@arch:~$ ls -la ubuntuNFS
-rw-r----- 1 ########## ##########    0 Nov 13  2013 test.txt

But if I copy a file, the group is not given any permissions:

userA@arch:~$ cp Videos/video.mp4 ubuntuNFS/

userA@arch:~$ ls -la ubuntuNFS
-rw------- 1 ########## ##########    0 Nov 13  2013 video.mp4
-rw-r----- 1 ########## ##########    0 Nov 13  2013 test.txt

Why isn't cp obeying the ACL defaults?

  • What if you use the --preserve switch to cp? – slm Nov 13 '13 at 23:02
  • @slm Tried cp --perserve=all and cp --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 tell cp 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:31
  • Yeah that wasn't suppose to work was the point. The cp command doesn't propagate EAs (Extended Attributes) of which ACLs is a part of. You could try using another method for copying the files via rsync. – slm Nov 14 '13 at 01:47

2 Answers2

3

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

slm
  • 369,824
  • 1
    Giving you the accept for leading me to ServerFault and suggesting rsync. Found this over at ServerFault: http://serverfault.com/questions/455111/rsynced-files-not-getting-proper-acl Which gives an example of using the --chmod flag of rsync to achieve the desired result. However the -a flag didn't handle the group permissions properly so I used -rt instead. So it looks like ACLs are of no use in this particular situation. – embedded.kyle Nov 15 '13 at 02:03
1

A possible solution is to force the umask to preserve the ACL.

Giving to the users who has to share the same group and owner rights,and setting the SGID bit in the shared folder, enforcing the correct rights to the folder in order to permit the sharing by the group.

In other words, doing the same configuration to share a folder by a group as if no ACL is in effect.

xae
  • 2,021
  • So you're suggesting not to use ACLs at all then and just standard unix groups & permissions, right? – slm Nov 13 '13 at 22:56
  • 1
    The root of the problem is that when ACL's and umask disagrees umask wins. – xae Nov 13 '13 at 22:59
  • I diagree, the problem for the OP is that the ACL metadata is treated as a 2nd class citizen and the tools are not keeping it together with his data. At the very least the tools should provide you an option to keep or discard the data, cp just isn't complying. If I'm wrong, then why does cp have a --preserve switch to allow/discard that particular metadata? – slm Nov 13 '13 at 23:01
  • cp has the flag -p, if you use it the command tries to preserve the ACL's and warns if not possible. – xae Nov 13 '13 at 23:03
  • There are 3 levels to EAs (Extended Attributes), ACLs is one of them. Need to make sure that the version he's using can contend with all of them. From the cp man: "... if possible additional attributes: context, links, xattr, all". – slm Nov 13 '13 at 23:08
  • Tried cp -p. No warnings were given and the result was the same. – embedded.kyle Nov 14 '13 at 01:19