Update To EL 6.3 Breaks TCP NFS Automounts

Home » CentOS » Update To EL 6.3 Breaks TCP NFS Automounts
CentOS 4 Comments

See Red Hat Bugzilla bug #846852 for details. https://bugzilla.redhat.com/show_bug.cgi?id


We discovered that after updating to EL 6.3 on our x86_64 server, autofs 5.0.5-54 broke our nightly backups that rely on automounting an NFS share hosted on another EL 6 machine on our local network. The machine hosting NFS server was configured to allow only TCP connections to the port specified by MOUNTD_PORT in “/etc/sysconfig/nfs”

Any attempts to access this share caused segmentation faults in the automount daemon.

EL 6.2 hosts that had not yet been updated had no problems accessing the same NFS shares.

While testing we found that opening the UDP MOUNTD_PORT on the NFS server firewall allowed successful access to the NFS shares from the EL 6.3 NFS client without segfault. Closing the port caused the EL 6.3 NFS client to return to the faulty behavior.

On another fully updated EL 6.3 i386 host, we were able to duplicate the same symptoms.

On one of the EL 6.2 hosts not yet updated we confirmed no issues with the previous autofs package, then upgraded only autofs. After the upgrade we confirmed symptoms identical to the fully updated 6.3 machines.

While filing the bug report I found 2 other, possibly related, bugs written against autofs 5.0.5-54 that did not describe our symptoms but may be relevant to other users on this list.

Bug 840025 – autofs 5.0.5-54 fails to mount share on IPv6 netapp https://bugzilla.redhat.com/show_bug.cgi?id=840025

Bug 834641 – autofs requires portmapper on server for NFSv4 mounts https://bugzilla.redhat.com/show_bug.cgi?id=834641


For now, we are leaving the UDP NFS port open on the firewall of the NFS server. Our networks are completely isolated from the outside world so this doesn’t pose a significant risk. However, this may not be acceptable for everyone’s environment.

4 thoughts on - Update To EL 6.3 Breaks TCP NFS Automounts

  • I was reading your posts with Joerg Schillings comments on Linux NFS (in the zfs/xfs/jfs thread) still in the back of my head, for some reason ;)

    The changelog entries in upstream’s autofs rpm go back thirteen years. One would expect some measure of maturity and stability here, yet autofs is a frequent source of problems. I remember another major problem we ran into somewhere around CentOS 5.2 or 5.3.

  • I do see maturity and a great many improvement but I must agree that comparing the change log to bug reports seems to indicate a level of instability. There do seem to be a great many bugs that dump core but this may be the nature of the beast when interacting with the Linux kernel, a constantly moving target. I’m not one to criticize but if software in our organization repeatedly produced segfaults, I’d suggest that developers look closely at improving error traps and handling and/or analyze faults to see if patterns or trends emerge. Still, there are enough alternatives and security features in EL to mitigate most problems.

  • I forgot to mention that I did find what appeared to be an identical bug reported apparently as a private upstream support case #155523. I found it in a Google search but the link
    (https://access.redhat.com/knowledge/solutions/155523) raised a permission error, even though I was logged into the site. The text-only cached page from July 24 read like this:

    Autofs process segfault on startup after upgrading to RHEL6.3 release.
    last modified by Shijoe Panjikkaran on 07/10/12 – 03:26 Issue

    Autofs is getting segfaults after upgrading the autofs package to
    the 6.3 release

    Automount segfaults with the following message in logs, automount[5195]: segfault at 28 ip 00007f0dfe22b862 sp 00007f0e01a7b960 error 4 in lookup_hosts.so[7f0dfe222000+1c000]


    Red Hat Enterprise Linux(RHEL) 6.3 autofs-5.0.5-54.el6.x86_64

    This leads me to believe that upstream is aware of this issue and
    someone there is working on a fix.