This post addresses failures on Network File System which result in a Solaris 10 client being unable to mount remote filesystem on the NFS server. Common symptoms are:
- NFS write error
- RPC timed out
- NFS errors cannot establish nfs service
- Unable to mount NFS error
- RPC: Program not registered
- NFS server not responding
- “Permission denied” errors when Solaris 10 NFSv4 is in use
Here are the steps you should take when troubleshooting an NFS mount issue.
1. Confirm NFS related OS packages are installed
The NFS related binaries, libraries, configuration files become installed with the Solaris 10 or earlier packages SUNWnfscr, SUNWnfscu, SUNWnfsskr, SUNWnfssr and SUNWnfssu. Solaris 11, aside from the core packages, requires the service/file-system/nfs and system/file-system/nfs (NFS client) packages. The Solaris 10 NFS related man pages become installed from the Solaris sw package SUNWman. The Solaris 11 NFS man pages are contained in the above NFS packages.
2. Determine NFS version is correct
To determine what version and transport of NFS is currently available, run rpcinfo on the NFS server.
# rpcinfo -p | grep 100003 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs
The second column above is the NFS version, the third column is the transport protocol.
3. Verify you can contact target server
Check that the NFS server is reachable from the client. On the client, type the following command.
# /usr/sbin/ping nfsserver nfsserver is alive
4. Verify service daemons are up and running.
On the server
1. confirm S10 smf network nfs server services are online:
# svcs -a |grep nfs
2. statd, lockd , mountd and nfsd processes should be running:
# ps -elf |grep nfs
3. compare the times when nfsd and mountd started with the time when rpcbind was started. The rpcbind MUST have started before the NFS Daemons. verify that the NFS programs have been registered with rpcbind:
# rpcinfo -s
4. To confirm specific RPC service use the following commands:
# rpcinfo -t100003 # rpcinfo -t100005 # rpcinfo -t 100021
logging may be enabled (not for NFSv4).
On the client
1. confirm S10 smf network nfs client services are online:
# svcs -a |grep nfs
2. statd, lockd should be running
# ps -elf |grep nfs
3. You can verify the server is working from the client side.
# rpcinfo -s [serverIP] | egrep "nfs|mountd|lock"
# rpcinfo -u [serverIP] 100003 # rpcinfo -u [serverIP] 100005 # rpcinfo -u [serverIP] 100021
check for interferences from NFS client caching.
5. Confirm proper syntax of dfstab share entries on NFS server
The syntax of /etc/dfs/dfstab should also be checked. For more information see the man page for share_nfs. Also refer the below post.
6. Confirm file system is shared as seen on both ends
The NFS server is the system that will share a file system. The “showmount -e” or “dfshares” command will display what is being shared. From the client use command with nfs server name.
# showmount -e [NFS server IP]
7. Verify mount point exists and is in use
To display statistics for each NFS mounted file system, use the below command
# nfsstat -m
This command will also tell you which options were used when the file system was mounted. You can also check the contents of the /etc/mnttab. It should show what is currently mounted. Lastly, check the dates between the server and the client. An incorrect date may show the file created in the future causing confusion.
8. Confirm proper permissions and privileges
Permissions need to be checked in two places. First, the underlying mount point. The owner and permissions of the underlying directory should be accessible by nfsd (root 755).
Second, the files being shared. These files should be accessible by the user accessing the filesystem.
9. Check automounter is configured properly if using autofs
The automounter mounts files systems upon request. Since the mount is automatic there is no need to issue the mount command. Resources that have been idle for 10 or more minutes will automatically unmounted. There are several automap types, indirect maps, direct maps, and special maps. The automount daemon (automountd) registers locally to the client system 100099.
Conclusion
At this point, if you have validated that each troubleshooting step above is true for your environment, and the issue still exists, further troubleshooting is required. Providing an explorer for analysis will be useful when engaging Oracle support engineer.