NFS mount attempts fail on a SLES 11 nfs client, which were working on SLES 10

This document (7008984) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 11 SP1

SUSE Linux Enterprise Server 11 GA

Situation

A SLES 11 system is trying to mount an NFS share from a NFS Server that has multiple IP addresses bound. The mount is failing with "rpc timeout" types of messages. It is especially likely if the SLES 11 NFS client is trying to mount with udp (proto=udp) but could happen in some cases where udp is not specifically being requested.

Resolution

SLES 11 is a bit more strict when it comes to certain types of UDP communication than previous versions were. This can even effect NFS mount attempts even when UDP is not specifically requested.

In has been seen in some cases, when an NFS Server is running on a system with more than one IP address bound, that the NFS Server may reply to a UDP request packet from a different IP address than that which received the UDP request. This is not proper behavior and the IP stack on SLES 11 is correctly rejecting such packets. Previous versions of SLES may have been more lenient about this. And this is not a SLES-only condition, it comes from Linux in general, with newer kernels being more strict.

Generally speaking, if an NFS Server is answering a UDP request from a different IP address than received it, this needs to be corrected in the IP stack design on the OS where the NFS Server is running. SUSE Technical Support has only seen this problem with 3rd-party, non-Linux Operating Systems. However, configuration options can often be used on SLES 11 to workaround this problem.

NFS mount requests typically involve communication to several services and therefore several different protocols and ports are used. At a minimum, usually the portmapper daemon, mount daemon, and nfs daemon on the NFS Server are all contacted. If the client is specifying UDP be used, or is not specifically requesting TCP, UDP can be used for one or more of these communications. Interestingly, most OSes which have exhibited this problem have only shown it on the mount daemon and/or the portmapper.

When a linux nfs client does a mount request, if the mount syntax does not specify a transport protocol, it will typically use TCP for NFS itself, but may use UDP for mount and portmapper. By specifying a preference for TCP, it should be used for all. So if TCP is the desired protocol, then mount option should be used:

proto=tcp

Or if there is still doubt about the mount transport, it could be specified as well with:

proto=tcp,mountproto=tcp

If UDP is actually the desired protocol for NFS to use, then this gets trickier but can still usually be accomplished as long as the mount protocol itself can still use TCP. The mount protocol is only used during a mount / umount event itself, not for ongoing NFS activity. So if a NFS Server system is answering from the "wrong" IP address but UDP is required for the NFS communication, the recommended syntax would be:

nfsvers=3,proto=udp,port=2049,mountproto=tcp

This means that UDP is used for nfs traffic; TCP is used for the small amount of mount traffic; and manually setting port 2049 for NFS will eliminate some requests that need to be made to portmapper, and further avoid potential instances of this problem.

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.