From: Sachin Prabhu <sprabhu@redhat.com>
To: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: Error: state manager encountered RPCSEC_GSS session expired against NFSv4 server
Date: Fri, 16 Mar 2012 19:26:44 +0000 [thread overview]
Message-ID: <1331926004.2336.6.camel@localhost> (raw)
In-Reply-To: <1331924613.12136.1.camel@lade.trondhjem.org>
On Fri, 2012-03-16 at 19:03 +0000, Myklebust, Trond wrote:
> On Fri, 2012-03-16 at 13:42 -0400, Daniel Kahn Gillmor wrote:
> > On 03/16/2012 01:36 PM, Myklebust, Trond wrote:
> > > The problem is that if the client doesn't have a machine cred, then you
> > > end up taking a random user credential that may not currently be holding
> > > any OPEN files. In that case too the RENEW will fail.
> >
> > So if i'm understanding this right:
> >
> > Sachin's proposal fails when the machine has no machine creds.
> >
> > The current implementation fails when the logged-in user's credentials
> > are expired.
> >
> > Can the NFS client's logic test for those different cases, use the
> > appropriate creds for RENEW in their difference, and reduce the failure
> > case to their intersection?
>
> Simpler solution: add the call to get machine creds to the existing
> get_renew_creds function.
Hello Trond,
I've sent a patch to the Mailing list using your suggestion above.
Thanks
Sachin Prabhu
next prev parent reply other threads:[~2012-03-16 19:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-16 15:46 Error: state manager encountered RPCSEC_GSS session expired against NFSv4 server Sachin Prabhu
2012-03-16 17:36 ` Myklebust, Trond
2012-03-16 17:42 ` Daniel Kahn Gillmor
2012-03-16 19:03 ` Myklebust, Trond
2012-03-16 19:25 ` [PATCH] Try using machine credentials for RENEW calls Sachin Prabhu
2012-03-16 19:26 ` Sachin Prabhu [this message]
2016-07-27 13:45 ` Error: state manager encountered RPCSEC_GSS session expired against NFSv4 server Hari Krishnan
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=1331926004.2336.6.camel@localhost \
--to=sprabhu@redhat.com \
--cc=Trond.Myklebust@netapp.com \
--cc=linux-nfs@vger.kernel.org \
/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.