Unable to set ACLs on ZFS file system over NFSv4?

[Rick Macklem]

Andrew Leonard wrote:
> On Fri, May 11, 2012 at 7:30 PM, Rick Macklem <rmacklem at uoguelph.ca>
> wrote:
> > Andrew Leonard wrote:
> >> On Thu, May 10, 2012 at 2:23 PM, Rick Macklem
> >> <rmacklem at uoguelph.ca>
> >> wrote:
> >>
> >> > I wrote:
> >>
> >> >> If you capture a packet trace from before you do the NFSv4
> >> >> mount, I
> >> >> can
> >> >> take a look and see what the server is saying. (Basically, at
> >> >> mount
> >> >> time
> >> >> a reply to a Getattr should including the supported attributes
> >> >> and
> >> >> that
> >> >> should include the ACL bit. Then the setfacl becomes a Setattr
> >> >> of
> >> >> the
> >> >> ACL
> >> >> attribute.)
> >> >> # tcpdump -s 0 -w acl.pcap host <server>
> >> >> - run on the client should do it
> >> >>
> >> >> If you want to look at it, use wireshark. If you want me to
> >> >> look,
> >> >> just
> >> >> email acl.pcap as an attachment.
> >> >>
> >> >> rick
> >> >> ps: Although I suspect it is the server that isn't behaving,
> >> >> please
> >> >> use
> >> >> the FreeBSD client for the above.
> >> >> pss: I've cc'd trasz@ in case he can spot some reason why it
> >> >> wouldn't
> >> >> work.
> >> >>
> >> > Oh, and make sure "user1" isn't in more than 16 groups, because
> >> > that
> >> > is the
> >> > limit for AUTH_SYS. (I'm not sure what the effect of user1 being
> >> > in
> >> > more
> >> > than 16 groups would be, but might as well eliminate it as a
> >> > cause.)
> >>
> >> Thanks, Rick - I'll send the pcap over private email, as I'm sure
> >> $DAYJOB would consider it somewhat sensitive.
> >>
> >> Looking in wireshark, if I'm reading it correctly, I don't see
> >> anything for FATTR4_ACL in any replies. On the final connection, I
> >> do
> >> see NFS4ERR_IO set as the status for the reply to the setattr - but
> >> from Googling, my understanding is that response is supposed to
> >> indicate a hard error, such as a hardware problem.
> >>
> > Yep, it appears that ZFS returned an error that isn't in the list of
> > replies for getattr, so it got mapped to EIO (the catch all for
> > error
> > codes not known to NFS).
> >
> > I took a quick look at the ZFS code and the problem looks pretty
> > obvious. ZFS replies EOPNOTSUPP to the VOP_ACLCHECK() and that's
> > as far as it gets.
> >
> > Please try the attached patch in the server (untested, but all it
> > does is go ahead
> > and try the VOP_SETACL() for the case where VOP_ACLCHECK() replies
> > EOPNOTSUPP) and let me know if it helps.
> 
> It took me a little while to get a test environment set up, but with
> the patch applied, ACLs can be set on the ZFS file system over NFSv4.
> 
Just fyi, a patch has just been committed to head and will be MFC'd in a week. It
is slightly different, in that it just deletes the VOP_ACLCHECK() call,
but should fix the problem. (The patch applies to the NFSv4 server, not
client.)

Thanks for testing this, rick

> Thanks,
> Andy
> 
> > Thanks for reporting this and sending the packet trace, rick
> >
> >> Also, I have verified that "user1" is not a member of more than 16
> >> groups, so we can rule that out - that user is in only three
> >> groups.
> >>
> >> -Andy