autofs "lookup_mount: exports lookup" fails on IPv6-only hosts
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | Debian |
New
|
Unknown
|
||
| | Fedora |
Fix Released
|
Medium
|
||
| | autofs (Ubuntu) |
Medium
|
Unassigned | ||
Bug Description
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.
|
|
#11 |
Right, I must have a mistake in what I'm using for the host
name, I'll investigate.
|
|
#12 |
Created attachment 503836
Patch - fix ipv6 name for lookup
First pass patch to fix blunder in autofs IPv6 name lookup.
|
|
#13 |
Created attachment 503837
Patch - fix libtirpc ipv6 check
First pass patch to correct the configure libtirpc IPv6
detection test code.
|
|
#14 |
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.
|
|
#15 |
Oh .. and I logged bug 711956 because using libtirpc I found
the IPv6 functions autofs uses weren't actually included in
the library.
|
|
#16 |
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://
|
|
#17 |
This is fixed in F17.
This still issue in F16.
|
|
#18 |
Created attachment 603173
Patch - fix ipv6 name lookup check
|
|
#19 |
Created attachment 603174
Patch - fix ipv6 rpc calls
|
|
#20 |
Created attachment 603175
Patch - fix ipv6 configure check
|
|
#21 |
Created attachment 603177
Patch - fix nfs4 contacts portmap
|
|
#22 |
Created attachment 603178
Patch - fix ipv6 proximity calculation
|
|
#23 |
(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.
|
|
#24 |
autofs-5.0.6-6.fc16 has been submitted as an update for Fedora 16.
https:/
|
|
#25 |
Package autofs-
* 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=
as soon as you are able to.
Please go to the following url:
https:/
then log in and leave karma (feedback).
|
|
#26 |
It segfaults on F16. The nfs.englab.
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=
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\
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=0x7fc5bc7
host=
host_
prx = <optimized out>
#3 0x00007fc5b9eb24d6 in add_host_addrs (list=0x7fc5bc7
host=
at replicated.c:1121
hints = {ai_flags = 32, ai_family = 0, ai_socktype = 2,
ai_next = 0x0}
ni = 0x7fc5ac000c30
this = 0x7fc5ac000c30
n_ptr = 0x7fc5ac000a40 "nfs.englab.
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>
#4 0x00007fc5b9eb2d3e in parse_location (logopt=<optimized out>,
hosts=
path = 0x7fc5ac000b3a "/exports/scratch"
next = 0x7fc5ac000b4a ""
weight = <optimized out>
str = 0x7fc5ac000b20 "nfs.englab.
p = <optimized out>
delim = 0x7fc5ac000b39 ""
empty = <optimized out>
#5 0x00007fc5b9eb072c in mount_mount (ap=0x7fc5bd27bff0,
root=
name_len=7,
what=
fstype=
at mount_nfs.c:148
fullpath = '\000' <repeats 2192 times>"\340, Dq\274\
|
|
#27 |
(In reply to comment #16)
> It segfaults on F16. The nfs.englab.
> 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.
|
|
#28 |
autofs-5.0.6-7.fc16 has been submitted as an update for Fedora 16.
https:/
|
|
#29 |
Package autofs-
* 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=
as soon as you are able to.
Please go to the following url:
https:/
then log in and leave karma (feedback).
|
|
#30 |
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) wrote : | #1 |
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=
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=
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.
Feb 26 15:09:15 svartkulp automount[21673]: dev_ioctl_
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_
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_
Feb 26 15:09:15 svartkulp automount[21673]: failed to mount /nfs/adm
My system runs Ubuntu 12.04.4 LTS.
| Thomas Dreibholz (dreibh) wrote : | #2 |
Note that I turned on debug output in /etc/default/
LOGGING="debug"
My NFS server has IPv4 as well as IPv6. Both addresses are in DNS (as A and AAAA record, respectively).
| Changed in debian: | |
| status: | Unknown → New |
| chemicalfan (mike-lumsden) wrote : | #3 |
Is this bug also present in Debian, or does it only affect the Ubuntu package?
| Serge Hallyn (serge-hallyn) wrote : | #4 |
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.
| Changed in autofs (Ubuntu): | |
| importance: | Undecided → Medium |
| Changed in autofs5 (Ubuntu): | |
| importance: | Undecided → Medium |
| Changed in autofs5 (Ubuntu): | |
| status: | New → Confirmed |
| Changed in autofs (Ubuntu): | |
| status: | New → Confirmed |
| Jimmy Hedman (jimmy-hedman) wrote : | #5 |
Seems that enabling libtirpc solves this.
I've attached simple patch.
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.]
| tags: | added: patch |
| Simon Iremonger (ubuntu-iremonger) wrote : | #7 |
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) wrote : | #8 |
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.
parse_mount: parse(sun): expanded entry: atlantis.
parse_mount: parse(sun): gathered options:
parse_mount: parse(sun): dequote(
parse_mount: parse(sun): core of entry: options=, loc=atlantis.
sun_mount: parse(sun): mounting root /net, mountpoint data6, what atlantis.
mount_mount: mount(nfs): root=/net name=data6 what=atlantis.
mount(nfs): no hosts available
dev_ioctl_
failed to mount /net/data6
| tags: | added: bot-stop-nagging |
| Kevin Otte (nivex) wrote : | #9 |
In addition to the already linked bug, Debian bug 737679 also appears to be closely related: https:/
| Changed in fedora: | |
| importance: | Unknown → Medium |
| status: | Unknown → Fix Released |
| Kevin Otte (nivex) wrote : | #31 |
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) wrote : | #32 |
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) wrote : | #33 |
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:/
Associated git branch: https:/
| Kevin Otte (nivex) wrote : | #34 |
I have tested the package provided by ahasenack in ppa:autofs-
A 'cd' into the autofs managed directory worked perfectly right off the bat.
| no longer affects: | autofs5 (Ubuntu) |
| Changed in autofs (Ubuntu): | |
| status: | Confirmed → In Progress |
| assignee: | nobody → Andreas Hasenack (ahasenack) |
| Launchpad Janitor (janitor) wrote : | #35 |
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
| Changed in autofs (Ubuntu): | |
| status: | In Progress → Fix Released |
| no longer affects: | linuxmint |
| Jonathan (jjcf89) wrote : | #36 |
This appears to have caused a regression. https:/
| Andreas Hasenack (ahasenack) wrote : | #37 |
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) wrote : | #38 |
Reopening the bug because autofs cannot be linked to our old libtirpc without introducing a crash (see bug #1745817).
| Changed in autofs (Ubuntu): | |
| status: | Fix Released → Confirmed |
| assignee: | Andreas Hasenack (ahasenack) → nobody |
@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) wrote : | #40 |
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) wrote : | #41 |
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) wrote : | #42 |
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) wrote : | #43 |
> Is there any chance the new libtirpc will get backported into 18.04.1?
Unlikely. See https:/
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.
scratchv6 -fstype=nfs4 [2001:470:
$ 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:
$ 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-
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/
Jun 8 12:40:32 corsair automount[2318]: handle_packet: type = 3
Jun 8 12:40:32 corsair automount[2318]: handle_
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:
Jun 8 12:40:32 corsair automount[2318]: parse_mount: parse(sun): expanded entry: -fstype=nfs4 [2001:470:
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(
Jun 8 12:40:32 corsair automount[2318]: parse_mount: parse(sun): core of entry: options=
Jun 8 12:40:32 corsair automount[2318]: sun_mount: parse(sun): mounting root /data, mountpoint scratchv6, what [2001:470:
Jun 8 12:40:32 corsair automount[2318]: mount_mount: mount(nfs): root=/data name=scratchv6 what=[2001:
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_
Jun...