 |
» |
|
|
 |
This section lists the following common problems encountered
with NFS and suggests ways to correct them. NFS “Server
Not Responding” Message |  |
Enter the /usr/sbin/ping command on the NFS client to make sure the NFS
server is up and is reachable on the network. If the ping command fails, either the server is down, or the
network has a problem. If the server is down, reboot it, or wait
for it to come back up. For more information on troubleshooting
network problems, see HP-UX LAN Administrator's Guide. Ensure that the following daemons are running on
the NFS server: Enter the following command on the NFS client to
make sure the server is running all the NFS server processes: /usr/bin/rpcinfo -p servername |
The rpcinfo command should display the following services: On the NFS server, check if the following processes are running: If any of these processes is not running, follow these steps: Make sure the /etc/rc.config.d/nfsconf file on the NFS server contains the following
lines: NFS_SERVER=1 START_MOUNTD=1 |
Enter the following command on the NFS server to
start all the necessary NFS processes: /sbin/init.d/nfs.server start |
Enter the following command on the NFS client to
make sure the rpc.mountd process on the NFS server is available and responding to
RPC requests: /usr/bin/rpcinfo -u servername mountd |
If the rpcinfo command returns RPC_TIMED_OUT, the rpc.mountd process may be hung. Enter the following commands
on the NFS server to restart rpc.mountd (PID is the process ID returned by the ps command): /usr/bin/ps -ef | /usr/bin/grep mountd /usr/bin/kill PID /usr/sbin/rpc.mountd |
Enter the following command on the NFS client to
check that your hosts database returns the correct address for the NFS
server: /usr/bin/nslookup server_name |
Enter the same nslookup command on the NFS server, and compare the address
with the one returned by the nslookup command on the NFS client. If they are different,
correct your NIS, BIND, or /etc/hosts configuration. For information on BIND or /etc/hosts, see Installing and Administering Internet
Services (B2355-91060). If you are using AutoFS, enter the ps -ef command to make sure the automountd process is running on your NFS client. If it
is not, follow these steps: Make sure the AUTOFS variable is set to 1 in the /etc/rc.config.d/nfsconf file on the NFS client. Enter the following command on the NFS client to
start the AutoFS: /sbin/init.d/autofs start |
“Access
Denied” Message |  |
Enter the following command
on the NFS client to check that the NFS server is exporting the
directory you want to mount: /usr/sbin/showmount -e server_name |
If the server is not exporting the directory, edit the /etc/dfs/dfstab file on the server so that it allows your NFS
client access to the directory. Then, enter the following command
to force the server to read its /etc/dfs/dfstab file. If the directory is shared with the [access_list] option, make sure your NFS client is included
in the [access_list], either individually or as a member of a netgroup. Enter the following commands on the NFS server to
make sure your NFS client is listed in its hosts database: nslookup client_name nslookup client_IP_address |
“Permission
Denied” Message |  |
Check the mount options
in the /etc/fstab file on the NFS client. A directory you are attempting
to write to may have been mounted as read-only. Enter the ls -l command to check the HP-UX permissions on the server
directory and on the client directory that is the mount point. You
may not be allowed access to the directory. Enter the following command on the NFS server: Or, enter the following command on the NFS client: /usr/sbin/showmount -e server_name |
Check the permissions on the shared directory. The directory
may have been shared as read-only to your client. The administrator
of the NFS server can use the remount mount option to mount the directory read/write
without unmounting it. See “Changing
the Default Mount Options”“Changing the Default Mount Options” on
page 51. If you are logged in as root to the NFS client, check the
share permissions to determine whether root access to the directory
is granted to your NFS client. If you are logged in as root to the NFS client,
and your client is not allowed root access to the exported directory,
check the passwd database on the NFS server to determine whether
it contains an entry for user nobody. Without root access, the root user on an NFS client
is given the access permissions of an anonymous user. Also, check
whether anonymous users are denied access to the directory (with
the anon=65535 export option). If your client is not allowed root access or anonymous user
ID access to the exported directory, log in as a non-root user to
get access to the directory. If you were attempting to run a program when you
received the “permission denied” message, enter the ls -l command on the NFS server to check whether the
program you tried to run has the setuid bit set. If it does, check /etc/fstab to determine whether the directory was mounted
with the nosuid mount option. If necessary, remove the nosuid option from the /etc/fstab file, then unmount and remount the directory.
“Device
Busy” Message |  |
If you received the “device busy” message while attempting to mount a directory,
check whether it is already mounted. If you received the “device busy” message while attempting to unmount a directory,
a user or process is currently using the directory. Wait until the
process completes, or follow these steps: Enter the following command to determine who is using the mounted
directory: /usr/sbin/fuser -cu local_mount_point |
The fuser(1M) command will return a list of process IDs
and user names that are currently using the directory mounted under local_mount_point. This will help you decide whether to kill the
processes or wait for them to complete. To kill all processes using the mounted directory,
enter the following command: /usr/sbin/fuser -ck local_mount_point |
Try again to unmount the directory.
Verify that the filesystem you are trying to unmount
is not a mount-point of another filesystem. Verify that the filesystem is not exported. In HP-UX
11i v3, an exported filesystem keeps the filesystem busy.
“Stale
File Handle” Message |  |
A “stale file handle” occurs when one client removes an NFS-mounted
file or directory that another client is accessing. The following
sequence of events explains how it occurs: Table 5-1 Stale File Handle Sequence of Events | NFS client 1 | NFS
client 2 | 1 | | | 2 | | | 3 | | | 4 | | |
If a server stops exporting a directory that a client has
mounted, the client will receive a stale file handle error. Stale file handles also occur if you restore the
NFS server’s file systems from a backup or randomize the
inode numbers with fsirand(1M). If the stale file handle
occurred because someone removed a file or directory that was in
use, or because a server stopped exporting a directory that was
in use, follow these steps: Enter the /usr/bin/cd command to move out of the NFS-mounted directory
that is causing the problem, then try unmounting the directory: /usr/bin/cd /.. /usr/sbin/umount directory |
If the directory cannot be unmounted because it
is busy (in use), enter the following commands to kill the processes
using the directory and to try again to unmount it: /usr/sbin/fuser -ck local_mount_point /usr/sbin/umount local_mount_point |
If the directory still cannot be unmounted, reboot
the client. To avoid stale file handles caused by users deleting NFS-mounted
files, try using a source code control system, like Revision Control
System (RCS). A source code control system allows only one user
at a time to modify a file or directory, so one user cannot remove
files another user is accessing. For more information on the source
code control system, see rcsintro(5).
If someone has restored the server’s file
systems from backup or entered the fsirand command on the server, follow these steps on each
of the NFS clients to prevent stale file handles by restarting NFS: Enter the mount(1M) command with no options, to get a list of
all the mounted file systems on the client: For every NFS-mounted directory listed by the mount command, enter the following command to determine
whether the directory is currently in use: /usr/sbin/fuser -cu local_mount_point |
This command lists the process IDs and user names of everyone using
the mounted directory. Warn any users to cd out of the directory, and kill any processes that
are using the directory, or wait until the processes terminate.
Enter the following command to kill all processes using the directory: /usr/sbin/fuser -ck local_mount_point |
Enter the following command on the client to unmount
all NFS-mounted directories: Enter the following commands to restart the NFS
client: /sbin/init.d/nfs.client stop /sbin/init.d/nfs.client start |
A
Program Hangs |  |
Check whether the NFS
server is up and operating correctly. If you are not sure, see “NFS “Server
Not Responding” Message”. If the server is down, wait until it comes back up, or, if
the directory was mounted with the intr mount option (the default), you can interrupt
the NFS mount, usually with CTRL-C. If the program uses file locking, enter the following
commands (on either the client or the server) to make sure rpc.statd and rpc.lockd are available and responding to RPC requests: /usr/bin/rpcinfo -u servername status /usr/bin/rpcinfo -u servername nlockmgr /usr/bin/rpcinfo -u clientname status /usr/bin/rpcinfo -u clientname nlockmgr |
If any of these commands return RPC_TIMED_OUT, the rpc.statd or rpc.lockd process may be hung. Follow these steps to restart rpc.statd and rpc.lockd daemons:
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.
|