On Wed, Mar 22, 2017 at 6:11 PM, John Jasen <jjasen at realityfailure.org> wrote: > On 03/22/2017 03:26 PM, Matt Garman wrote: >> Is anyone on the list using kerberized-nfs on any kind of scale? > > Not for a good many years. > > Are you using v3 or v4 NFS? v4. I think you can only do kerberized NFS with v4. > Also, you can probably stuff the rpc.gss* and idmapd services into > verbose mode, which may give you a better ideas as to whats going on. I do that. The logs are verbose, but generally too cryptic for me to make sense of. Web searches on the errors yield results at best 50% of the time, and the hits almost never have a solution. > And yes, the kernel does some kerberos caching. I think 10 to 15 minutes. To me it looks like it's more on the order of an hour. For example, a simple test I've done is to do a "fresh" login on a server. The server has just been rebooted, and with the reboot, all the /tmp/krb5cc* files were deleted. I login via ssh, which implicitly establishes my Kerberos tickets. I deliberately do a "kdestroy". Then I have a simple shell loop like this: while [ 1 ] ; do date ; ls ; sleep 30s ; done Which is just doing an ls on my home directory, which is a kerberized NFS mount. Despite having done a kdestroy, this works, presumably from cached credentials. And it continues to work for *about* an hour, and then I start getting permission denied. I emphasized "about" because it's not precisely one hour, but seems to range from maybe 55 to 65 minutes. But, that's a super-simple, controlled test. What happens when you add screen multiplexers (tmux, gnu screen) into the mix. What if you login "fresh" via password versus having your gss (kerberos) credentials forwarded? What if you're logged in multiple times on the same machine by via different methods?