ACL defaults not being obeyed on copy over NFS

Question

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?

Answer 1

I think ACLs are sporadically supported in various ways within NFS. See this article on the NFS project's website.

• http://www.linux-nfs.org/wiki/index.php/ACLs

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

• Access Control Lists in Linux

Answer 2

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.