NFS Services Administrator's Guide (762805-001, March 2014)

3. Enter the following commands to verify that rpc.statd, rpc.lockd, and nfsd are
all running and responding to RPC requests:
/usr/bin/rpcinfo -u servername status
/usr/bin/rpcinfo -u servername nlockmgr
/usr/bin/rpcinfo -u servername nfs
/usr/bin/rpcinfo -u clientname status
/usr/bin/rpcinfo -u clientname nlockmgr
/usr/bin/rpcinfo -u clientname nfs
4. Before retrying the mount that caused the program to hang, wait for a short while, say
two minutes.
5. If the problem persists, restart rpc.statd and rpc.lockd daemons and enable tracing.
Data is lost between the client and the server
□ Make sure that the directory is not exported from the server with the async option. If the
directory is exported with the async option, the NFS server will acknowledge NFS writes
before actually writing data to disk.
□ If users or applications are writing to the NFS-mounted directory, make sure it is mounted with
the hard option (the default), rather than the soft option.
□ If you have a small number of NFS applications that require absolute data integrity, add the
O_SYNC flag to the open() calls in your applications. When you open a file with the O_SYNC
flag, a write() call will not return until the write request has been sent to the NFS server
and acknowledged. The O_SYNC flag degrades write performance for applications that use
it.
□ If multiple NFS users are writing to the same file, add the lockf() call to your applications
to lock the file so that only one user may modify it at a time.
If multiple users on different NFS clients are writing to the file, you must also turn off attribute
caching on those clients by mounting the file with the noac mount option. Turning off attribute
caching degrades NFS performance.
For more information, see mount(1M), open(2),write(2), and lockf(2).
“Too many levels of remote in path” message
This message indicates that you are attempting to mount a directory from a server that has
NFS-mounted the directory from another server. You cannot “chain” your NFS mounts this way.
You must mount the directory from the server that has mounted its directory on a local disk.
Common problems while using secure NFS with Kerberos
Files created by root will be mapped to nobody as owner
With secure NFS setup, sometimes a file created by root at host specified in root=<host>option is
set to anon as owner.
In order to avoid this problem, kdestroy has been enhanced to invalidate Kerberos credentials
held for the user in NFS gss auth cache table. Thus, in order for the NFS cache table to have an
updated Kerberos credentials each time a kinit is called, it is mandatory to execute kdestroy prior
to kinit.
NOTE: The kdestroy enhancement is available in Kerberos V5 Client Version E.1.6.2.10.
100 Troubleshooting NFS services