NFS mount attempt fails, complains of statd or lock problems

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

Environment

SUSE Linux Enterprise Server 11 Service Pack 4 (SLES 11 SP4)
SUSE Linux Enterprise Server 11 Service Pack 3 (SLES 11 SP3)
SUSE Linux Enterprise Server 11 Service Pack 2 (SLES 11 SP2)
SUSE Linux Enterprise Server 11 Service Pack 1 (SLES 11 SP1)
SUSE Linux Enterprise Server 11 (SLES 11)

Situation

An NFS client machine attempts to perform an NFS mount.  This fails, with the following errors at the command line:
 
mount.NFS: rpc.statd is not running but is required for remote locking.
mount.NFS: Either use '-o nolock' to keep locks local, or start statd.
mount.NFS: an incorrect mount option was specified
 
In /var/log/messages, one or more of the following errors may be seen:
 
rpcbind: connect from 127.0.0.1 to getport/addr(status): request from unauthorized host
rpcbind: connect from 127.0.0.1 to unset(status): request from unauthorized host
rpc.statd[18142]: Could not bind name to socket: Address already in use
 

Resolution

If the server has had a new kernel installed without being rebooted, this can cause one variation of this issue.  Compare the output of "rpm -qa | grep kernel-" [to see the installed kernel(s)] and the output of "uname -a" [to see the running kernel] and see if there is a discrepancy.  Reboot to put the currently installed kernel into effect, if needed.
 
Another cause / resolution:  The /etc/hosts.allow and/or /etc/hosts.deny must be edited to allow access to rpcbind.  The NFS client machine must be able to talk to it's own rpcbind (portmapper) service in order to mount NFS resources.
 
This is allowed by default, but in many cases, administrators have changed these files to restrict access to many services on their systems, without realizing the extent of their restrictions.
 
The exact modifications needed may depend upon the configuration desired.  Returning to the "default" is the simplest way to correct this issue.  Also, returning to the default (at least temporarily) is a good way to confirm or deny the involvement of these files.
 
On SLES, the default /etc/hosts.allow file contain only comments.
 
The default /etc/hosts.deny file contains comments plus one line:
http-rman : ALL EXCEPT LOCAL
 
If many things are being denied in hosts.deny, and it is desired to keep those restrictions, then it may be enough to add the following entry to /etc/hosts.allow:
 
#/etc/hosts.allow
rpcbind : ALL : ALLOW
 
Some administrators might be tempted to deny some or all services with lines such as:
 
#/etc/hosts.deny
ALL : ALL
rpcbind : ALL
 
And once this causes problems for NFS mounts, they may believe that it would be sufficient solution to change those entries to make an exception for "local" access to those services, such as:
 
#/etc/hosts.deny
ALL : ALL EXCEPT LOCAL
rpcbind : ALL EXCEPT LOCAL
 
These settings would indeed allow the mount to complete successfully.  HOWEVER, it is still not enough for proper functioning of NFS.  An NFS client sometimes need to be contacted by an NFS Server, to give the client status announcements or lock callbacks.   If the NFS client's rpcbind is only allowing "local" access, then the NFS Server will not be able to reach those services on the client.
 
The NFS client's rpcbind should be open to everyone, or at least to LOCAL plus any NFS Server that it deals with.
 
So if a rule in /etc/hosts.allow is to be used to correct this, it should be:
 
#/etc/hosts.allow
rpcbind : ALL : ALLOW
 
Alternatively, if a rule in /etc/hosts.deny is used with an exception, it should be something like:
 
#/etc/hosts.deny
rpcbind : ALL EXCEPT LOCAL 10.10.10.10
#(where 10.10.10.10 is the IP address of the NFS Server with which this client machine interacts)
 
or possibly:
 
#/etc/hosts.deny
ALL : ALL EXCEPT LOCAL 10.10.10.10
#(where 10.10.10.10 is the IP address of the NFS Server with which this client machine interacts)

Cause

/etc/hosts.allow and hosts.deny are files used by the "TCP Wrappers" library.  This library can enforce rules about who can access various services.  However, these rules are not automatically enforced.  A service will only be protected by these rules if it has been written to use them.  A service can be checked by doing "ldd" against the binary.
 
For example, the command:
 
ldd /sbin/rpcbind
 
will output a list of library dependencies for "rpcbind", and one of them will be:
 
 libwrap.so.0 => /lib64/libwrap.so.0
 
The presence of this library is the signal that this binary is written to use TCP Wrappers.
 
Previously, SLES 10 used a package called "portmap" to serve rpc functions, and the portmap binary did not use TCP Wrappers.  In contrast, SLES 11's rcpbind does use them.  So customers who have TCP Wrapper rules configuration may not have run into this problem on SLES 10, but may find that moving from SLES 10 to SLES 11 triggers 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.

  • Document ID:7022429
  • Creation Date: 04-Dec-2017
  • Modified Date:03-Mar-2020
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback@suse.com

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Join Our Community

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.


SUSE Customer Support Quick Reference Guide SUSE Technical Support Handbook Update Advisories
Support FAQ

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.

Go to Customer Center