autofs "lookup_mount: exports lookup" fails on IPv6-only hosts

[Denis Cheong]

Using Linux Mint 14 and both autofs 5.0.6 and 5.0.7, when attempting to access an NFS server mounted under /net with an auto.master configuration such as:
/net -hosts

If the host is only accessible over IPv6 (i.e. it only has an AAAA record in DNS, or there is no accessible A address), attempting to 'cd' to its host name (e.g. "cd /net/server") will timeout after a few seconds (bash: cd: server: No such file or directory) and result in a syslog entry similar to:
Jan 19 22:39:43 client automount[5582]: lookup_mount: exports lookup failed for server

Immediately upon adding an accessible A (IPv4) address for the server, everything will work correctly (and NFS mounts created by autofs will continue to use the IPv6 address by default).

It appears that the rpc_get_exports() function in autofs is not correctly defaulting to IPv6 when it is available, even though NFS will default to IPv6, and is failing when the server is not accessible over IPv4.

[Jeff (jeff-redhat-bugs)]

Description of problem:
As part of the World IPv6 Test Day, I tried setting up automount to use an IPv6 address, but it's not working:

$ grep scratchv[46] /etc/auto.data
scratchv4 -fstype=nfs4 192.168.1.77:/scratch/
scratchv6 -fstype=nfs4 [2001:470:1f0f:46d:f2de:f1ff:fe15:6496]:/scratch/

$ ls /data/scratchv6
ls: cannot access /data/scratchv6: No such file or directory

$ ls /data/scratchv4
foo

Manually mounting the filesystem works fine, though:

$ sudo mount -t nfs4 [2001:470:1f0f:46d:f2de:f1ff:fe15:6496]:/scratch/ /mnt/tmp

$ ls /mnt/tmp
foo

The changelog indicates that autofs should support IPv6:

$ rpm -q --changelog autofs | grep -i ipv6
- dont fail on ipv6 address when adding host.
- update to provide ipv6 name and address support.
- update to provide ipv6 address parsing.

Version-Release number of selected component (if applicable):
autofs-5.0.5-35.fc15.i686

How reproducible:
every time

Steps to Reproduce:
1. set up NFSv4 server with IPv6
2. set up autofs client with a map entry pointing to the IPv6 NFSv4 server
3. try to automount a directory

Actual results:
ls: cannot access /data/scratchv6: No such file or directory

Expected results:
access the directory

Additional info:
I enabled debug logging in /etc/sysconfig/autofs and this is what I saw during the attempt to mount /data/scratchv6

Jun 8 12:40:32 corsair automount[2318]: handle_packet: type = 3
Jun 8 12:40:32 corsair automount[2318]: handle_packet_missing_indirect: token 15, name scratchv6, request pid 3263
Jun 8 12:40:32 corsair automount[2318]: attempting to mount entry /data/scratchv6
Jun 8 12:40:32 corsair automount[2318]: lookup_mount: lookup(file): looking up scratchv6
Jun 8 12:40:32 corsair automount[2318]: lookup_mount: lookup(file): scratchv6 -> -fstype=nfs4 [2001:470:1f0f:46d:f2de:f1ff:fe15:6496]:/scratch/
Jun 8 12:40:32 corsair automount[2318]: parse_mount: parse(sun): expanded entry: -fstype=nfs4 [2001:470:1f0f:46d:f2de:f1ff:fe15:6496]:/scratch/
Jun 8 12:40:32 corsair automount[2318]: parse_mount: parse(sun): gathered options: fstype=nfs4
Jun 8 12:40:32 corsair automount[2318]: parse_mount: parse(sun): dequote("[2001:470:1f0f:46d:f2de:f1ff:fe15:6496]:/scratch/") -> [2001:470:1f0f:46d:f2de:f1ff:fe15:6496]:/scratch/
Jun 8 12:40:32 corsair automount[2318]: parse_mount: parse(sun): core of entry: options=fstype=nfs4, loc=[2001:470:1f0f:46d:f2de:f1ff:fe15:6496]:/scratch/
Jun 8 12:40:32 corsair automount[2318]: sun_mount: parse(sun): mounting root /data, mountpoint scratchv6, what [2001:470:1f0f:46d:f2de:f1ff:fe15:6496]:/scratch/, fstype nfs4, options
Jun 8 12:40:32 corsair automount[2318]: mount_mount: mount(nfs): root=/data name=scratchv6 what=[2001:470:1f0f:46d:f2de:f1ff:fe15:6496]:/scratch/, fstype=nfs4, options=
Jun 8 12:40:32 corsair automount[2318]: mount_mount: mount(nfs): nfs options="", nosymlink=0, ro=0
Jun 8 12:40:37 corsair automount[2318]: add_host_addrs: hostname lookup failed: Name or service not known
Jun 8 12:40:37 corsair automount[2318]: mount(nfs): no hosts available
Jun 8 12:40:37 corsair automount[2318]: st_readmap: state 1 path /data
Jun 8 12:40:37 corsair automount[2318]: dev_ioctl_send_fail: token = 15
Jun...

[Ian (ian-redhat-bugs)]

Right, I must have a mistake in what I'm using for the host
name, I'll investigate.

[Ian (ian-redhat-bugs)]

Created attachment 503836
Patch - fix ipv6 name for lookup

First pass patch to fix blunder in autofs IPv6 name lookup.

[Ian (ian-redhat-bugs)]

Created attachment 503837
Patch - fix libtirpc ipv6 check

First pass patch to correct the configure libtirpc IPv6
detection test code.

[Ian (ian-redhat-bugs)]

Once the above problems are fixed we find that the interface
ioctls never return IPv6 information.

What that means for autofs is that we can't detect when an
IPv6 address is a local interface or the address is directly
accessible via a local interface. Consequently bind mounts
can't be used for the localhost6 and all hosts appear to be
at the same proximity so there can't be a preference given
to host directly reachable via a local interface.

[Ian (ian-redhat-bugs)]

Oh .. and I logged bug 711956 because using libtirpc I found
the IPv6 functions autofs uses weren't actually included in
the library.

[Fedora (fedora-redhat-bugs)]

This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached 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" (top right of this page) 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

[Petr (petr-redhat-bugs)]

This is fixed in F17.
This still issue in F16.

[Ian (ian-redhat-bugs)]

Created attachment 603173
Patch - fix ipv6 name lookup check

[Ian (ian-redhat-bugs)]

Created attachment 603174
Patch - fix ipv6 rpc calls

[Ian (ian-redhat-bugs)]

Created attachment 603175
Patch - fix ipv6 configure check

[Ian (ian-redhat-bugs)]

Created attachment 603177
Patch - fix nfs4 contacts portmap

[Ian (ian-redhat-bugs)]

Created attachment 603178
Patch - fix ipv6 proximity calculation

[Ian (ian-redhat-bugs)]

(In reply to comment #5)
> Oh .. and I logged bug 711956 because using libtirpc I found
> the IPv6 functions autofs uses weren't actually included in
> the library.

I'm fairly sure I've applied the patches needed to resolve
this.

I'll request a push to testing.

[Fedora (fedora-redhat-bugs)]

autofs-5.0.6-6.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/autofs-5.0.6-6.fc16

[Fedora (fedora-redhat-bugs)]

Package autofs-5.0.6-6.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing autofs-5.0.6-6.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-11598/autofs-5.0.6-6.fc16
then log in and leave karma (feedback).

[Petr (petr-redhat-bugs)]

It segfaults on F16. The nfs.englab.brq.redhat.com has one IPv4 and one IPv6 address:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fc5bc718700 (LWP 13939)]
0x00007fc5bb276d29 in __memcmp_sse4_1 () from /lib64/libc.so.6
(gdb) bt full
#0 0x00007fc5bb276d29 in __memcmp_sse4_1 () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007fc5b9eb1fde in get_proximity (host_addr=<optimized out>)
    at replicated.c:177
        msk6_addr = <optimized out>
        addr_len = 16
        ifa = 0x7fc5ac003500
        addr = <optimized out>
        msk_addr = <optimized out>
        if_addr = <optimized out>
        if6_addr = <optimized out>
        mask6 = 0x0
        addr6 = <optimized out>
        hst_addr = 0x0
        hst6_addr = 0x7fc5ac000c68
        ha = 0
        buf = "\000\000\377\377\n\"\030\232", '\000' <repeats 40 times>, "P1q\274\305\177\000\000\002\000\000\000\000\000\000\000\060\f\000\254\305\177\000\000 \000\000\254\305\177\000\000`\v\000\254\305\177\000\000\000\000\000\000\000\000\000\000\005\000\000\000\000\000\000\000\310\065q\274\305\177\000\000\002\000\000\000\305\177\000\000\265\034\032\273\305\177\000"
        mask = <optimized out>
        ia6 = 0x0
---Type <return> to continue, or q <return> to quit---
        ret = <optimized out>
        this = 0x7fc5ac003728
        ha6 = 0x7fc5ac000c68
        ia = <optimized out>
#2 add_new_host (list=0x7fc5bc7135c8,
    host=0x7fc5ac000b20 "nfs.englab.brq.redhat.com", weight=0,
    host_addr=0x7fc5ac000c30, rr=0, options=0) at replicated.c:1003
        prx = <optimized out>
#3 0x00007fc5b9eb24d6 in add_host_addrs (list=0x7fc5bc7135c8,
    host=0x7fc5ac000b20 "nfs.englab.brq.redhat.com", weight=0, options=0)
    at replicated.c:1121
        hints = {ai_flags = 32, ai_family = 0, ai_socktype = 2,
          ai_protocol = 0, ai_addrlen = 0, ai_addr = 0x0, ai_canonname = 0x0,
          ai_next = 0x0}
        ni = 0x7fc5ac000c30
        this = 0x7fc5ac000c30
        n_ptr = 0x7fc5ac000a40 "nfs.englab.brq.redhat.com"
        name = 0x7fc500000000 <Address 0x7fc500000000 out of bounds>
        len = <optimized out>
        buf = "\000\000:", '\000' <repeats 124 times>
        rr = <optimized out>
        rr4 = <optimized out>
        rr6 = <optimized out>
        ret = <optimized out>
        __FUNCTION__ = "add_host_addrs"
#4 0x00007fc5b9eb2d3e in parse_location (logopt=<optimized out>,
    hosts=0x7fc5bc7135c8, list=<optimized out>, options=0) at replicated.c:1271
        path = 0x7fc5ac000b3a "/exports/scratch"
        next = 0x7fc5ac000b4a ""
        weight = <optimized out>
        str = 0x7fc5ac000b20 "nfs.englab.brq.redhat.com"
        p = <optimized out>
        delim = 0x7fc5ac000b39 ""
        empty = <optimized out>
#5 0x00007fc5b9eb072c in mount_mount (ap=0x7fc5bd27bff0,
    root=0x7fc5bd27c0d0 "/mnt/redhat", name=0x7fc5bc7146f0 "scratch",
    name_len=7,
    what=0x7fc5bc7146b0 "nfs.englab.brq.redhat.com:/exports/scratch",
    fstype=<optimized out>, options=0x7fc5bc714710 "rw,soft,intr", context=0x0)
    at mount_nfs.c:148
        fullpath = '\000' <repeats 2192 times>"\340, Dq\274\305\177\000\000\320Dq\274\305\177\000\000\bFq\274\305\177...

[Ian (ian-redhat-bugs)]

(In reply to comment #16)
> It segfaults on F16. The nfs.englab.brq.redhat.com has one IPv4 and one IPv6
> address:

There is a mistake in the conversion to use getifaddrs(3).
It is a new patch so I'm not surprized there's a mistake in
it, sorry about that.

I incorrectly dropped a check in cases thinking it wasn't
needed. Too much focus on what I wanted to do rather than
what I was doing.

Let me fix it we'll have another go at it.

[Fedora (fedora-redhat-bugs)]

autofs-5.0.6-7.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/autofs-5.0.6-7.fc16

[Fedora (fedora-redhat-bugs)]

Package autofs-5.0.6-7.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing autofs-5.0.6-7.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-11719/autofs-5.0.6-7.fc16
then log in and leave karma (feedback).

[Fedora (fedora-redhat-bugs)]

autofs-5.0.6-7.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.

[Thomas Dreibholz (dreibh)]

autofs fails to mount an IPv6 server. It seems to be that, regardless of proto=tcp6, the DNS lookup uses IPv4:

Feb 26 15:09:15 svartkulp automount[21673]: mount_mount: mount(nfs): nfs options="nfsvers=4,proto=tcp6,rsize=32768,wsize=32768,soft,async,intr,noatime,nodiratime,rw", nobind=0, nosymlink=0, ro=0
Feb 26 15:09:15 svartkulp automount[21673]: mount_mount: mount(nfs): calling mkdir_path /nfs/adm
Feb 26 15:09:15 svartkulp automount[21673]: mount_mount: mount(nfs): calling mount -t nfs -s -o nfsvers=4,proto=tcp6,rsize=32768,wsize=32768,soft,async,intr,noatime,nodiratime,rw 10.1.1.4:/filesrv/adm /nfs/adm
Feb 26 15:09:15 svartkulp automount[21673]: >> mount.nfs: Failed to resolve server 10.1.1.4: Address family for hostname not supported
Feb 26 15:09:15 svartkulp automount[21673]: mount(nfs): nfs: mount failure nfs.simula.nornet:/filesrv/adm on /nfs/adm
Feb 26 15:09:15 svartkulp automount[21673]: dev_ioctl_send_fail: token = 103
Feb 26 15:09:15 svartkulp automount[21673]: failed to mount /nfs/adm
Feb 26 15:09:15 svartkulp automount[21673]: handle_packet: type = 3
Feb 26 15:09:15 svartkulp automount[21673]: handle_packet_missing_indirect: token 104, name adm, request pid 21681
Feb 26 15:09:15 svartkulp automount[21673]: attempting to mount entry /nfs/adm
Feb 26 15:09:15 svartkulp automount[21673]: lookup_mount: lookup(file): looking up adm
Feb 26 15:09:15 svartkulp automount[21673]: dev_ioctl_send_fail: token = 104
Feb 26 15:09:15 svartkulp automount[21673]: failed to mount /nfs/adm

My system runs Ubuntu 12.04.4 LTS.

[Thomas Dreibholz (dreibh)]

Note that I turned on debug output in /etc/default/autofs:
LOGGING="debug"

My NFS server has IPv4 as well as IPv6. Both addresses are in DNS (as A and AAAA record, respectively).

[chemicalfan (mike-lumsden)]

Is this bug also present in Debian, or does it only affect the Ubuntu package?

[Serge Hallyn (serge-hallyn)]

I'm a bit confused - the linked redhat bug is listed as fixed with an older version of autofs; the debian bug claims that using an FQDN for an ipv6 host works, only ipv6 addresses fail, which seems different from this bug description.

[Jimmy Hedman (jimmy-hedman)]

Seems that enabling libtirpc solves this.
I've attached simple patch.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "auto.diff" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Simon Iremonger (ubuntu-iremonger)]

There have been various upstream ipv6 related fixes in the debian/ubuntu changelogs,, imported from upstream and otherwise.
Is this bug still present in debian stretch and ubuntu xenial with newer autofs packages ? I'd suggest testing ubuntu-xenial in particular as the next LTS release (underpinning mint 18 LTS) to come out?

[Kevin Otte (nivex)]

Can confirm this still affects 16.04 LTS (autofs 5.1.1-1ubuntu3)

attempting to mount entry /net/data6
lookup_mount: lookup(file): looking up data6
lookup_mount: lookup(file): data6 -> atlantis.home.nivex.net:/data
parse_mount: parse(sun): expanded entry: atlantis.home.nivex.net:/data
parse_mount: parse(sun): gathered options:
parse_mount: parse(sun): dequote("atlantis.home.nivex.net:/data") -> atlantis.home.nivex.net:/data
parse_mount: parse(sun): core of entry: options=, loc=atlantis.home.nivex.net:/data
sun_mount: parse(sun): mounting root /net, mountpoint data6, what atlantis.home.nivex.net:/data, fstype nfs, options (null)
mount_mount: mount(nfs): root=/net name=data6 what=atlantis.home.nivex.net:/data, fstype=nfs, options=(null)
mount(nfs): no hosts available
dev_ioctl_send_fail: token = 15
failed to mount /net/data6

[Kevin Otte (nivex)]

In addition to the already linked bug, Debian bug 737679 also appears to be closely related: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737679

[Kevin Otte (nivex)]

There is a patch filed against Debian 737679 that fixes the problem. If it doesn't make it through Debian in time, can Ubuntu pick up this patch for the next LTS? It would be a shame for another two years to go by and not have proper IPv6 support.

[Andreas Hasenack (ahasenack)]

It looks like upstream has settled on using libtirpc if ipv6 is needed. From the autofs(5) manpage:
" To be able to use IPv6 within autofs maps the package must be build to use the libtirpc library for its RPC communications. This is becuase the glibc RPC implementation doesn't
       support IPv6 and is depricated so this is not likely to change.
"

[Andreas Hasenack (ahasenack)]

This PPA has test packages built with libtirpc if someone has an ipv6-only setup and is willing to give them a quick test:

https://launchpad.net/~ahasenack/+archive/ubuntu/autofs-ipv6-1101779/

Associated git branch: https://code.launchpad.net/~ahasenack/ubuntu/+source/autofs/+git/autofs/+ref/bionic-ipv6-via-libtirpc-1101779

[Kevin Otte (nivex)]

I have tested the package provided by ahasenack in ppa:autofs-ipv6-1101779
A 'cd' into the autofs managed directory worked perfectly right off the bat.

[Launchpad Janitor (janitor)]

This bug was fixed in the package autofs - 5.1.2-1ubuntu2

---------------
autofs (5.1.2-1ubuntu2) bionic; urgency=medium

  * Fix IPv6 support by linking with libtirpc (LP: #1101779, Closes: #737679):
    - d/control: add libtirpc-dev to build-depends
    - d/rules: add --with-libtirpc to configure call
    Thanks to Stefan Potyra <email address hidden>.

 -- Andreas Hasenack <email address hidden> Wed, 24 Jan 2018 14:01:38 -0200

[Jonathan (jjcf89)]

This appears to have caused a regression. https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1745817

[Andreas Hasenack (ahasenack)]

It did, and I'm afraid I will have to revert this change. I couldn't get autofs to work with the -hosts builtin map with libtirpc 0.2.x. It worked with 1.0.3, which shows how ancient the package is in ubuntu (and debian). Unfortunately now is too late to upgrade that lib to 1.0.3, as that's even a soname bump.

I looked over the changes, tried a few patches, but still couldn't get autofs to work with 0.2.5 in the scenario of bug #1745817.

I rather have this bug reopened than ship 18.04 with a crashing autofs.

[Andreas Hasenack (ahasenack)]

Reopening the bug because autofs cannot be linked to our old libtirpc without introducing a crash (see bug #1745817).

[Simon Iremonger (ubuntu-iremonger)]

@ahasenack
Andreas, your linked-bug has supposedly been fixed, can you check this autofs bug has therefore also been fixed and comment-further or close again...? Be good to get this sorted-out before 18.04.1, with thanks!.

[Jonathan (jjcf89)]

Simon, I think you misunderstood. He had to revert this patch since it caused a regression. So this bug isn't fixed yet. Ubuntu's libtirpc needs to be updated before autofs can switch over to using it, is my understanding.

[Andreas Hasenack (ahasenack)]

Correct. We need to bring in the newer libtirpc, then we can link autofs with it and fix this bug here about ipv6 support.

As of now, ubuntu cosmic has libtirpc-0.2.5-1.2 (old), and debian has 1.0.2-0.2 in experimental. That's a bit better than how it was a while ago, when debian had a new source package for the newer libtirpc called libtirpc3. I think that was because of the transition.

[Kevin Otte (nivex)]

Is there any chance the new libtirpc will get backported into 18.04.1? Not having IPv6-enabled autofs is going to wreck a lot of my workflow once I start upgrading machines in August. I'm currently running a custom build of autofs with libtirpc in 16.04 to enable this functionality.

[Robie Basak (racb)]

> Is there any chance the new libtirpc will get backported into 18.04.1?

Unlikely. See https://wiki.ubuntu.com/StableReleaseUpdates.

[Andreas Hasenack (ahasenack)]

This was fixed in https://launchpad.net/ubuntu/+source/autofs/5.1.5-1ubuntu1, which is linked with a newer libtirpc.