NFSv4: Listing of files hangs

Kevin Coffman kwc at citi.umich.edu
Fri Mar 23 13:36:49 EDT 2007


On 3/23/07, Johan Marcusson <independence at blinkenlights.se> wrote:
> fre 2007-03-23 klockan 12:57 -0400 skrev Kevin Coffman:
> > > ...
> >
> > This message does not indicate a problem.
> >
> > Do you see messages from rpc.gssd that indicate a context has been
> > created for the user and is being written to the kernel?
> >
> > There are no iptables/firewall issues?  A wireshark trace might be helpful.
> >
>
> I get some output indicating this yes, but not at the same time as I do
> "ls" on the client really. It might be very delayed, or it's some
> periodic event. This is the output:
>
> handling krb5 upcall
> Using keytab file '/etc/krb5.keytab'
> INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_MARCUSSON.LOCAL' are
> good until 1174750243
> using FILE:/tmp/krb5cc_machine_MARCUSSON.LOCAL as credentials cache for
> machine creds
> using environment variable to select krb5 ccache
> FILE:/tmp/krb5cc_machine_MARCUSSON.LOCAL
> creating context using fsuid 0 (save_uid 0)
> creating tcp client for server saturn.marcusson.local
> creating context with server nfs at saturn.marcusson.local
> DEBUG: serialize_krb5_ctx: lucid version!
> prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length
> 8
> doing downcall
>
> Client is indy.marcusson.local, server is saturn.marcusson.local and the
> realm is MARCUSSON.LOCAL
>
> There is no firewall rules limiting the connection between client and
> server.

OK, thanks, this looks like the Kerberos part is working from the
client's point of view.   Back to David's question, does it work when
mounted with auth_sys?  A network trace might give a hint at what it
is waiting for.


More information about the NFSv4 mailing list