All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.