On Sat, 12 May 2018 at 18:26:11 -0700, Ross Vandegrift wrote:
> After upgrading my laptop from stretch to buster, I'm not able to mount NFS
> via
> mdns. I have the following entry in /etc/fstab:
>
> vanvanmojo.local:/mnt/storage /mnt/storage nfs4
> noauto,nofail,x-systemd.automount,x-systemd.mount-timeout=10,x-systemd.requires=network-online.target,x-systemd.idle-timeout=10m
> 0 0
>
> The mount fails with the following log message:
>
> stgulik kernel: [ 575.329441] NFS: bad IP address specified:
> addr=2606:6000:4502:1d00:4639:c4ff:fe53:e49b%2
>
> It looks like the scope id was added in #644912. This may be a kernel bug if
> the scope id should be accepted.
I think this might be a bug in whatever user-space tool calls
getaddrinfo() and passes its result to the kernel, which probably means
mount.nfs? If the kernel doesn't want to see scope IDs in this context,
then the user-space tool shouldn't provide them: returning scope IDs is
part of the getaddrinfo() API.
Not including the scope ID in the result of address resolution breaks IPv6
link-local addressing (fe80:*), and link-local addressing and mDNS are both
parts of the Zeroconf stack, so they (should) go well together.
Or possibly nss-mdns should be setting the scope ID to the interface
index for link-local addresses, but not for other addresses? It isn't
entirely clear to me what nss-mdns is meant to be doing here.
Workarounds:
* don't use mDNS (.local names) to find NFS servers; or
* configure mdns4[_minimal] instead of mdns[_minimal] so .local names
resolve to IPv4 addresses
NFS has historically been somewhat fragile against network failures,
so I'm not sure that I can recommend mDNS as a way to find NFS shares.
If your network is sufficiently static and hand-configured that you can
safely put NFS shares in /etc/fstab, then it's probably also sufficiently
static that the NFS server has a stable name, or even a stable IP address.
smcv
