From: "J. Bruce Fields" <bfields@fieldses.org>
To: "david m. richter" <richterd@citi.umich.edu>
Cc: Brian De Wolf <bldewolf@csupomona.edu>, linux-nfs@vger.kernel.org
Subject: Re: nfs4_getfacl "Failed getxattr operation" when too many ACL entries exist
Date: Fri, 11 Apr 2008 15:33:20 -0400 [thread overview]
Message-ID: <20080411193320.GC16965@fieldses.org> (raw)
In-Reply-To: <Pine.BSO.4.64.0804101837200.12362@citi.umich.edu>
On Thu, Apr 10, 2008 at 06:41:18PM -0400, david m. richter wrote:
> On Thu, 10 Apr 2008, david m. richter wrote:
>
> > On Thu, 10 Apr 2008, Brian De Wolf wrote:
> >
> > > Recently we've been prototyping serving Solaris ZFS exports via NFSv4 to some
> > > Linux hosts. These will some day be exposed to general users, so I've been
> > > testing things to see if I can break them. Anyway, it seems that nfs4_getfacl
> > > is only able to read ACLs with up to 208 entries. nfs4_setfacl is able to
> > > insert a 209th entry, but any attempts to view or edit the ACLs after that
> > > fail with:
> > >
> > > Failed getxattr operation
> > > : Input/output error
> > >
> > > There are two ways to make the ACLs readable again:
> > > 1) Have someone log in to the Solaris box and remove some of the entries
> > > 2) Reset the ACLs using nfs4_setfacl -s `some spec`
> > >
> > > Has anyone run into this issue before? Is it fixable? I didn't reach the
> > > same problem locally on the Solaris box, nor on another Solaris box with the
> > > same NFS mount, so it looks like it's a problem specific to Linux. Here's the
> > > versions of relevant packages on the test box running Gentoo (did I miss
> > > any?):
> > > Kernel: 2.6.23-gentoo-r8
> > > nfs-utils-1.1.0-r1
> > > attr-2.4.39
> > > nfs4-acl-tools-0.3.2
> >
> > honestly, this probably stems from some naive, unrevisited <ahem>
> > assumptions still lingering nfs4-acl-tools code that need fixing. at the
> > -very- least, nfs4_setfacl could save the original ACL and attempt to
> > restore it if the setxattr() call fails.
>
> sorry, misread part of your letter the first time around -- it'd
> be very bizarre if nfs4_getfacl influenced the ACL in any way, so i
> suspect that something's going awry with nfs4_setfacl. seeing such an
> arbitrary limit of 208 or 209 ACEs looks like the tools being dumb.
I haven't looked at this code in a while. From a quick look.... It
appears the kernel limits ACLs to 64K (xdr-encoded). One ACE has length
16 + (length of user/group name rounded up to multiple of 4)
But to be hitting that limit with 208 entries I think you'd have to have
user/group names (including domain) of about 300 characters.
Anyway, strace'ing nfs4_getfacl/nfs4_setfacl would verify whether the
error was coming from the kernel or the tools.
I have to ask: how many acl entries do you need?
--b.
next prev parent reply other threads:[~2008-04-11 19:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-10 21:53 nfs4_getfacl "Failed getxattr operation" when too many ACL entries exist Brian De Wolf
2008-04-10 22:35 ` david m. richter
2008-04-10 22:41 ` david m. richter
2008-04-11 19:33 ` J. Bruce Fields [this message]
2008-04-11 21:43 ` nfs4_getfacl "Failed getxattr operation" when too many ACLentries exist Brian De Wolf
2008-04-11 22:26 ` david m. richter
2008-04-11 23:31 ` Brian De Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080411193320.GC16965@fieldses.org \
--to=bfields@fieldses.org \
--cc=bldewolf@csupomona.edu \
--cc=linux-nfs@vger.kernel.org \
--cc=richterd@citi.umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox