Red Hat Bugzilla – Bug 828265
Autofs needs port 111 open even for NFS4 mounts.
Last modified: 2012-08-14 06:21:11 EDT
Description of problem:
Since autofs-5.0.6-13.fc17, changelog entry "catch EHOSTUNREACH and bail out early", autofs sends a UDP port 111 probe to the nfs-server.
If there's no response, it simply fails.
However, if the server is NFS4-only, autofs worked properly with port
111/UDP firewalled. Which means that the HOSTUNREACH test is unneeded
(for NFS4). A manual nfs4 mount works perfectly with port 111 closed.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Try automounting a NFS4 exported FS, whereby the server has port 111 firewalled.
Automount fails, manualmount succeeds.
Automount and manualmount succeed.
NFS4 needs only a tcp-connection to TCP/2049 by default. That should
be enough for automount too...
Recent changes to mount.nfs(8) resulted in significant timeouts
when attempting to mount against a host which isn't responding.
That isn't going to change and it's what prompted the recent
change. Now autofs needs to probe host availability for simple
mounts as well as multi-mounts to provide reasonable interactive
There's no way for autofs to know if the server provides nfs4
mounts only so the fstype=nfs4 option is needed to tell it that.
That should stop the attempts to contact port 111.
That might not be working quite right now but you haven't
provided sufficient information for me to work that out.
Also, if you don't have a problems with servers not responding
then autofs should use the previous behaviour if MOUNT_WAIT
is set to a value other than the default of -1.
Setting MOUNT_WAIT to a value that is sensible for your site
should be enough to resolve your problem as well.
I understand the reasons for it; makes sense. But still, as you say
if the mount is clearly nfs4, it's pointless to check for the
portmapper. And that is what autofs does.
I have e.g. in my automount maps for /esat/vaishali
More clearly I cannot state it... So something is broken somewhere.
As for the workaround with MOUNT_WAIT, that indeed works. So I'll do
(In reply to comment #2)
> Hi Ian,
> I understand the reasons for it; makes sense. But still, as you say
> if the mount is clearly nfs4, it's pointless to check for the
> portmapper. And that is what autofs does.
> I have e.g. in my automount maps for /esat/vaishali
> -fstype=nfs4,nodev,nosuid vaishali:/
> More clearly I cannot state it... So something is broken somewhere.
Yes, that's not right.
It didn't look like that would happen so I'll have to look at it
> As for the workaround with MOUNT_WAIT, that indeed works. So I'll do
Good to hear.
All that does is provide a way to restore the original behaviour
and at the same time prevent lengthy timeout waits, or at least
use waits that are acceptable to the site.
Can you post a debug log of this happening please.
Make sure that syslog is recording debug log output from
automount. Easiest way to do that is add daemon.* to the
syslog configuration. And then set LOGGING="debug" in the
Check that this issue is fixed by autofs-5.0.6-22.
Re-open the bug if find that it isn't.
*** This bug has been marked as a duplicate of bug 845313 ***
The fix in autofs-5.0.6-22 works for me, I no longer need port 111 open on the server when I specify -fstype=nfs4 on the client. Thanks!