RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 846320 - Autofs needs port 111 open even for NFS4 mounts. (regression since 6.2)
Summary: Autofs needs port 111 open even for NFS4 mounts. (regression since 6.2)
Keywords:
Status: CLOSED DUPLICATE of bug 834641
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: autofs
Version: 6.3
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Ian Kent
QA Contact: yanfu,wang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-08-07 13:12 UTC by Rik Theys
Modified: 2023-01-13 08:56 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 828265
Environment:
Last Closed: 2012-09-06 01:42:12 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

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 ***
Note You need to log in before you can comment on or make changes to this bug.