General troubleshooting recommendations

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
Line 2: Line 2:
If you cannot resolve your problem and plan to report it to the developer, see [[Reporting bugs]].
If you cannot resolve your problem and plan to report it to the developer, see [[Reporting bugs]].
 +
 +
=General NFSv4 Issues=
== Check server's exports ==
== Check server's exports ==
Line 19: Line 21:
Try mounting the nfs4 export on the server itself by mounting localhost:/.  This will isolate whether the problem is with the server configuration.
Try mounting the nfs4 export on the server itself by mounting localhost:/.  This will isolate whether the problem is with the server configuration.
-
==Getting detailed debug output of the client/server interactions==
+
== Getting detailed debug output of the client/server interactions ==
 +
 
 +
If you suspect the problem may involve some sort of miscommunication between the client and server, it can be useful for debugging purposes to dump the communication stream:
Start `tcpdump -s 9000 -w /tmp/dump.out port 2049` on the client, then conduct the client/server interaction.  Review the /tmp/dump.out file (or include it with your bug report).
Start `tcpdump -s 9000 -w /tmp/dump.out port 2049` on the client, then conduct the client/server interaction.  Review the /tmp/dump.out file (or include it with your bug report).
 +
 +
== Tracing kernel calls ==
 +
 +
If the problem might be in the kernel, it can be useful to log a trace of the kernel calls.  Here is how to turn this on:
 +
 +
First, look in /etc/sysctl.conf to see if kernel.sysrq is set to 1.  If not, then run this command:
 +
 +
echo 1 > /proc/sys/kernel/sysrq
 +
 +
Next, turn on system trace via this command:
 +
 +
echo t > /proc/sysrq-trigger
 +
 +
=="Reboot" the NFSv4 server without shutting down the machine==
=="Reboot" the NFSv4 server without shutting down the machine==
Line 27: Line 45:
Just shut down rpc.nfsd and start it again.
Just shut down rpc.nfsd and start it again.
-
==I get different results when mounting via NFSv3 and NFSv4==
+
==Comparing results when mounting via NFSv3 and NFSv4==
Find a file that is differing between v3 and v4, and look at the output from the `stat` utility.   
Find a file that is differing between v3 and v4, and look at the output from the `stat` utility.   
Or use `ls -lid --type-style=full-iso` and `ls -lid --time=ctime --time-style=full-iso` if you don't have stat.
Or use `ls -lid --type-style=full-iso` and `ls -lid --time=ctime --time-style=full-iso` if you don't have stat.
 +
 +
=Kerberos issues=
 +
 +
==Check hostnames==
 +
 +
Kerberos requires the hostname/domainname used in the keytab is correct.  Run `hostname` and look in /etc/hosts to doublecheck that it is set properly.  Compare with what you've listed in your keytab file.

Revision as of 21:01, 28 June 2005

Depending on your configuration, there's a number of ways that NFS can fail to work. Sometimes it can be difficult to determine exactly why it is not working. This page describes some general techniques for diagnosing the issue.

If you cannot resolve your problem and plan to report it to the developer, see Reporting bugs.

Contents

General NFSv4 Issues

Check server's exports

An easy first thing to doublecheck is that your server is exporting what you think it is. On the server, run the command:

exportfs -v

If you need to make modifications, edit /etc/exports and re-export using the command

exportfs -r

Remember that pseudo-filesystems in NFSv4 work very differently than NFSv3. Review the <a href="http://www.citi.umich.edu/projects/nfsv4/linux/using-nfsv4.html">Using NFSv4</a> directions if you have questions.

Check server mount functionality

Try mounting the nfs4 export on the server itself by mounting localhost:/. This will isolate whether the problem is with the server configuration.

Getting detailed debug output of the client/server interactions

If you suspect the problem may involve some sort of miscommunication between the client and server, it can be useful for debugging purposes to dump the communication stream:

Start `tcpdump -s 9000 -w /tmp/dump.out port 2049` on the client, then conduct the client/server interaction. Review the /tmp/dump.out file (or include it with your bug report).

Tracing kernel calls

If the problem might be in the kernel, it can be useful to log a trace of the kernel calls. Here is how to turn this on:

First, look in /etc/sysctl.conf to see if kernel.sysrq is set to 1. If not, then run this command:

echo 1 > /proc/sys/kernel/sysrq

Next, turn on system trace via this command:

echo t > /proc/sysrq-trigger


"Reboot" the NFSv4 server without shutting down the machine

Just shut down rpc.nfsd and start it again.

Comparing results when mounting via NFSv3 and NFSv4

Find a file that is differing between v3 and v4, and look at the output from the `stat` utility.

Or use `ls -lid --type-style=full-iso` and `ls -lid --time=ctime --time-style=full-iso` if you don't have stat.

Kerberos issues

Check hostnames

Kerberos requires the hostname/domainname used in the keytab is correct. Run `hostname` and look in /etc/hosts to doublecheck that it is set properly. Compare with what you've listed in your keytab file.

Personal tools