Bug 153670 - autofs does not do bind mounts with nfsv4
autofs does not do bind mounts with nfsv4
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ian Kent
Brock Organ
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2005-04-04 16:53 EDT by Orion Poplawski
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-04-17 18:24:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Have sun_mount call mount_nfs for fstype=nfs4 and variants thereof. (539 bytes, patch)
2005-04-05 12:20 EDT, Jeff Moyer
no flags Details | Diff

  None (edit)
Description Orion Poplawski 2005-04-04 16:53:32 EDT
Description of problem:

I'm trying out NFSv4.  We have a /data directory tree of nfs mounts that I've
made a NFSv4 version of like so:

$ cat /etc/auto.master
/data           auto.data       intr
/data4          auto.data4      fstype=nfs4,intr,rsize=32768,wsize=32768

auto.data and auto.data4 are essentially the same, but without the /export
prefix in auto.data4 (since that is the fsid=0 root for NFSv4).

Machines /etc/exports look like:

/export         *.cora.nwra.com(rw,sync,fsid=0)
/export/waves2          *.cora.nwra.com(rw,sync,nohide)
/export/radar3          *.cora.nwra.com(rw,sync,nohide)

and all exported file systems are mounted under /export.

Now, when automount mounts a directory in /data that is hosted on the local
machine, I get a bind mount.  But when it mounts a directory in /data4, I get an
NFSv4 mount.

sample mount output:

/export/waves2 on /data/waves2 type none (rw,bind)
alexandria:/waves2 on /data4/waves2 type nfs4

Can this be fixed somehow?  Also, I see in the automount entries a "maxproto=4"
statement.  I assume this would refer to the NFS version, but this doesn't not
appear to have any effect and you need to specify -fstype=nfs4 in the mount
options.  Or is that the autofs protocol version?

automount(pid3694) on /data type autofs (rw,fd=5,pgrp=3694,minproto=2,maxproto=4)

Version-Release number of selected component (if applicable):

How reproducible:
Comment 1 Jeff Moyer 2005-04-05 12:10:15 EDT
I'm guessing this configuration triggers the generic mount routine, instead of
the nfs mount routine:

	if (!strcmp(fstype, "nfs")) {
		rv = mount_nfs->mount_mount(root, mountpoint, strlen(mountpoint),
					    what, fstype, options, mount_nfs->context);
	} else {
		/* Generic mount routine */
		rv = do_mount(root, mountpoint, strlen(mountpoint), what, fstype,

This should be fairly simple to fix, if my guess is right.  I'll attach a patch.
Comment 2 Jeff Moyer 2005-04-05 12:20:08 EDT
Created attachment 112719 [details]
Have sun_mount call mount_nfs for fstype=nfs4 and variants thereof.

This should address your problem.  The patch was made against the latest CVS,
so it may or may not apply to 4.1.3-28.  Let me know if you need help with
getting this applied/built.

Comment 3 Orion Poplawski 2005-04-05 13:00:14 EDT
This doesn't work.  First of all, it appears to be trying to mount via nfs3 now
rather than nfs4.  Not seeing any errors from an attempt to --bind mount, but I
imagine that would fail too because it would be trying to mount from /data1
rather than /export/data1

Apr  5 10:55:15 alexandria rpc.mountd: refused mount request from
alexandria.cora.nwra.com for /data1 (/): not exported
Apr  5 10:55:15 alexandria automount[6123]: >> mount: alexandria:/data1 failed,
reason given by server: Permission denied
Apr  5 10:55:15 alexandria automount[6123]: mount(nfs): nfs: mount failure
alexandria:/data1 on /data/sw1
Apr  5 10:55:15 alexandria automount[6123]: failed to mount /data/sw1
Comment 4 Jeff Moyer 2005-04-05 13:06:18 EDT
Okay, thanks for the info.  I'll look into this further.  One thing we could do
is to make mount_generic do bind mounts.  I want to investigate a bit more to
make sure this is the best way to do this, though.

Comment 5 Orion Poplawski 2005-04-05 13:37:58 EDT
I installed the rawhide version of autofs and it looks like it just no longer
does bind mounts at all for local nfs filesystems:

alexandria:/export/waves2 on /data/waves2 type nfs

Something appears to have changed between the FC3 version and autofs-4.1.3-107
Comment 6 Jeff Moyer 2005-04-05 14:01:14 EDT
Please include the full contents of all maps involved and I'll take a closer
look.  I cannot reproduce the problem you have with 4.1.3-107.

Comment 7 Chris Feist 2005-04-05 14:17:51 EDT
I think 4.1.3-107 had a problem with local mounts not using --bind.  It should
be fixed in 4.1.3-114.

Comment 8 Orion Poplawski 2005-04-05 16:14:01 EDT
Okay, rebuilt with devel version from CVS (123) plus the above patch.  Now I
think we are just missing the /export path:

Apr  5 14:11:10 alexandria automount[6013]: >> mount: special device /data1 does
not exist
Apr  5 14:11:10 alexandria automount[6013]: failed to mount /data4/sw1
Apr  5 14:11:10 alexandria automount[6015]: >> mount: special device /data1 does
not exist
Apr  5 14:11:10 alexandria automount[6015]: failed to mount /data4/sw1

Not sure how autofs would be able to determine that the nfsv4 paths are relative
to export without parsing /etc/exports:

/export                 *.cora.nwra.com(rw,sync,fsid=0)
/export/amanda          *.cora.nwra.com(rw,sync,nohide,no_root_squash)
/export/data1           *.cora.nwra.com(rw,sync,nohide,no_root_squash)
/export/clouds2         *.cora.nwra.com(rw,sync,nohide)
/export/radar3          *.cora.nwra.com(rw,sync,nohide)
/export/soldyn2         *.cora.nwra.com(rw,sync,nohide)
/export/bigmeadow       *.cora.nwra.com(rw,sync,nohide)
/export/waves2          *.cora.nwra.com(rw,sync,nohide)
Comment 9 Orion Poplawski 2005-05-09 17:53:45 EDT
I'm seeing local NFSv3 mounts not using --bind again with 4.1.4-8:

hawk:/export/web on /data/web type nfs (rw,intr,addr=
[root@hawk ftp]#
Comment 10 Jeff Moyer 2006-04-17 16:50:01 EDT
I think this should (again) be resolved in rawhide/fc5.

The issue with NFSv4 mounts stands.  I think that we *should* use the nfs4
protocol to mount those local directories.  The automounter really shouldn't
know about nfs4 internals just so that it can do a bind mount.

So, we still need to fix this.

Thanks for your continued analysis.
Comment 11 Orion Poplawski 2006-04-17 17:34:50 EDT
I'm sorry, I didn't follow that.

I'm running FC4 and FC5 here now.  I get local bind mounts for NFSv3.

If you think the local directories *should* be mounted via nfs4 rather than
bind, than this bug is resolved, NOTABUG.  I'm fine with that, assuming a
minimal performance hit.
Comment 12 Jeff Moyer 2006-04-17 17:52:34 EDT
In the event that you have "fstype=nfs4" in your options, the automounter should
not attempt a bind mount when the server is localhost.  The reason for this is
that the automounter would need nfsv4 specific information to determine where
the mount actually comes from.  As you noted, it's not straight-forward as it is
in v2 and v3.

So, for your nfsv2 and nfsv3 mounts, the automounter should continue to use bind
mounts.  If you specify -fstype=nfs4, then you should get a mount via nfs4.

Clear as mud?
Comment 13 Orion Poplawski 2006-04-17 18:14:48 EDT
Yes, and that's what I'm seeing right now on FC4 and FC5.  So I don't understand
the "So, we still need to fix this." in comment #10.

Comment 14 Jeff Moyer 2006-04-17 18:24:48 EDT
OK, that's a misunderstanding on my part, then.  I'll close this.  Thanks!

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