Using NFSv4 ACLs on Linux

Question

I have successfully set up an NFSv4 client and server, roughly following the guide at Setting Up NFS HOWTO. Both are running Ubuntu Linux 14.04. This is a small test environment without complicated authentication; the two servers just use the same passwd file. Everything seems to be working correctly; files are visible on the client, and permissions/user IDs are correct.

Now I would like to use NFSv4 ACLs to control access to the files on the NFSv4 server. I installed the requisite command-line tools on the client, and I am able to see something that looks like an NFSv4 ACL:

$ nfs4_getfacl .
A::OWNER@:rwaDxtTcCy
A::GROUP@:rxtcy
A::EVERYONE@:rxtcy

However, while I can get the ACL list just fine, I can't set any ACLs. Every attempt results in an Invalid argument error from setxattr.

$ nfs4_setfacl -a A::OWNER@:rxtncy .
Failed setxattr operation: Invalid argument

I used strace to see what was going on. According to the sparse documentation I've been able to find, NFSv4 ACLs are stored as binary XDR data in an extended attribute called system.nfs4_acl on the file. And sure enough, that's what's happening; setxatt is returnin EINVAL.

getxattr("/primary/home/rstudiouser", "system.nfs4_acl", 0x0, 0) = 80
getxattr("/primary/home/rstudiouser", "system.nfs4_acl", "\x00\x00\x00\x03\x00\x00\x00\x00\x00\x00\x00\x00\x00\x16\x01\xe7\x00\x00\x00\x06OWNER@\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x12\x00\xa1\x00\x00\x00\x06GROUP@\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x12\x00\xa1\x00\x00\x00\x09EVERYONE@\x00\x00", 80) = 80
setxattr("/primary/home/rstudiouser", "system.nfs4_acl", "\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x00\x00\x12\x00\xa9\x00\x00\x00\x06OWNER@\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x16\x01\xe7\x00\x00\x00\x06OWNER@\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x12\x00\xa1\x00\x00\x00\x06GROUP@\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x12\x00\xa1\x00\x00\x00\x09EVERYONE@\x00\x00", 104, XATTR_REPLACE) = -1 EINVAL (Invalid argument)

So, why is setxattr failing? Extended attributes are enabled on the NFSv4 server:

$ sudo tune2fs -l /dev/sda1
tune2fs 1.42.9 (4-Feb-2014)
...
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file 
uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
...

And the client is certainly using the NFSv4 protocol; using mount to show the mounted drives:

$ mount
...
192.168.55.103:/primary/home on /primary/home type nfs4 (rw,rsize=8192,wsize=8192,timeo=14,intr,nfsvers=4,acl,addr=192.168.55.103,client
addr=192.168.55.101)
...

I tried flipping all the debug flags on nfsd to see if that would yield a useful log.

$ sudo rpcdebug -m nfsd -s all

It does confirm that the server is receiving the request to set the attribute.

Apr  7 20:21:49 vagrant-ubuntu-trusty-64 kernel: [73465.567892] nfsd_dispatch: vers 4 proc 1
Apr  7 20:21:49 vagrant-ubuntu-trusty-64 kernel: [73465.567909] nfsv4 compound op #1/2: 22 (OP_PUTFH)
Apr  7 20:21:49 vagrant-ubuntu-trusty-64 kernel: [73465.567915] nfsd: fh_verify(36: 01070001 001c0002 00000000 acf697e6 a847b405 c98a638b)
Apr  7 20:21:49 vagrant-ubuntu-trusty-64 kernel: [73465.567929] nfsv4 compound op ffff88003c2f6080 opcnt 2 #1: 22: status 0
Apr  7 20:21:49 vagrant-ubuntu-trusty-64 kernel: [73465.567932] nfsv4 compound op #2/2: 34 (OP_SETATTR)
Apr  7 20:21:49 vagrant-ubuntu-trusty-64 kernel: [73465.567938] nfsd: fh_verify(36: 01070001 001c0002 00000000 acf697e6 a847b405 c98a638b)
Apr  7 20:21:49 vagrant-ubuntu-trusty-64 kernel: [73465.567978] nfsv4 compound op ffff88003c2f6080 opcnt 2 #2: 34: status 22

What's "status 22"? Why, 22 = EINVAL, Invalid Argument, which is what setxattr is returning on the client. Unfortunately it doesn't appear to reveal anything about why the argument is considered invalid.

Some other things I've tried:

1. One possibility is that the server thinks the ACL is malformed. To check for this, I used nfs4_setfacl -e ., which opens the existing ACL in a text editor for manipulation. Saving the file without changes still produces an ACL that results in Invalid argument when applied.

2. User ID mapping is another common problem with NFSv4. I have validated that the user IDs are lined up correctly and that file ownership/mode bits are correct from the NFSv4 client's viewpoint. I've also tried creating a domain for NFSv4 by setting Domain = localdomain in /etc/idmapd.conf on both servers, to no effect.

If you use NFSv4 ACLs on Linux-based NFS servers, I'd be curious to hear from you; I found lots of tutorials for setting up NFSv4 itself (see link at the top of this tirade), but virtually none mention the use of ACLs.

Answer 1

For what it's worth, I finally gave up on this effort after a few more stabs in the dark, which mostly involved trying an Ubuntu host with ZFS.

As all I needed for my test environment was a VM which could expose an NFSv4 server with ACLs, I wound up abandoning my efforts to get a Linux server going, and using a FreeBSD 10.3 image instead. Attempting to get this to work with NFSv4 was also difficult but was at least possible. There's a pretty decent guide on the FreeBSD manpage for nfsv4(4).

Answer 2

NFSv4 ACLs are like RichACLs. The problem is that RichACLs aren't implemented in any underlying linux filesystem other than ZFS. Ext4, XFS, etc. only support POSIX ACLs, which are a limited subset of the preceding. The actual permissions of the files will be dropped down to what the underlying filesystem supports. The bottom line is ACLs are an absolute mess on linux (still, in March 2019) and need to be fixed.