Description of problem:
When a Solaris 10 NFS client tries to mount an export on a RHEL4 (and RHEL5)
server, "Permission denied" is reported and the mount fails.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Add a normal entry to /etc/exports
2. Attempt to mount export on a Solaris 10 machine
Permission denied reported.
If NFSv4 is disabled on either side, the mount works fine again. I note that
this bug (https://bugzilla.redhat.com/show_bug.cgi?id=166822) was filed, but
never really resolved. The fsid fix mentioned there does not work for me. The
only solution is to either tell the Solaris 10 client to use NFSv3 at most or
tell rpc.nfsd on the Linux side to do the same.
This happens with RHEL5 and Fedora NFS servers as well.
I am not clear if this is an issue on the RH side or the Solaris side.
Will file an SR for this issue as well.
Created attachment 290864 [details]
tcpdump output on RHEL4 server
tcpdump -i eth0 -n -vv -s 0 -w /tmp/nfs.dmp host barn
Where 'barn' is the Solaris 10 NFS client.
In the file, 10.49.6.46 is the RHEL4 server and 10.27.6.19 is the Solaris 10
These bugs from upstream may be interesting:
As is this page from Sun:
The thing is, even when I use the following in my /etc/exports:
(Which is an NFSv3 style export), Solaris 10 clients still can't seem to mount it.
Who's right and who's wrong here? :-)
This may also be of interest -- and worthwhile to backport?
Oh, d'oh, that patch was by Steve himself. :) My bad. Will this find its way
into RHEL4 eventually?
Likely not, though it might make it into RHEL5.
Can you post your /etc/exports file and the command you're using on the solaris
side to mount the filesystem?
Pretty basic NFSv3 style exports file.
On the Solaris side, we're using the automounter to access the directories. ie:
solaris10% cd /net/linuxhostname/install
This fails as long as NFSv4 is enabled either on the Solaris10 client side or
the RH server side.
Note that per this thread:
I was able to use Steve's patch to make this work correctly. Specifically here:
I will try backporting the patch into RHEL4's nfs-utils on my own.
Let me know if you need any additional information.
Ok, I think I understand the problem. Your exports don't have any entries with
the option "fsid=0". That's how the root of the NFSv4 namespace is designated.
Solaris implicitly declares the root directory as the root of the NFSv4
namespace. Linux does not -- this has to be done manually.
This page describes this in a bit more detail:
This is really a configuration issue, so I'm going to close this as NOTABUG.
My understanding is that we will not be backporting the dynamic pseudo root
patches to RHEL4, but RHEL5 is still a possibility. The approach you link to
above is still being debated upstream, and likely won't have enough soak time
there before RHEL4 goes into maintenance mode.
Closing this as NOTABUG, please reopen if you consider this to be in error.
Even with fsid=0 in my export line, the automounter from Solaris still will not
It _will_ work with fsid=0 if I manually do a mount from Solaris. The problem
is that the namespace exposed is incorrect.
RH seems to expect an NFSv4 mount to request / as the mount for the export
tagged fsid=0. Solaris sees "/install" and tries to mount that instead.
If you have access to a Solaris 10 machine this should be reproduceable.
Remember this is with the automounter, _not_ with a manual mount.
I did reopen this and can give you a detailed example if that would help clarify
> Even with fsid=0 in my export line, the automounter from Solaris still will
> not work.
That's because Solaris is querying the NFSv3 mount daemon and assumes that it
can mount the same set of directories using NFSv4. This isn't necessarily
correct because the NFSv4 namespace doesn't map directly to the NFSv3 namespace
unless you set it up that way.
> It _will_ work with fsid=0 if I manually do a mount from Solaris. The problem
> is that the namespace exposed is incorrect.
The namespace is not incorrect -- it's simply different from the NFSv3 namespace.
> RH seems to expect an NFSv4 mount to request / as the mount for the export
> tagged fsid=0. Solaris sees "/install" and tries to mount that instead.
Right. That's because fsid=0 denotes the _root_ of the NFSv4 namespace. You're
free to map the root to anything you like in Linux. Solaris is constrained to
mapping the root of the NFSv4 namespace to /.
To work around this, you might want to do something like this in /etc/exports:
Bind mount /install, /yum3, and /var/www/mrepo under /export. Then run exportfs
-a. This is essentially what Steve's patches do, just in a less automatic fashion...
As a side note, "async" can leave you with data corruption. See several notes in
the NFS FAQ for more info:
Again closing this again as NOTABUG since this is just the NFSv4 server on RHEL4
working as designed.
Thanks Jeff. Will consider these workarounds.
Should I reopen another bug for RHEL5 and also a new SR for RHEL5 in the hopes
of getting the pFS patch backported to RHEL5 at some point?
Opening a SR might be the best thing. There are already a couple of BZ's open
related to this:
...so you might want to mention those when you open the SR. My gut feeling on
this is that the changes will be too much for RHEL4, but a possibility for RHEL5.
Sorry, I posted the exports example in haste yesterday. It's wrong. This would
...also to be safe, you'll probably want to make /export a real filesystem.
Otherwise, a client could spoof filehandles and get to stuff in your root
FWIW, I also posted a "rebuttal" to Tom's blog post, so that anyone else who
runs across it will have a bit more info to go on: