On Thu, 2010-05-27 at 09:09 -0400, Rob Crittenden wrote: > I assume the keytab is still valid since the mount succeeds and root > works. Kerberos otherwise works ok on this machine, you can kinit, etc?
Hm, the server didn't change, and on the client klist -k /etc/krb5.keytab -e does not suggest anything changed, so yes the keytab seems to be ok. Kerberos works as well. > You might want to check the kdc log on and the 389-ds log, you might see > some querying to find the user for authentication. Neither /var/log/krb5kdc.log nor /var/log/dirsrv/slapd-XXX-COM/errors lists anything related to that client. > Do things like 'getent passwd <someuser>' still work? Yes. I don't think it's anything related to the server, or krb5 on the client going wrong. At the time the non-root user does ls /tmp/z, there is no network traffic, so the server cannot even know that some user tries to ls the mount directory. Also, I've monitored the network traffic with wireshark, the whole NFSv4 exchange seems to work as expected (unfortunately wireshark does not seem to have a dissector for V4 composite RPC calls, so I don't know in detail what server and client are talking about), I have not seen any GSS related failures in the protocol exchange. I've tried selective downgrade of the client. I've downgraded kernel, nfs-utils*, cyrus-sasl*, libtirpc*, krb5*, so far without success. I've also tried the opposite, i.e. selectively upgrading a working fc12 client, so far without any insight, it is still working. I've upgraded the following packages: grubby-7.0.13-1.fc13.x86_64 kernel-18.104.22.168-95.fc13.x86_64 krb5-devel-1.7.1-10.fc13.x86_64 krb5-libs-1.7.1-10.fc13.i686 krb5-libs-1.7.1-10.fc13.x86_64 krb5-workstation-1.7.1-10.fc13.x86_64 linux-firmware-20100106-4.fc13.noarch nfs-utils-1.2.2-2.fc13.x86_64 nfs-utils-lib-1.1.5-1.fc13.x86_64 I'm a bit at a loss... Tom _______________________________________________ Freeipa-users mailing list Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-users