Bug 659887

(In reply to comment #0)
> I have a machine (prodigy) that exports /local with fsid=0.  On another machine
> with autofs, if I ls /net/prodigy, I see a single directory called local (NFSv3
> style) rather than the contents of local (NFSv4 style).  If I set "/net   
> -hosts -fstype=nfs4" in /etc/auto.master, then an ls of /net/prodigy still
> shows a directory called local, but an ls of /net/prodigy/local gives the error
> "ls: cannot open directory /net/prodigy/local: No such file or directory".  I
> would like autofs to automatically mount prodigy:/ on /net/prodigy, but I
> haven't been able to succeed at getting this to work.
> 
> If I am doing something wrong, please let me know, but I had assumed that
> autofs would use nfsv4 by default starting in Fedora 14.  Am I missing
> something?  Thanks.

The autofs internal hosts map doesn't know that you want it
to mount prodigy:/ instead of prodigy:/local. There is no
way for autofs to discover if a global root is being used
or not from the export information provided by mountd on
the other machine. So the server needs to honour mount requests
both for the global root path and the export path.

What distribution is in use on the server?

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

I've tried with both Fedora 12 and Fedora 14 as servers.

If autofs is mounting with NFSv4, then prodigy:/local is not a valid path in the first place (this is only a valid mount with NFSv3).  So it must be using NFSv3 for discovery, right?

(In reply to comment #3)
> I've tried with both Fedora 12 and Fedora 14 as servers.
> 
> If autofs is mounting with NFSv4, then prodigy:/local is not a valid path in
> the first place (this is only a valid mount with NFSv3).  So it must be using
> NFSv3 for discovery, right?

I believe that used to be the case but I thought the restriction
of mounting the NFS global root as / from the server had been
removed in around F14. It's true that this would introduce
conflicts between server versions but it had to be done. Other
industry NFS servers allow both forms I believe.

Can you post an autofs debug log.
Uncomment and set LOGGING="debug" in /etc/sysconfig/autofs and
ensure the syslog facility "daemon" is being captured by syslog.
You can do this by adding something like 
"daemon.*    /var/log/debug.log"
to /etc/rsyslog.conf, touching the log file if it doesn't exist
and restarting rsyslog.

Created attachment 472916 [details]
debug.log

I'm attaching debug.log from when I went to /net/0potato and /net/0potato/local.

[sorry for not looking into this over the holidays]

It looks like it works as long as it uses NFSv3 (which seems to be the case in the debug.log I just attached).  Oddly, in /etc/sysconfig/autofs, it has MOUNT_NFS_DEFAULT_PROTOCOL=4, so I'm surprised that it's using NFSv3.

For NFSv4, I think the correct behavior would be to simply mount 0potato:/ as /net/0potato rather than looking at the export list.  I've found a few web pages that seem to indicated that showmount isn't used with NFSv4 (e.g., "For nfsv4, the old showmount command will no more be used, because '/' can always be mounted.").  Is there any easy way to configure this with autofs?  It seems that it shouldn't be too hard, but I admit I'm not very experienced with autofs.  In the meantime, I'll keep on working on it and see what I can figure out.

Okay, I think I have something that works for nfs4, except for the lack of backwards compatibility with nfs3.  I changed the /net line in /etc/auto.master to:

/net    /etc/auto.nfs4

and then I set /etc/auto.nfs4 to the following:

*       -fstype=nfs4,rw,nosuid,soft     &:/

Since NFSv4 has a single unified root instead of multiple unconnected exports, doing this single mount per host seems to give the correct behavior (for NFSv4).  Ideally, there would be some way to automatically switch between the NFSv3 and NFSv4 behaviors.

I've still been using a custom auto.nfs4 file, and I was just wondering whether I've missed any developments in the meantime. By the way, my auto.nfs4 is slightly different from what I described in comment #7. It's now:

"""
key="$1"
hostname="$(hostname -s)"

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

Could this be related to my problem that I can't get autofs on another (Mandriva) machine to be able to automount a Fedora 16 x86_64 machine?  Details are on Fedora Forum here:  http://forums.fedoraforum.org/showthread.php?t=278702  In the latest update http://forums.fedoraforum.org/showpost.php?p=1569503&postcount=3 I mention that manual mounting works fine, yet automounting won't work when trying to mount the F16 machine.  All other cases work fine.  Thanks.

(In reply to comment #9)
> Could this be related to my problem that I can't get autofs on another
> (Mandriva) machine to be able to automount a Fedora 16 x86_64 machine?  Details
> are on Fedora Forum here: 
> http://forums.fedoraforum.org/showthread.php?t=278702  In the latest update
> http://forums.fedoraforum.org/showpost.php?p=1569503&postcount=3 I mention that
> manual mounting works fine, yet automounting won't work when trying to mount
> the F16 machine.  All other cases work fine.  Thanks.

I have no idea what patches have been applied to the Mandriva
package.

Your problem could be the mountd version autofs is trying is
not available.

ftp://ftp.kernel.org/pub/linux/daemons/autofs/v5/patches-5.0.6/autofs-5.0.5-fix-mountd-vers-retry.patch

but there are a number of other changes that could also be
related, the Mandriva maintainer needs to keep up with what's
happening upstream to deal with that.

OK, fair enough.  I'm using two different Mandriva distribution versions, 2007.0 and 2010.2.  The first uses autofs-5.0.1-0.rc3.1.2mdv2007.0 and the second uses autofs-5.0.5-2mdv2010.1.  I won't ask you to know what's in those.  But, I would like to learn a bit.  Is mountd on the NFS server or client?  My client is Mandriva trying to use its older version of autofs and older version of mount.  My NFS server is F16 with a newer version of NFS.  My naive brain thinks that Mandriva's autofs hands off to its own mount, which negotiates with F16's NFS server.  Is that about right?  Do you know of a document which I could refer to to understand how this is supposed to work?  Thanks.

(In reply to comment #11)
> OK, fair enough.  I'm using two different Mandriva distribution versions,
> 2007.0 and 2010.2.  The first uses autofs-5.0.1-0.rc3.1.2mdv2007.0 and the
> second uses autofs-5.0.5-2mdv2010.1.  I won't ask you to know what's in those. 
> But, I would like to learn a bit.  Is mountd on the NFS server or client?  My
> client is Mandriva trying to use its older version of autofs and older version
> of mount.  My NFS server is F16 with a newer version of NFS.  My naive brain
> thinks that Mandriva's autofs hands off to its own mount, which negotiates with
> F16's NFS server.  Is that about right?  Do you know of a document which I
> could refer to to understand how this is supposed to work?  Thanks.

rpc.mountd runs on the server, you can see that in the startup
messages and by lookup at a process listing.

autofs does use mount(8) (and mount then uses mount.nfs) but
when you use the hosts map (aka. "-hosts" in the master map)
then autofs will request the list of exports from mountd on
the server to construct the mount tree. That bit is nothing
to do with mount which, obviously, mounts NFS locations.
showmount(8) is an example of a program which requests the
list of export from the server mountd (the autofs exports
query code was modelled on that code.

As far as documentation goes, not really, but have a look at
http://www.linux-nfs.org/ and, although quite old now, "Managing
NFS and NIS" is still worth a look. A web search on "managing
nfs and nis" should return plenty of links to go on with.

Your description is wonderful. I managed to cause failures of showmount wherever there is a failure of autofs. For instance, this is working:

f16machine> sudo showmount --exports f16machine
Export list for f16machine:
/projects 192.168.1.0/24
/nobackup 192.168.1.0/24
/music    192.168.1.0/24
/home     192.168.1.0/24

mandriva1> sudo showmount --exports mandriva2
Export list for mandriva2:
/spare    192.168.1.0/24
/projects 192.168.1.0/24
/nobackup 192.168.1.0/24
/music    192.168.1.0/24
/media    192.168.1.0/24
/home     192.168.1.0/24

This is not working:

mandriva1> showmount --exports f16machine
mount clntudp_create: RPC: Port mapper failure - RPC: Unable to receive

I suspect that if I can get showmount to work, then autofs will work.  Visa versa would maybe be true too.

I'm off to read up on that NFS at the link you supplied.  I'm not using NIS/YP on any of my machines.  I used to know this stuff better back when NFS2 was modern.

Thanks again!

I found the trouble.  It was my firewall on the Fedora 16 machine.  I needed to open up ports 111 and 20048 for both tcp and udp.  The story of my debugging is here: http://forums.fedoraforum.org/showpost.php?p=1569808&postcount=4

rpcinfo shows my ports open to the clients of my F16 server now.
showmount shows mount points accessible from the clients.
autofs succeeds in mounting the F16 server from the other clients.

Thanks very much for the comment about showmount.  It was the key to my debugging method.

I'm ending my day on a very happy note, thanks to Ian Kent.

(In reply to comment #14)
> I found the trouble.  It was my firewall on the Fedora 16 machine.  I needed to
> open up ports 111 and 20048 for both tcp and udp.  The story of my debugging is
> here: http://forums.fedoraforum.org/showpost.php?p=1569808&postcount=4

Oh right, yes, you need to be able to be able to talk to the
portmapper (or rpcbind) to get the port that mountd is listening
on and then you need to be able to talk to the mountd.

> 
> rpcinfo shows my ports open to the clients of my F16 server now.
> showmount shows mount points accessible from the clients.
> autofs succeeds in mounting the F16 server from the other clients.

Right, I guess port 2049 is already open.

> 
> Thanks very much for the comment about showmount.  It was the key to my
> debugging method.

Cool. Since you are talking about NFSv4 be aware that there is a
limitation in earlier Linux implementations where the server only
provides NFS mounts via a global root. Later version allow mounting
of exported paths similar to NFSv3 and lower.

For autofs the global root just means that the exported path
doesn't match the export path (provided by mountd) needed to
mount the location so the  hosts map won't work properly.

Also, if the NFSv4 server only provides the global root exports
for NFSv4 then the client can't fall back from NFSv4 to NFSv3
(when v4 isn't available) since the mount location path is
different.

I guess this will give you more to research, ;)
You won't find much on NFSv4 in the book I mentioned btw.

Ian

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is 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" 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

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.