Red Hat Bugzilla – Bug 51768
Solaris 8 machines fail to mount Linux server's /home shared FS.
Last modified: 2007-03-26 23:48:02 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
Description of problem:
I can share /home and numerous other partitions and directories using
Linuxconf. I do an exportfs -r and then an exportfs and the shared
directories all show up. We have numerous Solaris machines, some with
Solaris 2.6, one with Solaris 7, and numerous with Solaris 8. The 2.6 and
7 machines can mount every directory being shared out by the Linux server
(even the /home). The Solaris 8 machines can mount all the shared
directories except for one, /home. When they attempt to mount it they
receive a "Permission denied" error. The command I am using to mount the
Linux's /home directory on the solaris machines is as follows: "mount -F
nfs jcatslx0:/home /mnt" Why is it I can mount all the other shared
directories except /home? and why can the Solaris 2.6 and 7 machines do
it. Sounds like a conflict with the current version of nfs-utils (I have
0.3.1-5 loaded) and the Solaris 8 nfs client component. I have noticed
that if I uninstall the nfs-utils rpm in the GnomeRPM utility and then
reinstall it, the Solaris 8 machines can then mount the /home partition,
but as soon as I reboot them they lose the ability and get the "permission
denied" error. I also went to the rawhide ftp area and downloaded nfs-
utils 0.3.1-11, but it didn't resolve the problem. Any help would be
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.See Description above
Recently figured out that in order to receive the "Permission Denied" error
upon mounting the linus server's /home directory, you must have a sub-directory
of /home already mounted. In our case we have the
directory /home/jdata30/data_30 mount up at boot time (in the Solaris 8
machines' /etc/vfstab file). So just prior to tryinf to mount the linux
machine's /home directory you can do a "df -k" and see the linux
machine's /home/jdata30/data_30 directory already mounted on a mount point (in
our case the mount point for /home/jdata30/data_30 is /home/jdata30/data_30).
I now believe the Solaris 2.6 machines would also get the persmission denied
error if they had the /home/jdata30/data_30 directory mounted ahead of time as
well (they don't mount any directories from the linux server at boot time).
After I figured out that having a /home sub-directory mounted prior to
attempting to mount /home was causing the problem, I figured out a way of
getting around this problem. What I do now if I need to mount the linux
server's top level /home directory on one of the Solaris 8 machines:
1. "umount" the /home/jdata30/data_30 directory on the Solaris 8 machine
(as root of course).
2. go over to the linux 7.1 server and do a "exportfs -r" as root.
3. go back to the Solaris machine and now mount the linux machine's /home
directory ("mount -F nfs jcatslx0:/home /mnt"). This time it will work.
4. mount the /home/jdata30/data_30 At this point both the linux
machine's /home and /home/jdata30/data_30 directory structures are mounted
(separate mount points) and are both accessiable.
Once I'm finished using the /home directory, I can then umount both the /home
and /home/jdata30/data_30 directories, do a "exportfs -r" on the linux server
again, and finally remount the /home/jdata30/data_30 directory. Found that if
you don't unmount the /home/jdata30/data_30 prior to the exportfs -r command,
it will show up as a stale FS when doing a "df -k" on the solaris machine. Is
the nfs-utils (nfs server) portion on the linux machine working properly, or is
this something that needs to be fixed by you guys? I have this work-around,
but I'm not exactly thrilled about it. Let me know if this is how the Linux
server should be handling it, or if there is a bug in the nfs-utils. Thanks
This is actually correct behaviour by the NFS Server. In general, NFS servers
do not allow hierarchical exports. The one exception to this is if the exported
directories do not themselves lie on the same file system.