No lockfile creation in NFS setup

Question

I recently set up a new fileserver for our research group. The old one was running SuSE linux and, although small harddrives and a slow machine, worked fine. The clients are mostly Gentoo machines mounting the NFS shares via autofs. The home directories of the machines are on the fileserver.

The new fileserver is a virtual machine on some department computer running Debian squeeze. After setting up (several times) we had major problems with the rpc.statd and/or rpc.lockd not responding as soon as more than one computer mounted their home directories. We updated the kernel from 2.6.32 to 3.2 what seemed to fix that issue. However, it seems as if lockfiles are still not created at all.

For example, our xdm desktop manager on the clients falls back to creating the .Xauthority file somewhere locally in /tmp instead of in the home directory on the NFS share. Also, heavy programs that use lock files, like Firefox, Thunderbird, Libreoffice etc. are somewhat slow and so is the xdm login.

We use (at least that's what I think) NFS4, which to my knowledge doesn't need rpc.lockd and so on anymore. The only error message related to this that I can find since the kernel update is the following:

sm-notify[540]: nsm_parse_reply: [0x515dce2e] RPC status 1

I can not find out on the internet what that means. The server is (currently) not protected at all, the /etc/default/nfs-kernel-server looks like this

RPCNFSDCOUNT=32
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS="--manage-gids -p 32767"
NEED_SVCGSSD=
RPCSVCGSSDOPTS=

and on the clients, the hosts.allow contains an entry for rpcbind of the server.

I have several questions related to this:

• How can I check, using a small python or bash script, whether lock file creation works normally on NFS shares?
• How do I find out which NFS version a client uses?
• How can I track down NFS errors, when nothing appears in the log files?
• What could be the reason for our problems with the Xauthority and the applications mentioned above?

Answer 1

I think I solved it. xdm creates the .Xauthority as root, so the option no_root_squash in the NFS exports prevents it from doing so. Removing that option allows the clients to create the .Xauthority just fine.

Answer 2

I think tcpdump(8) and strace(1) are your friends here.

tcpdump can:

• show the NFS protocol version
• tell you who is talking to who (for troubleshooting)
• sometimes also tell you what goes wrong in cases where application log messages are scarce

strace tracks system calls and signals, which, when attached to the proper process, such as a shell or sshd, could show for instance what fopen() calls are attempted, which could hint about the .Xauthority problem.

It has happened to me several times (not with NFS, but with client/server troubleshooting) that the application does not work and either won't say why or say something clever like "unexpected error" in the log files, where a verbose tcpdump -A shows the error messages from the server (that the client simply ignored), so tcpdump along with strace are invaluable when dealing with problems with applications you haven't built yourself.