mount picks the wrong version of NFS filesystem

[William Fagan]

I have a server running 10.04 and a desktop running 10.10. The server has a directory I am trying to mount using NFS. When letting it guess the NFS version it chooses incorrectly.

Here is the command I use to mount my desired directory.
> sudo /sbin/mount.nfs 192.168.1.20:/public /mnt/server -o rw

/etc/mtab looks like this and the mount directory doesn't show any files.
192.168.1.20:/public /mnt/server nfs rw,vers=4,addr=192.168.1.20,clientaddr=192.168.1.147 0 0

By forcing version 3 on the command line it works.
> sudo /sbin/mount.nfs 192.168.1.20:/public /mnt/server -o rw,vers=3

/etc/mtab looks like this and the mount directory correctly shows the files.
192.168.1.20:/public /mnt/server nfs rw,vers=3,addr=192.168.1.20 0 0

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: nfs-common 1:1.2.2-1ubuntu1
ProcVersionSignature: Ubuntu 2.6.35-22.35-generic 2.6.35.4
Uname: Linux 2.6.35-22-generic x86_64
Architecture: amd64
Date: Tue Nov 23 15:34:08 2010
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release Candidate amd64 (20100928)
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: nfs-utils

[Steve Langasek (vorlon)]

mount.nfs is intended to be a helper for /sbin/mount, you shouldn't really be invoking it directly. Is this problem reproducible if you call 'mount -tnfs' instead of 'mount.nfs'?

[William Fagan (libwilliam-deactivatedaccount)]

'mount -t nfs' was where I was originally seeing the problem. I switched to
mount.nfs afterwards so there would be one less possibility of a failure
point.

I tried the basic 'mount -t nfs' on a clean 10.04 install and it worked. So
it appears to be something that was introduced between then and now.

On Wed, Nov 24, 2010 at 12:39 AM, Steve Langasek <
<email address hidden>> wrote:

> mount.nfs is intended to be a helper for /sbin/mount, you shouldn't
> really be invoking it directly. Is this problem reproducible if you
> call 'mount -tnfs' instead of 'mount.nfs'?
>
> --
> mount picks the wrong version of NFS filesystem
> https://bugs.launchpad.net/bugs/680680
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Peter Bell (peter-bellfamily)]

I have just discovered that 'mount.nfs' defaults to applying the option 'vers=4'. This was causing me problems with nfs3 mounts via autofs. I presume that this behaviour is a change between 10.04 and 10.10, since I never encountered this difficulty in Lucid.

If this was an intentional change, I wonder what the purpose of the 'mount.nfs4' command is??

In my opinion, this should count as a bug and the behaviour of 'mount.nfs' be returned to that of earlier versions.

In my case, I have worked around the problem by adding 'vers=3' to the end of the '/net' line in /etc/auto.master

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Christian Mudra (brixlwupf)]

I'm running a Debian Server (6.0.3) and two Ubuntu 10.04 LTS clients with am-utils to mount the server shares.
 On the 10.04 LTS, the output of 'mount' and '/proc/mounts' differ about the nfs-version and the used protocol type:

~$ mount | grep nfs | grep home
seth:(pid1718,port1022) on /home type nfs (intr,rw,port=1022,toplvl,nolock,map=amd.home,actimeo=0)
amun:/net/amun/fs1/home on /net/amun/fs1/home type nfs (rw,grpid,hard,intr,nodevs,nosuid,vers=3,proto=tcp)

~$ cat /proc/mounts | grep nfs | grep home
seth:(pid1718,port1022)/ /home nfs rw,relatime,vers=2,rsize=1024,wsize=1024,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,proto=udp,port=65535,timeo=7,retrans=3,sec=sys,local_lock=none,addr=127.0.0.1 0 0
amun:/net/amun/fs1/home/ /net/amun/fs1/home nfs rw,nosuid,relatime,vers=2,rsize=8192,wsize=8192,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,proto=udp,port=65535,timeo=7,retrans=3,sec=sys,local_lock=none,addr=172.20.91.20 0 0

On the 10.04 LTS client, in /etc/am-utils/amd.conf the following nfs options are spezified:

~$ grep nfs /etc/am-utils/amd.conf | grep -v "^\ *#"
  nfs_proto = tcp
  nfs_vers = 3

[Christian Mudra (brixlwupf)]

Following the above hint from Peter Bell, I've now added the proto and vers options to the amd.home-map (beside that, I set the rsize and wsize to 16k). Demanded are the following options:

~$ ypcat -k amd.home | grep 'default '
/defaults type:=nfs;sublink=${key};opts:=rw,grpid,hard,intr,nodevs,nosuid,vers=3,proto=tcp,rsize=16384,wsize=16384;rfs:=${autodir}/${rhost}/fs1/home;fs:=${autodir}/${rhost}/fs1/home

The result is:

~$ cat /proc/mounts | grep nfs | grep home
seth:(pid1512,port1022)/ /home nfs rw,relatime,vers=2,rsize=1024,wsize=1024,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,proto=udp,port=65535,timeo=7,retrans=3,sec=sys,local_lock=none,addr=127.0.0.1 0 0
amun:/net/amun/fs1/home/ /net/amun/fs1/home nfs rw,nosuid,relatime,vers=2,rsize=8192,wsize=8192,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,proto=udp,port=65535,timeo=7,retrans=3,sec=sys,local_lock=none,addr=172.20.91.20 0 0

The amd registers in the mount tab with vers=2,proto=udp,rsize=1024,wsize=1024, while the mount itself is mounted with vers=2,proto=udp, rsize=8192,wsize=8192.
The given workaround does not work for me, and I also don't have a clue why the 16k read/write size is also not used.

[Christian Mudra (brixlwupf)]

I solved the problem by updating to nfs-common-1.2.2-1ubuntu1 and nfs-kernel-server-1.2.2-1ubuntu1 (both taken from maverick), and the related am-utils problem by updating to am-utils-6.2+rc20110530-1ubuntu1, taken from oneiric (luckily all the prerequsites for these packages are fulfilled by lucid/lucid-updates).

Just for the records: A mount in the shell now results in an nfs4-mount, the mount by am-utils uses nfsv3 with a 256k read/write-blocksize if nothing is spezified in the amd maps.
Moving of files larger than 2 GB to the nfs share is now finally possible :-)