On Wed, Aug 31, 2016 at 2:41 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > I should have asked for what distro/nfs-utils are you using? > > In the RHEL/Fedora nfs-utils distros, lifetime of the context is > gotten from gss_inquire_context() call from the gss krb5 api. In > krb5_gss_inquire_context() in krb5 source code in > src/lib/gssapi/krb5/inq_context.c it's set to what I have set before. > > A server can choose to expire the context at any time by returning gss > context error and force the client to create the new security context. > What server are you going against? A network trace would be helpful to > check to see if the server is returning such error. Bringing this thread back to life... I am using CentOS (effectively same as RHEL) 6.5. nfs-utils version 1.2.3-39. All clients and servers are same OS version, same kernel, same nfs-utils. Just to be clear: in your suggestion of a network trace, do you mean using something like tcpdump or wireshark to see exactly what is going on between client and server? Is it sufficient to do this while I am seeing "permission denied" on the krb5p share? Since I am using krb5p (not the 'p'), I believe all NFS traffic is encrypted... so will I actually be able to see anything useful in the packet capture? Can you elaborate specifically on what I should look for? Lastly... as a workaround, can I use the "-t" parameter of rpc.gssd? What if I set that value to be equivalent to be the same as our Kerberos ticket lifetime? Thank you, Matt -- 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
