Bug 846320

Summary:	Autofs needs port 111 open even for NFS4 mounts. (regression since 6.2)
Product:	Red Hat Enterprise Linux 6	Reporter:	Rik Theys <rik.theys>
Component:	autofs	Assignee:	Ian Kent <ikent>
Status:	CLOSED DUPLICATE	QA Contact:	yanfu,wang <yanwang>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	6.3	CC:	AmandaOralie812, berrange, Bert.Deknuydt, dgilbert, fradisel, ikent, ljglmail, Per.t.Sjoholm, rik.theys, uckelman, yanwang
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	828265	Environment:
Last Closed:	2012-09-06 01:42:12 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Rik Theys 2012-08-07 13:12:00 UTC

+++ This bug was initially created as a clone of Bug #828265 +++

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):

Since 5.0.6-13.fc17.

How reproducible:

Always.

Steps to Reproduce:
1. Try automounting a NFS4 exported FS, whereby the server has port 111 firewalled.
2. 
3. 
  
Actual results:

Automount fails, manualmount succeeds.

Expected results:

Automount and manualmount succeed.

Additional info:

NFS4 needs only a tcp-connection to TCP/2049 by default.  That should
be enough for automount too...

--- Additional comment from ikent on 2012-06-06 07:36:06 CEST ---

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
response.

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.

--- Additional comment from Bert.Deknuydt.be on 2012-06-06 09:46:57 CEST ---

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.

As for the workaround with MOUNT_WAIT, that indeed works.  So I'll do
that.

Thanks!

--- Additional comment from ikent on 2012-06-06 10:32:23 CEST ---

(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
again.

> 
> As for the workaround with MOUNT_WAIT, that indeed works.  So I'll do
> that.

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.

> 
> Thanks!

My pleasure.
Ian

--- Additional comment from ikent on 2012-06-11 04:33:36 CEST ---

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
autofs configuration.

Comment 2 Rik Theys 2012-08-07 13:13:33 UTC

If the mount options specify nfs4 as the mount type, it should do an NFSv4 no-op instead of trying to contact the portmapper service. NFSv4 doesn't need the portmapper/rpcbind service open in the firewall.

Comment 3 Rik Theys 2012-08-07 13:45:44 UTC

Here's the autofs debug output from a failed mount. It seems to indicate no hosts are available, although the host is definitely up but has tcp/rpcbind firewalled.

Aug  7 14:33:17 vierre64 automount[22292]: handle_packet: type = 3
Aug  7 14:33:17 vierre64 automount[22292]: handle_packet_missing_indirect: token 8076, name donovan, request pid 22345
Aug  7 14:33:17 vierre64 automount[22292]: attempting to mount entry /esat/donovan
Aug  7 14:33:17 vierre64 automount[22292]: lookup_mount: lookup(ldap): looking up donovan
Aug  7 14:33:17 vierre64 automount[22292]: do_bind: lookup(ldap): auth_required: 1, sasl_mech (null)
Aug  7 14:33:17 vierre64 automount[22292]: do_bind: lookup(ldap): ldap simple bind returned 0
Aug  7 14:33:17 vierre64 automount[22292]: lookup_one: lookup(ldap): searching for "(&(objectclass=nisObject)(|(cn=donovan)(cn=/)(cn=\2A)))" under "nisMapName=auto.net,ou=Automount,dc=esat,dc=kuleuven,dc=be"
Aug  7 14:33:17 vierre64 automount[22292]: lookup_one: lookup(ldap): getting first entry for cn="donovan"
Aug  7 14:33:17 vierre64 automount[22292]: lookup_one: lookup(ldap): examining first entry
Aug  7 14:33:17 vierre64 automount[22292]: validate_string_len: lookup(ldap): string donovan encoded as donovan
Aug  7 14:33:17 vierre64 automount[22292]: lookup_mount: lookup(ldap): donovan -> -fstype=nfs4,nodev,nosuid,intr donovan:/
Aug  7 14:33:17 vierre64 automount[22292]: parse_mount: parse(sun): expanded entry: -fstype=nfs4,nodev,nosuid,intr donovan:/
Aug  7 14:33:17 vierre64 automount[22292]: parse_mount: parse(sun): gathered options: nosymlink,fstype=nfs4,nodev,nosuid,intr
Aug  7 14:33:17 vierre64 automount[22292]: parse_mount: parse(sun): dequote("donovan:/") -> donovan:/
Aug  7 14:33:17 vierre64 automount[22292]: parse_mount: parse(sun): core of entry: options=nosymlink,fstype=nfs4,nodev,nosuid,intr, loc=donovan:/
Aug  7 14:33:17 vierre64 automount[22292]: sun_mount: parse(sun): mounting root /esat, mountpoint donovan, what donovan:/, fstype nfs4, options nosymlink,nodev,nosuid,intr
Aug  7 14:33:17 vierre64 automount[22292]: mount_mount: mount(nfs): root=/esat name=donovan what=donovan:/, fstype=nfs4, options=nosymlink,nodev,nosuid,intr
Aug  7 14:33:17 vierre64 automount[22292]: mount_mount: mount(nfs): nfs options="nodev,nosuid,intr", nosymlink=1, ro=0
Aug  7 14:33:17 vierre64 automount[22292]: get_nfs_info: called with host donovan(10.33.133.6) proto tcp version 0x40
Aug  7 14:33:17 vierre64 automount[22292]: get_nfs_info: nfs v4 rpc ping time: 0.000193
Aug  7 14:33:17 vierre64 automount[22292]: get_nfs_info: host donovan cost 193 weight 0
Aug  7 14:33:17 vierre64 automount[22292]: mount(nfs): no hosts available
Aug  7 14:33:17 vierre64 automount[22292]: dev_ioctl_send_fail: token = 8076
Aug  7 14:33:17 vierre64 automount[22292]: failed to mount /esat/donovan
Aug  7 14:33:17 vierre64 automount[22292]: handle_packet: type = 3
Aug  7 14:33:17 vierre64 automount[22292]: handle_packet_missing_indirect: token 8077, name donovan, request pid 22345
Aug  7 14:33:17 vierre64 automount[22292]: attempting to mount entry /esat/donovan
Aug  7 14:33:17 vierre64 automount[22292]: lookup_mount: lookup(ldap): looking up donovan
Aug  7 14:33:17 vierre64 automount[22292]: dev_ioctl_send_fail: token = 8077
Aug  7 14:33:17 vierre64 automount[22292]: failed to mount /esat/donovan

Comment 4 Rik Theys 2012-08-17 13:53:34 UTC

This bug was recently fixed in Fedora 17 with version 5.0.6-22. Please backport the relevant patches to the RHEL 6 autofs package.

Comment 5 Ian Kent 2012-09-06 01:42:12 UTC


*** This bug has been marked as a duplicate of bug 834641 ***