Bug 427583 - Solaris 10 clients cannot mount NFS exports from RHEL (NFSv4 specific)
Solaris 10 clients cannot mount NFS exports from RHEL (NFSv4 specific)
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nfs-utils (Show other bugs)
4.6
All Linux
low Severity medium
: rc
: ---
Assigned To: Jeff Layton
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-04 16:32 EST by Ray Van Dolson
Modified: 2009-06-29 09:35 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-11 19:09:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
tcpdump output on RHEL4 server (12.33 KB, application/octet-stream)
2008-01-04 16:38 EST, Ray Van Dolson
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 166822 None None None Never

  None (edit)
Description Ray Van Dolson 2008-01-04 16:32:01 EST
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.
Comment 1 Ray Van Dolson 2008-01-04 16:38:28 EST
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.
Comment 2 Ray Van Dolson 2008-01-07 13:53:29 EST
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? :-)
Comment 3 Ray Van Dolson 2008-01-07 14:36:55 EST
This may also be of interest -- and worthwhile to backport?

  http://linux-nfs.org/pipermail/nfsv4/2007-December/007248.html
Comment 4 Ray Van Dolson 2008-01-07 14:40:23 EST
Oh, d'oh, that patch was by Steve himself. :)  My bad.  Will this find its way
into RHEL4 eventually?
Comment 5 Jeff Layton 2008-01-11 15:51:58 EST
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?

Comment 6 Ray Van Dolson 2008-01-11 16:01:16 EST
/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.
Comment 7 Jeff Layton 2008-01-11 16:23:04 EST
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.

Comment 8 Ray Van Dolson 2008-01-11 16:27:01 EST
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.
Comment 9 Ray Van Dolson 2008-01-11 16:28:54 EST
I did reopen this and can give you a detailed example if that would help clarify
my issue.
Comment 10 Jeff Layton 2008-01-11 16:48:15 EST
> 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/
Comment 11 Jeff Layton 2008-01-11 19:09:08 EST
Again closing this again as NOTABUG since this is just the NFSv4 server on RHEL4
working as designed.
Comment 12 Ray Van Dolson 2008-01-11 19:51:35 EST
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?
Comment 13 Jeff Layton 2008-01-12 06:47:53 EST
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.
Comment 14 Jeff Layton 2008-01-12 06:54:13 EST
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.
Comment 15 Jeff Layton 2008-01-14 07:36:25 EST
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


Note You need to log in before you can comment on or make changes to this bug.