Send in your Unix questions today! |
See additional Unix tips and tricks
I hadn't seen a stale NFS file handle for more than a decade, so this mount error surprised me.
|
fermion:/ # mount boson:/cdrom/studio_9_solsparc /studio_9_solsparc
nfs mount: mount: /studio_9_solsparc: Stale NFS file handle
|
I was trying to mount a CD ROM loaded on a remote system because the target system didn't have a CD ROM drive. This didn't seem like an unusual thing to do. In fact, I'd been doing the same thing only a few weeks earlier. I first tried using /cdrom as the mount point, then tried working with a new created directory. In both cases, the mount failed with the "Stale NFS file handle" error. It took me a while to realize that the problem related to the fact that boson, recently upgraded to Solaris 10, was running a newer version of NFS than fermion, a Solaris 9 server.
Solution: Thinking about NFS on my newly installed Solaris 10 server quickly drew my attention to the /etc/default/nfs file. Like other files in the /etc/default directory, this file sets configuration parameters for particular services. In this case, the file contains configuration information for both lockd and nfsd. The settable parameters for Solaris 10 include options which are new in Solaris 10 -- all those marked with an asterisk in the list below.
*GRACE_PERIOD=num
LOCKD_GRACE_PERIOD=num
LOCKD_LISTEN_BACKLOG=num
LOCKD_RETRANSMIT_TIMEOUT=num
LOCKD_SERVERS=num
NFSD_DEVICE=devname
NFSD_LISTEN_BACKLOG=num
NFSD_MAX_CONNECTIONS=num
NFSD_PROTOCOL=ALL
NFSD_SERVERS=num
*NFSMAPID_DOMAIN=domain-string
*NFS_CLIENT_VERSMAX=num
*NFS_CLIENT_VERSMIN=num
*NFS_SERVER_DELEGATION=on | off
*NFS_SERVER_VERSMAX=num
*NFS_SERVER_VERSMIN=num
|
Of these, the NFS_SERVER_VERSMIN and NFS_SERVER_VERSMAX parameters supposedly determine the NFS versions that the server will support. The defaults are 2 for NFS_SERVER_VERSMIN and 4 for NFS_SERVER_VERSMAX. A quick check with the man page confirmed this:
NFS_SERVER_VERSMIN=num
NFS_SERVER_VERSMAX=num
The NFS server only uses NFS versions in the range
specified by these variables. Valid values or versions
are: 2, 3, and 4. As with the client, the default is to
leave these variables commented out and the default
minimum version is 2, while the default maximum version
is 4.
|
However, since the defaults didn't seem to be allowing my Solaris 10 server to accommodate my Solaris 9 client, I tried some other settings. I tried setting NFS_SERVER_VERSMIN explicitly to 2 and then 3, but I found that only setting NFS_SERVER_VERSMAX to 2 worked. Of course, this puts a damper on my use of NFS Version 4, but I needed this mount to solve an immediate problem and figure that, soon enough, my servers will all be migrating to Solaris 10 and I will no longer have to deal with this issue. To switch the NFS_SERVER_VERSMAX parameter on my Solaris 10 server, I changed this line: #NFS_SERVER_VERSMAX=4 to NFS_SERVER_VERSMAX=2 I then restarted NFS on my Solaris 10 server using the /etc/init.d/nfs.server stop and /etc/init.d/nfs.server start commands and reshared my CD ROM as shown below.
# /etc/init.d/nfs.server stop
# /etc/init.d/nfs.server start
# share -F nfs -o ro /cdrom/studio_9_solsparc
To confirm that my CD ROM was shared, I issued the share command by itself.
# share
- /cdrom/studio_9_solsparc ro ""
On my Solaris 9 NFS client, I then mounted my CD ROM and examined its contents to be sure that the mount had worked properly.
fermion:/ # mount boson:/cdrom/studio_9_solsparc /studio_9_solsparc
fermion:/ # ls -l /studio_9_solsparc
total 259
dr-xr-xr-x 5 root root 2048 Jul 28 2004 Documentation
dr-xr-xr-x 2 root root 2048 Jul 29 2004 LICENSE_README
-r-xr-xr-x 1 root root 14873 Aug 6 2004 batch_installer
-r-xr-xr-x 1 root root 15507 Aug 6 2004 installer
dr-xr-xr-x 4 root root 2048 Aug 6 2004 kits
-r--r--r-- 1 root root 34184 Jul 29 2004 release_notes_en.html
-r--r--r-- 1 root root 34130 Jul 30 2004 release_notes_ja.html
-r--r--r-- 1 root root 25159 Jul 30 2004 release_notes_zh.html
-r-xr-xr-x 1 root root 1010 Aug 6 2004 volstart
|
Once the mount was working properly, I was able to proceed with my installation. This is probably a Solaris bug, but I was glad there was a way around the problem that involves only a configuration change and will be easy to reverse.
