mount.nfs does not downgrade NFS version when connecting to dual-stack NFS server
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
nfs-utils (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Precise |
Fix Released
|
Medium
|
Dave Chiluk |
Bug Description
[Impact]
When all the following exist
- mounting a server using hostname.
- the hostname resolves to both an ipv4 and ipv6 address
- the nfs server only supports nfsv3
Then.
* The nfs client will not fall back to nfsv3, and will be unable to mount
the share.
* The following errors are printed in the logs.
"
mount: no type was given - I'll assume nfs because of the colon
mount.nfs: timeout set for Tue Nov 11 14:25:34 2014
mount.nfs: trying text-based options 'vers=4,
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'vers=4,
mount.nfs: mount(2): No route to host
mount.nfs: trying text-based options 'vers=4,
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'vers=4,
mount.nfs: mount(2): No route to host
"
[Test Case]
* Restrict to nfsv3 on Server by setting RPCNFSDOPTS=
* Enable dns resolution for both ipv4 and ipv6 of the server.
* Export a directory from the server (export -a)
* Attempt to mount the nfs share from client
[Regression Potential]
* Upstream backport that still exists upstream.
[Other Info]
* Fix already exists in 2.6+ which means >trusty already have the fix.
_______
If you attempt to mount a share from a server that is dual stack (i.e. has both an A and a AAAA record in DNS) and NFSv3-only, mount.nfs goes into an infinite loop of retrying an NFS-v4 mount:
mount nfs-v3-server:/path /mnt -v
mount: no type was given - I'll assume nfs because of the colon
mount.nfs: timeout set for Tue Nov 11 14:25:34 2014
mount.nfs: trying text-based options 'vers=4,
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'vers=4,
mount.nfs: mount(2): No route to host
mount.nfs: trying text-based options 'vers=4,
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'vers=4,
mount.nfs: mount(2): No route to host
If we "hide" the AAAA record by setting an override in /etc/hosts, then mount.nfs correctly retries with NFSv3:
mount -t nfs nfs-v3-server:/path /mnt -v
mount.nfs: timeout set for Tue Nov 11 15:01:35 2014
mount.nfs: trying text-based options 'vers=4,
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'addr=x.x.x.x'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying x.x.x.x prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying x.x.x.x prog 100005 vers 3 prot UDP port 635
nfs-v3-server:/path on /mnt type nfs (rw)
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: nfs-common 1:1.2.5-3ubuntu3.1
ProcVersionSign
Uname: Linux 3.2.0-70-generic x86_64
ApportVersion: 2.0.1-0ubuntu17.8
Architecture: amd64
Date: Tue Nov 11 15:56:25 2014
InstallationMedia: Ubuntu-Server 10.04.2 LTS "Lucid Lynx" - Release amd64 (20110211.1)
MarkForUpload: True
ProcEnviron:
SHELL=/usr/bin/ksh
TERM=xterm
PATH=(custom, no user)
LANG=en_US
SourcePackage: nfs-utils
UpgradeStatus: Upgraded to precise on 2013-10-07 (400 days ago)
Related branches
Changed in nfs-utils (Ubuntu): | |
assignee: | nobody → Dave Chiluk (chiluk) |
description: | updated |
Changed in nfs-utils (Ubuntu): | |
status: | In Progress → Fix Released |
Changed in nfs-utils (Ubuntu Precise): | |
assignee: | nobody → Dave Chiluk (chiluk) |
importance: | Undecided → Medium |
status: | New → In Progress |
Changed in nfs-utils (Ubuntu): | |
assignee: | Dave Chiluk (chiluk) → nobody |
description: | updated |
description: | updated |
I have built a test package with this commit for precise git.linux- nfs.org/ ?p=steved/ nfs-utils. git;a=commit; h=9da66f8898a6
http://
I have placed it http:// people. canonical. com/~chiluk/ lp1391662/
Unfortunately my environments do not have ipv6 name resolution adequately functioning to fully test this fix.
@Tyler Sable - Can you test this and let me know if it resolves the issue you are seeing? Otherwise I will work next week to get ipv6 functional in my labs.
Thanks