[20493] in Athena Bugs
Re: Solaris Athena 9.1.11 and KNFS servers
daemon@ATHENA.MIT.EDU (Garry Zacheiss)
Tue Jul 16 17:12:18 2002
Message-Id: <200207162109.RAA15433@riff-raff.mit.edu>
To: Tom Cavin <cavin@mit.edu>
cc: Garry Zacheiss <zacheiss@mit.edu>, Athena Bugs list <bugs@mit.edu>
In-Reply-To: Your message of "Tue, 16 Jul 2002 16:49:14 EDT."
<15668.34506.258410.788897@lap1-wccf.mit.edu>
Date: Tue, 16 Jul 2002 17:09:46 -0400
From: Garry Zacheiss <zacheiss@MIT.EDU>
>> I was in a bit of a rush with this server and fixed it (more or less) by
>> doing a "nfs.server stop" followed by an "nfs.server start".
>>
>> If I recall correctly, we had a similar problem with mountd dying on start
>> up that was fixed with a new version of mountd.
There was at one point, although my recollection is that our newer
mountd got backed out because there was an issue with it sometimes
failing to properly authenticate users. It should be on your system as
/usr/local/lib/nfs/mountd.new; if your current mountd dies again, you
might consider starting that one and seeing how it works.
>> I can get in using either the password or ssh-agent, but I don't understand
>> why the "Key version number for principal in key table is incorrect".
>>
>> When I look at the srvtab and krb5.keytab files, they seem ok. I don't
>> know (or remember) how to check the version on the key server.
That error message is usually indicative of you having an old version
of the key in your kerberos credentials cache; if you kdestroy and get
new tickets and then try to log in again, does the problem persist?
You can use "kvno principal" to tell what version of a key the KDC
thinks is most recent; so, in this case, we would use:
[zacheiss@riff-raff] ~$ kvno host/pasque.mit.edu@ATHENA.MIT.EDU
host/pasque.mit.edu@ATHENA.MIT.EDU: kvno = 4
Let me know if you still have problems.
Garry
