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): nfs-utils-1.0.6-84.EL4 How reproducible: Always Steps to Reproduce: 1. Add a normal entry to /etc/exports 2. Attempt to mount export on a Solaris 10 machine 3. Actual results: Permission denied reported. Expected results: Successful mount. Additional info: 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 client.
These bugs from upstream may be interesting: http://bugzilla.linux-nfs.org/show_bug.cgi?id=75 http://bugzilla.linux-nfs.org/show_bug.cgi?id=153 As is this page from Sun: http://blogs.sun.com/tdh/entry/linux_nfsv4_namespace_implementation_fools The thing is, even when I use the following in my /etc/exports: /install *(rw,insecure,async) (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? http://linux-nfs.org/pipermail/nfsv4/2007-December/007248.html
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?
/etc/exports: /install *(rw,insecure,async) /yum3 *(rw,insecure,async) /var/www/mrepo *(ro,async) 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: http://linux-nfs.org/pipermail/nfsv4/2008-January/007465.html I was able to use Steve's patch to make this work correctly. Specifically here: http://linux-nfs.org/pipermail/nfsv4/2008-January/007479.html 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: http://wiki.linux-nfs.org/wiki/index.php/Nfsv4_configuration 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 work. 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 my issue.
> 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: /install *(rw,insecure,async) /yum3 *(rw,insecure,async) /var/www/mrepo *(ro,async) /export *(ro) /export/install *(rw,insecure,async,fsid=0) /export/yum3 *(rw,insecure,async,fsid=0) /export/var/www/mrepo *(ro,async,fsid=0) 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: http://nfs.sourceforge.net/
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: 237108 247759 ...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 be correct: /install *(rw,insecure,async) /yum3 *(rw,insecure,async) /var/www/mrepo *(ro,async) /export *(ro,fsid=0) /export/install *(rw,insecure,async) /export/yum3 *(rw,insecure,async) /export/var/www/mrepo *(ro,async) ...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 filesystem.
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: http://blogs.sun.com/tdh/entry/linux_nfsv4_namespace_implementation_fools