On Thu, 2012-11-15 at 21:03 -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. Why shouldn't we be able to cope with multiple GSS sessions on the same transport? > > 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. Is it gssd that is failing then? > Anyway, I'll have a deeper look at this tomorrow. Thanks! -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
