Linux NFS development
 help / color / mirror / Atom feed
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.

  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