/sbin/mount.nfs doesn't understand mount option mountvers=n

[scorp123]

It appears that on Ubuntu 8.04 the binary /sbin/mount.nfs no longer understands certain (standard?) mount options which work on Ubuntu 7.10. This is bad for compatibility!

Instructions to reproduce the behaviour:

1.) both on Ubuntu 8.04 and 7.10:
Configure an NFS server and have it export a directory "/smb" ... e.g. my /etc/exports looks like this:

/smb *(rw,async,no_root_squash,no_subtree_check)

2.) Now try to mount it onto your localhost with this command:
sudo mount -t nfs -o rw,udp,mountvers=2,port=4242 localhost:/smb /smb

Results you will get:

* Ubuntu 7.10:
Everything OK, works tip top. A simple "mount" returns this:

~$ mount
...
localhost:/smb on /smb type nfs (rw,udp,mountvers=2,port=4242,addr=127.0.0.1)

The application (please see below for details) I have to do this for also works tip top with Ubuntu 7.10.

* Ubuntu 8.04:
Does not work! The "mount" binary immediately exists with this error message:

"mount.nfs: an incorrect mount option was specified"

If I modify above command e.g. so that it now looks like this (leaving away the "mountvers=2" parameter) ...:

sudo mount -t nfs -o rw,udp,port=4242 localhost:/smb /smb

... then "mount" seems to hang for quite a while and then after several minutes simply exits with this message:

"mount.nfs: internal error"

... Without giving any further explanation of what might be wrong! "dmesg" shows this line:

"[718405.028275] nfs: server localhost not responding, timed out"

... But according to the "nfs-kernel-server" itself it is running:

# /etc/init.d/nfs-kernel-server status
nfsd running

The same message about "nfs: server localhost not responding, timed out" is also present in /var/log/messages but other than this there are no indications of why this does not work anymore (again: it works tip top in Ubuntu 7.10 and other Linux distributions).

Background:

We are using "Sun Secure Global Desktop" (see here: http://www.sun.com/software/products/sgd/get.jsp) and Ubuntu as application server (e.g. Ubuntu's Gnome desktop session is served as application to our SGD users) and for everything (= audio forwarding, client drive mapping, seamless window mode) to work it is necessary to install the "SGD Client Enhancement Module". Details about that one can be found here: http://docs.sun.com/source/820-2550/cdm.html

This page explains in detail how NFS and exporting the "/smb" share is needed for "Client Drive Mapping" to work:
http://docs.sun.com/source/820-2550/cdm.html#unixappserver

As per these instructions by SUN, when you issue this command:

/opt/tta_tem/bin/tem startcdm

... to trigger the "client drive mapping" functionality then this script "/opt/tta_tem/bin/tem" is executed which ultimately triggers the mount command I give above (I checked via "strace"):

"mount -t nfs -o rw,udp,mountvers=2,port=4242 localhost:/smb /smb"

So this explains why I need above command to work, no matter how strange and pointless it may look.

As explained above, I can use "Sun Secure Global Desktop" with Ubuntu 7.10 and with "client drive mapping" (and therefore via that funny-looking "mount" command above!) users who login get the drives of their client PC (e.g. their C:\ .... or their $HOME directory) mapped onto the remotely running desktop session (e.g. Ubuntu's Gnome session) as if it were connected directly to the server. Trust me, this is a very cool feature.

With Ubuntu 8.04 however this does not work anymore.

So it all boils down to the fact that this command (regardless how odd and pointless it may look):

sudo mount -t nfs -o rw,udp,mountvers=2,port=4242 localhost:/smb /smb

... works tip top on Ubuntu 7.10
... but does not work at all on Ubuntu 8.04

... Which means that we cannot use Ubuntu 8.04 in connection with "Sun Secure Global Desktop" and maybe other enterprise products as well.

So am I right to assume that something was changed in the "mount.nfs" binary and that this might be a bug?

If it's not a bug .... could we please have 7.10's binaries back?
:-)

[scorp123 (scorp123)]

Bump?

[scorp123 (scorp123)]

Two months and still no answer? This is sad. :(

[Brendan McLearie (bren-internode)]

Is there anyway to modify the mount script globally? With my far from complete understanding of the changes to 8.04 nfs, the underlying version is now 4 (supporting all sorts of better security etc). My investigations into mount issues indicated a places to look was the manner of exports, being changed significantly. Older versions are still supported but the native export arrangement is now different - check man pages for -t nfs4.

The other idea, is to specify the bg option although it appears it would have been an easy fix to remove the mountvers if the mount options could be changed in your setup. I have found the bg option still errors but then spawns a retry process in background that eventually sorts it out - I use this where an fstab mount executes before networking starts. May not solve the mountvers issue for you though.

I concur with your backwards compatibility comments. Sorry I couldn't be more helpful.

[scorp123 (scorp123)]

Sun Microsystems recently released a new version of the software: SSGD 4.41-907 ... I have only installed in Solaris 10 so far, I did not yet have the chance to try it out on an Ubuntu 8.04 installation.

But SSGD 4.41-907 too just like the previous version 4.40-917 (the one my bug report is about) officially only support RHEL 5 and SLES 10 ... So I imagine that the underlying mount script will still be the same and that it too will still expect those old mount options to work.

There should be a package, e.g. something like "nfs-compat" or something like that, that would give people like me the old NFS binaries back (make it conflict with the new mainstream NFS binaries if you have to) so closed-source enterprise packages like this stuff from SUN will continue to work.

Stuff like this is exactly the reason why e.g. some of the customer companies I work with they will not accept Linux and especially not Ubuntu, because things work in one release and then all of a sudden stop working in the next release and nobody can really tell you why this was even done.

Messing with those NFS mount options and making it incompatible was really a silly decision, sorry to say so.

[scorp123 (scorp123)]

... bump ...

As far as "reporting bugs" goes this is a pretty sad experience here.

[kris (krism-walla)]

hi scorp123.
I'm running CentOS v5.2 i386 and I had the same problem with Ubuntu 8.04 : to mount (using NFS) to an exported folder on a CentOS server.

My config:
- A CentOS 5.2 machine the will act as a NFS server with IP of 192.168.1.151. I disabled the firewall and SELinux on CentOS server . If you want to play with Firewall and SELinux furthermore, than it's up to yourself. I've disabled them for testing purposes.
- Ubuntu 8.04 machine - NFS client with IP of 192.168.1.138 and a patrick user account

1) First, I've created a folder to be exported on a CentOS server.

mkdir /home/kris/storage

2) Then, I've set everyone to have read-write permissions:

sudo chmod 777 storage

3) Then using GUI version of NFS I've exported:
3.1) /home folder as Read-Only (this had to be done so everyone can see all the exported folders)
3.2) /home/kris/storage as Read-Write for everyone on my network by typing 192.168.1.0/24 as Host(s)

4) On Ubuntu PC I've created an empty folder to use as a mount point
mkdir /home/patrick/share

5) Again on Ubuntu PC I installed NFS:

apt-get install nfs-common

6) Finally I've mounted the exported folder:
mount -t nfs -o soft,intr,tcp,timeo=20 192.168.1.151:/home/kris/storage /home/patrick/share

7) To see if the folder was accessible for Ubuntu client I issued a command:
mount

and it showed me in the last line:
192.168.1.151:/home/kris/storage on /home/patrick/share type nfs (rw,soft,intr,tcp,timeo=20, addr=192.168.1.151)

8) to stop using that exported folder simply run as a root:
umount share

9) I don't have time now to write how to permanently add this mount point during Ubuntu system startup but if you're interested, then let me know. It's all about modyfying /etc/fstab file.

with Regards
kris

[scorp123 (scorp123)]

@kris:

It is obvious that you are a beginner and did not understand what this is about. Sorry to say so. My problem has nothing whatsoever to do with /etc/fstab

Please try and read again what I wrote. Please understand that the mount options that I need are simply not understood anymore by the "nfs-common" package due to some stupid unnecessary changes that were done in Ubuntu 8.04 (everything worked fine with Ubuntu 7.10). And because of that it really doesn't matter where I put those options, e.g. onto the command line or into /etc/fstab

If you want to reproduce my problem please read my original posting again and try the steps I wrote there:

Quote from there:

"So it all boils down to the fact that this command (regardless how odd and pointless it may look):

sudo mount -t nfs -o rw,udp,mountvers=2,port=4242 localhost:/smb /smb

... works tip top on Ubuntu 7.10
... but does not work at all on Ubuntu 8.04"

[Darrel (hankedr)]

I see "incorrect mount option" in ubuntu 8.04 with SGD (Sun Secure Global Desktop). The behavior is different on a Debian mostly-Lenny system, where the mount succeeds (from SGD startcdm) and the expected subdirectories are created on login from SGD, but a directory listing stalls with an eventual "nfs server not responding".

Is there still no solution for Ubuntu 8.04 or Debian Lenny? In limited experiments, I don't see that we can intercept the call. The port option in the call to mount.nfs means that it is ttadm that is targeted (and so some of the comments in this thread puzzle me).

The client drive mechanism works fine on our Solaris systems, but we are forced to use Linux for certain apps, and I'd prefer to use some distribution that is currently running here rather than install the SGD-blessed Linux distributions.

[scorp123 (scorp123)]

@Darrel:

> I see "incorrect mount option" in ubuntu 8.04 with SGD (Sun Secure Global Desktop)
Yes, same here. I haven't tried Ubuntu 8.10 or 9.04 yet but I'd expect the behaviour to be the same.

> some of the comments in this thread puzzle me
yup :-)

> and I'd prefer to use some distribution that is currently running here rather
> than install the SGD-blessed Linux distributions.
Same here. Let's face it: The officially supported distros (SLES 9? SLES 10? Oh please ...) suck badly for the most part (they are mostly outdated and getting extra-packages to work isn't nearly as easy as with "apt" on Ubuntu or Debian!). However, lacking a solution for Ubuntu at the moment I might give CentOS 5.3 a try which should be 100% compatible with the officially supported RHEL 5. So I hope the NFS mount options used by SGD still work there. Of all the available alternatives CentOS 5.3 sucks the least I guess ("yum" is no "apt" but I think I could live with it if the rest works under SGD ...).

Besides, for really large file transfers we use this SGD plugin: "ToolBox Backplane Service" aka "TBS".
http://www.tbsol.de

"TBS" has a "File Transfer" module which more or less works and looks like a web-based SFTP client. So you'd click on the "File Transfer" icon and the right pane of your webtop (which mostly isn't used for anything but for displaying the "Welcome to your webtop" message ...) turns into a SFTP client ... If you can't get CDM to work (thanks to the missing NFS mount options ...) then TBS is a must-have IMHO.

[scorp123 (scorp123)]

Bump??

I reported this a little more than one year ago and this bug is still "New" .... ?

[zappepcs (zappepcs)]

I think this might be an nsf4 bug, or bug in software related to nsf4 settings etc. I say this because I found this thread due to trying to solve the same issues described by scorp123. Seeing his notes made me thing... ahh, lets go back to before 8.04 etc.

So I created an nsf3 export on my CentOS 5.4 using Webmin (sorry no cli info) and then went to the Ubuntu 9.10 desktop system and created an NFS3 mount to that system. Aside from the CentOS system no advertising (webmin could not see that it has nfs exports) I was able to create a quick nfs mount and all is good. While trying the NFS4 mounts I was getting an error on the directory file name being wrong. If anyone is interested, I can go back and detail the errors and such. I just wanted to say I think it's in the nsf4 implementation rather than some Ubuntu irregularity. It could still be an Ubuntu deal I guess, but seems odd to say that to me given that nsf3 mounts work fine. No, I have not looked upstream for any bug tracking/issues on Debian or RH/Fedora. This is internal to my home network for me, so I'll be happy enough with the nsf3 for now. Hopefully someone fixes the nsf4 issues.

[scorp123 (scorp123)]

NFS4?? Writing stuff like ...

/smb *(rw,async,no_root_squash,no_subtree_check)

... into your /etc/exports _CLEARLY_ is NFSv2/NFSv3 syntax and _NOT_ NFSv4 syntax. And I already wrote where this bug comes from:

nfs-common
nfs-kernel-server

The "mount.nfs" binaries in those packages simply don't understand the mount options anymore that I need for "Sun Secure Global Desktop" and its "Client Drive Mapping" mechanism to function on Ubuntu

Did you even try what I wrote in my first posting over one year ago? Put this line into your /etc/exports:
/smb *(rw,async,no_root_squash,no_subtree_check)

And then try and mount it with this command:
sudo mount -t nfs -o rw,udp,mountvers=2,port=4242 localhost:/smb /smb

With Ubuntu 7.10 and earlier ==> Above command WORKS.
With Ubuntu 8.04 and later ==> Above command DOES NOT WORK.

Unless you tried the same options (rw,udp,mountvers=2,port=4242) then I'd say your problem has nothing to do with this bug or NFS4. Sorry to say so.

Results with Ubuntu 7.10:
sudo mount -t nfs -o rw,udp,mountvers=2,port=4242 localhost:/smb /smb

=> WORKS!

Results with Ubuntu 9.10:

sudo mount -t nfs -o rw,udp,mountvers=2,port=4242 localhost:/smb /smb
mount.nfs: an incorrect mount option was specified

Variations, leaving parts of the parameters away:

sudo mount -t nfs -o rw,udp,port=4242 localhost:/smb /smb
mount.nfs: mount system call failed

sudo mount -t nfs -o rw,port=4242 localhost:/smb /smb
mount.nfs: mount system call failed

This stuff WORKED in Ubuntu 7.10

[Florian Diesch (diesch)]

Thanks for reporting this bug and any supporting documentation.

According to nfs(5) mountvers=n should be supported by mount.nfs but it's not:

$ sudo mount.nfs localhost:/smb /mnt -o mountvers=2
mount.nfs: an incorrect mount option was specified

nfs-common:
  Installed: 1:1.2.0-2ubuntu8
  Candidate: 1:1.2.0-2ubuntu8
  Version table:
 *** 1:1.2.0-2ubuntu8 0
        500 http://de.archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here. Thanks for taking the time to make Ubuntu better!

[Steve Langasek (vorlon)]

In nfs(5), the mountvers option is described as:

  The RPC version number used to contact the server's mountd. If this option is not specified, the client uses a version number appropriate to the requested NFS version. This option is useful when multiple NFS services are running on the same remote server host.

The question is, why are you specifying the *mount RPC version* instead of specifying the NFS protocol version and letting mount figure out the mountd version to use on its own? It's not that mount.nfs doesn't allow 'mountvers=n', it's that it doesn't want you to use mountvers=*2* here. Other values of 'n' work just fine, as does specifying an NFS protocol version with 'nfsvers=' instead.

This probably is a bug (unless there happens to be some reason that mount version 2 has been deliberately disabled as insecure or dangerous?), but it looks to me like best practices would be to not use this option at all.

[scorp123 (scorp123)]

Please read the early comments. Oracle SGD demands these options. They work with Ubuntu before 8.04, they work in Oracle Linux, RHEL, Solaris 10 ... they don't work anymore here. Why I want to use these options or not utterly irrelevant. Fact is this stuff worked before ... now it doesn't :(

[Steve Langasek (vorlon)]

Have you tested specifying nfsvers=n in place of mountvers=n, and found that it didn't work? My assertion is that, contrary to the SGD documentation, 'mountvers' should normally not need to be specified explicitly.

> They work with Ubuntu before 8.04, they work in Oracle Linux, RHEL, Solaris 10 ... they
> don't work anymore here.

The behavior change is a result of changes in nfs-utils upstream; this is not an Ubuntu-specific change. I would expect the same problem to affect recent versions of RHEL, for instance.

[scorp123 (scorp123)]

@Steve Langasek:

The options CANNOT be specified. *PLEASE* => read my comments early on.
Quote:

"... As per these instructions by SUN, when you issue this command:

/opt/tta_tem/bin/tem startcdm

... to trigger the "client drive mapping" functionality then this script "/opt/tta_tem/bin/tem" is executed which ultimately triggers the mount command I give above (I checked via "strace"):

"mount -t nfs -o rw,udp,mountvers=2,port=4242 localhost:/smb /smb"

So this explains why I need above command to work, no matter how strange and pointless it may look. ... "

> My assertion is that, contrary to the SGD documentation, 'mountvers'
> should normally not need to be specified explicitly.

My assertion is that this option should not have been touched, damn it!! This boneheaded changing of options because "nobody should be using this" is making Debian and Ubuntu *impossible* to use in a professional environment. One day the option is there ... you upgrade a few packages and ... *POOOOFFF!* ... option is gone all of a sudden and your Enterprise Remote Access solution partially stops to work.

Nice one. Seriously. :-(

> I would expect the same problem to affect recent versions of RHEL, for instance.

I can test that.

[Steve Langasek (vorlon)]

> So this explains why I need above command to work, no matter how
> strange and pointless it may look.

Well, the straightforward workaround for this should be:
 - create a shell script named 'mount' that maps 'mountvers=2' to 'nfsvers=2' and calls /bin/mount
 - put this shell script in /usr/local/bin
 - make sure /usr/local/bin is in the path before /bin
 - call /opt/tta_tem/bin/tem startcdm

If that doesn't work, you can use 'dpkg-divert' to permanently move /bin/mount aside in a way that will be respected on upgrades, and install your script directly as /bin/mount.

> My assertion is that this option should not have been touched, damn it!!

That's as may be, but we didn't touch it. You'd have to take up the question of not touching it with linux-nfs upstream.

> This boneheaded changing of options because "nobody should be using
> this" is making Debian and Ubuntu *impossible* to use in a professional
> environment.

This is not due to any Debian or Ubuntu changes; it's due to an upstream change, probably one that was meant to fix something else and only incidentally broke mount version 2 support. And it probably went unnoticed because the only thing affected was a version of the protocol that's been *obsolete* for a decade.

I agree that it's a bug to have the option stop working. I also think it's a bug that the software you're using is setting that option. Neither of these bugs are going to be a high priority for the Ubuntu team, because the number of users affected by problems with NFSv2 support is very, very small.

> One day the option is there ... you upgrade a few packages
> and ... *POOOOFFF!* ... option is gone all of a sudden and your
> Enterprise Remote Access solution partially stops to work.

> Nice one. Seriously. :-(

If by "upgrade a few packages" you mean "upgrade to the next version of the release, which is not guaranteed to be feature-compatible with the previous version", sure.

The way I see it, you have several options to get this bug fixed.
 - Talk to upstream.
 - Work out how to fix it yourself.
 - Contract someone to fix the bug. There are a number of companies that provide paid support for Linux distributions, including for Debian and Ubuntu. For information about Canonical's paid support options, see <http://www.ubuntu.com/support>.

But escalating the bug via the community bug tracker is not likely to lead to a fix in the foreseeable future, because this is going to be a deep bug and there are a lot of other bugs that need fixing.

[scorp123 (scorp123)]

> That's as may be, but we didn't touch it. You'd have to take up
> the question of not touching it with linux-nfs upstream.

Yes, I get it. I'll try that too. Thanks so far.

> because the only thing affected was a version of the protocol that's
> been *obsolete* for a decade.

A lot of "Enterprise" stuff (be that software or OS) still use tons of obsolete things, e.g. HP-UX and Solaris still install r*-tools (rcp, rlogin, rsh, and so on), and so on, and so on. I've been in server rooms where they still use VAX and PDP-something machines in active production ... :)

Thanks for your patience and help so far.