Bug 668906 - different mount from local host than from remote host
different mount from local host than from remote host
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
rawhide
Unspecified Unspecified
low Severity medium
: ---
: ---
Assigned To: Ian Kent
Fedora Extras Quality Assurance
: Reopened, Tracking
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-01-11 19:53 EST by Andrew McNabb
Modified: 2012-08-16 18:05 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-16 17:55:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrew McNabb 2011-01-11 19:53:50 EST
I have a map defined that mounts nfs4 directories.  In short, if I mount this from the local machine, it gets a completely different directory than if I mount it from a remote host.

My /etc/auto.master is defined as follows:
/net	/etc/auto.nfs4

My /etc/auto.nfs4 is defined as follows:
*   -fstype=nfs4,rw,nosuid,soft   &:/

Suppose the server's name is xyz and it exports /nfsroot as its NFSv4 root (fsid=0).  Then from host abc, the contents of /net/xyz are the same as /nfsroot on the server (this is the correct behavior).  However, if I am on the server (xyz), and I go to /net/xyz, then I see the contents of the root filesystem (/bin, /boot, ..., /usr, /var) instead of the contents of /nfsroot.

It appears that automount is trying to avoid going over NFS, which is a good thing, but it assumes that xyz:/ maps to the directory / when in fact /etc/exports defines /local to be the NFS root (with fsid=0).
Comment 1 Andrew McNabb 2011-01-11 19:54:50 EST
In case it helps, the contents of /etc/exports is as follows:

/local 192.168.36.0/22(rw,no_root_squash,no_subtree_check,fsid=0)
Comment 2 Andrew McNabb 2011-01-12 13:16:26 EST
The following executable map /etc/auto.nfs4 seems to work:

#!/bin/bash
key="$1"
hostname="$(hostname -s)"

if [[ $key = $hostname ]]; then
    echo "-fstype=bind  :/local"
else
    echo "-fstype=nfs4,rw,nosuid,soft  $key:/"
fi

However, this simple example assumes that it already knows where the NFS root is.  A better script would parse /etc/exports and look for the line with fsid=0.  Anyway, I hope this is helpful.  Thanks.
Comment 3 Ian Kent 2011-01-12 20:38:03 EST
(In reply to comment #2)
> The following executable map /etc/auto.nfs4 seems to work:
> 
> #!/bin/bash
> key="$1"
> hostname="$(hostname -s)"
> 
> if [[ $key = $hostname ]]; then
>     echo "-fstype=bind  :/local"
> else
>     echo "-fstype=nfs4,rw,nosuid,soft  $key:/"
> fi
> 
> However, this simple example assumes that it already knows where the NFS root
> is.  A better script would parse /etc/exports and look for the line with
> fsid=0.  Anyway, I hope this is helpful.  Thanks.

There isn't any standard interface (that I know of) for reading
the local exports file. Probably the better thing to do is to
tell autofs not to try a bind mount. You can do that by adding
a "port=<nfs server port>" option or using (the badly named
pseudo option) nosymlink.
Comment 4 Andrew McNabb 2011-01-13 12:41:14 EST
Having it do a bind mount is a desirable feature.  The problem is that it's getting the paths wrong for NFSv4.  The map that I shared above works around the problem in my environment, but it would be best if autofs knew how to find the root by default.
Comment 5 Ian Kent 2011-01-13 23:04:56 EST
(In reply to comment #4)
> Having it do a bind mount is a desirable feature.  The problem is that it's
> getting the paths wrong for NFSv4.  The map that I shared above works around
> the problem in my environment, but it would be best if autofs knew how to find
> the root by default.

Yeah, agreed, but it isn't always possible for autofs to get
that piece of information.

The same problem occurs for mounting from a remote server and
falling back to NFS v3. AFAICS, from the exports list that
comes from the server you cannot tell which export is the
global root.

Looking at the exports file for local mounts might be OK for
this case but it can change at any time so it's also
problematic.

The other difficulty is, what if nfs4 isn't specified and
the default for mount.nfs(8) is v4, then we need to start
looking into the local mount.nfs(8) configuration which may
or may not specify what we need to know (namely that NFS v4
is the default). That's because the defaults are usually not
specified in the configuration and we don't know what they
are. If we make assumptions base on what they are now they
will likely be wrong at some point as the defaults will
probably change over time.

I really don't want to start adding a bunch of special case
changes all to resolve the same issue and none being reliable.
That's going to end up a nightmare for everyone. So, I'm still
not sure what to do about this.
Comment 6 Andrew McNabb 2011-01-13 23:54:02 EST
As of Fedora 13, the default NFS version is 4 (http://docs.fedoraproject.org/en-US/Fedora/13/html/Release_Notes/sect-Release_Notes-File_Systems.html).  I agree that dealing with all of the special cases sounds awful, but it seems that working with NFSv4 should be the priority now that it's the default version.

By the way, I think the most reliable way to find out the NFSv4 root would be something more or less like this:

ROOT="$(exportfs -v |grep "fsid=0" |head -n 1 |awk '{ print $1; }')"

I think the exportfs command gives the current state of the server, even if the exports file has changed.

Anyway, it shouldn't be too hard to get the NFSv4 case to work, and I think that it should be supported by default even if NFSv3 isn't.  Including sample auto.net files for both NFSv3 and NFSv4 would of course make it easy to customize.
Comment 7 Orion Poplawski 2011-12-15 17:17:33 EST
If you're gonna use awk, use awk :)

exportfs -v  | awk '/fsid=0/ { print $1; exit }'

But anyways...  Ian - any more thoughts on this?  Any hope of getting bind mounts working for nfsv4 mounts?
Comment 8 Ian Kent 2012-01-02 19:17:16 EST
(In reply to comment #7)
> 
> But anyways...  Ian - any more thoughts on this?  Any hope of getting bind
> mounts working for nfsv4 mounts?

There is no way around requiring an NFS server that allows
the use of NFSv4 without the need to use the virtual root
feature, so that the export path can be the same as the
mount path.
Comment 9 Andrew McNabb 2012-01-03 12:33:53 EST
(In reply to comment #8)
> There is no way around requiring an NFS server that allows
> the use of NFSv4 without the need to use the virtual root
> feature, so that the export path can be the same as the
> mount path.

If all of the exports are under a single directory, though, there isn't anything particularly difficult about bind mounts, right? I was able to set up a script to do this, but it would be nice if it happened automatically.
Comment 10 Ian Kent 2012-01-05 03:53:05 EST
(In reply to comment #9)
> (In reply to comment #8)
> > There is no way around requiring an NFS server that allows
> > the use of NFSv4 without the need to use the virtual root
> > feature, so that the export path can be the same as the
> > mount path.
> 
> If all of the exports are under a single directory, though, there isn't
> anything particularly difficult about bind mounts, right? I was able to set up
> a script to do this, but it would be nice if it happened automatically.

Maybe.

Your saying special case the bind mount for nfs4 and spawn
a process to check if a virtual root is used and, if so,
obtain the path to the virtual root.

It's possible and I guess that the exports file is likely
to be a reasonable size.

Ian
Comment 11 Andrew McNabb 2012-01-05 12:04:52 EST
(In reply to comment #10)
> 
> Your saying special case the bind mount for nfs4 and spawn
> a process to check if a virtual root is used and, if so,
> obtain the path to the virtual root.
> 
> It's possible and I guess that the exports file is likely
> to be a reasonable size.

Yes.  Comment #6 shows a simple example of how this can be done.
Comment 12 Fedora End Of Life 2012-08-16 17:55:23 EDT
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 13 Orion Poplawski 2012-08-16 18:05:31 EDT
Let's keep hoping.

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