On Thu, Nov 15, 2012 at 09:03:03PM -0500, Chuck Lever wrote: > > On Oct 28, 2012, at 12:15 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > > On Wed, Oct 24, 2012 at 04:40:59PM -0400, J. Bruce Fields wrote: > >> On Wed, Oct 24, 2012 at 08:34:37PM +0000, Myklebust, Trond wrote: > >>>> -----Original Message----- > >>>> From: Myklebust, Trond > >>>> Sent: Wednesday, October 24, 2012 4:31 PM > >>>> To: 'J. Bruce Fields' > >>>> Cc: linux-nfs@xxxxxxxxxxxxxxx; Schumaker, Bryan > >>>> Subject: RE: 3.7-rc1 NFSv3/sec=krb5 mkdir failure > >>>> > >>>>> -----Original Message----- > >>>>> From: J. Bruce Fields [mailto:bfields@xxxxxxxxxxxx] > >>>>> Sent: Wednesday, October 24, 2012 4:15 PM > >>>>> To: Myklebust, Trond > >>>>> Cc: linux-nfs@xxxxxxxxxxxxxxx; Schumaker, Bryan > >>>>> Subject: Re: 3.7-rc1 NFSv3/sec=krb5 mkdir failure > >>>>> > >>>>> On Wed, Oct 24, 2012 at 08:07:55PM +0000, Myklebust, Trond wrote: > >>>>>>> -----Original Message----- > >>>>>>> From: linux-nfs-owner@xxxxxxxxxxxxxxx [mailto:linux-nfs- > >>>>>>> owner@xxxxxxxxxxxxxxx] On Behalf Of J. Bruce Fields > >>>>>>> Sent: Wednesday, October 24, 2012 4:03 PM > >>>>>>> To: linux-nfs@xxxxxxxxxxxxxxx; Myklebust, Trond; Schumaker, Bryan > >>>>>>> Subject: Re: 3.7-rc1 NFSv3/sec=krb5 mkdir failure > >>>>>>> > >>>>>>> Anyone get a chance to look at this? It seems very reproduceable. > >>>>>>> > >>>>>>> --b. > >>>>>>> > >>>>>>> On Tue, Oct 16, 2012 at 08:58:32AM -0400, bfields wrote: > >>>>>>>> On 3.7-rc1: > >>>>>>>> > >>>>>>>> client# mount -tnfs -osec=krb5,vers=3 server:/exports/ext4 > >>>>>>>> /mnt/ > >>>>>>>> > >>>>>>>> server# ls -l /exports/ext4|grep TMP > >>>>>>>> server# > >>>>>>>> > >>>>>>>> # mkdir /mnt/TMP > >>>>>>>> mkdir: cannot create directory `/mnt/TMP': Permission denied > >>>>>>>> > >>>>>>>> server# ls -l /exports/ext4|grep TMP > >>>>>>>> drwxr-xr-x 2 nfsnobody nfsnobody 4096 Oct 16 08:56 TMP > >>>>>>>> server# > >>>>>>>> > >>>>>>>> Wireshark also shows that the create succeeds. > >>>>>> > >>>>>> Can you share the wireshark trace? > >>>>> > >>>>> Sure. This covers the mount and mkdir. The mkdir call and reply are > >>>>> in frames 77 and 78. > >>>> > >>>> Hmm.... Can you please check if the ACL is being set correctly on the server? I > >>>> suspect that might be the source of the error. > >>>> > >>> > >>> In fact, can you see if mounting with '-onoacl' causes the whole thing to succeed? > >> > >> That's on the client mount command? No difference. > > > > By the way, I managed to do a little bisecting while working on > > something else today, and blame landed on Chuck's > > ba9b584c1dc37851d9c6ca6d0d2ccba55d9aad04 "SUNRPC: Introduce > > rpc_clone_client_set_auth()". Which makes some sense if it's an ACL > > problem, and indeed testing on that commit finds success with -noacl, > > failure without. > > After two weeks, Bruce and I were finally able to catch up in person. > > I've reproduced this on 3.7-rc5 using cthon basic tests. The first getacl operation fails because it's mistakenly attempting to set up a fresh GSS context on a transport where one already exists. That's in line with the kind of change that's in commit ba9b584c1. > > > I'm not sure if that explains the failure I was seeing on 3.7-rc1, since > > there I didn't see any ACL traffic, and still got a failure. (And > > -noacl didn't help.) > > The failure occurs on the client just before the getacl request is issued, so you won't see any ACL-related network traffic in the failure case. The failure prevents any ACL request from succeeding. > > Anyway, I'll have a deeper look at this tomorrow. Great, thanks for taking another look. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
