mount.nfs fails stating incorrect mount option but succeeds if -v option is used

Bug #537746 reported by RParr
18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
util-linux (Ubuntu)
Incomplete
Undecided
Unassigned
Trusty
Confirmed
Undecided
Unassigned
Utopic
Won't Fix
Undecided
Unassigned
Vivid
New
Undecided
Unassigned

Bug Description

Binary package hint: mount

with /etc/fstab containing;

n2:/db /db nfs auto,nfsvers=3 0 0

OR containing

n2:/db /db nfs auto 0 0

# mount /db

fails with message "mount.nfs: an incorrect mount option was specified"

# mount n2:/db /db

also fails with the same message

BUT the following succeeds despite the "Operation not supported" message

# mount n2:/db /db -v
mount: no type was given - I'll assume nfs because of the colon
mount.nfs: timeout set for Thu Mar 11 15:14:50 2010
mount.nfs: text-based options: 'addr=63.227.222.65'
mount.nfs: mount(2): Operation not supported
mount.nfs: trying 63.227.222.65 prog 100003 vers 3 prot UDP port 2049
mount.nfs: trying 63.227.222.65 prog 100005 vers 3 prot UDP port 32767
mount.nfs: text-based options (retry): 'addr=63.227.222.65,vers=3,proto=udp,mountvers=3,mountproto=udp,mountport=32767'
n2:/db on /db type nfs (rw)

This system in question dual boots 10.04 and 8.04; under 8.04 ALL of the above succeeds without error messages.

This error is preventing NFS mounts in /etc/fstab; without a workaround or fix this prevents any deployment of Ubuntu 10.04 for us.

Revision history for this message
RParr (rparr) wrote :

Given the mounts did work if I used the -v option from the command line, I experimented with adding the options shown in the verbose output to the fstab options.

If I add the proto=udp option "an incorrect mount option" error message goes away and the mount succeeds as before.

n2:/db /db nfs auto,nfsvers=3,proto=udp 0 0

I tried the other options, and the ordering of the options, and found adding proto=udp was the option that made the error go away.

As can be seen from the verbose output, in this instance I am trying to mount volumes on an older server that only supports NFS vers 3.

Radu Cotescu (radu)
summary: - mount.nfs fails stating incorrect mount option but succeeds if -v or
- with 8.04
+ mount.nfs fails stating incorrect mount option but succeeds if -v option
+ is used
Changed in util-linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Radu Cotescu (radu) wrote :

This was actually not a bug. While NFS uses UDP by default, autofs5 seems to use TCP. The way to mount UDP NFS exports is to specify this as an option for the mount point.

Changed in util-linux (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Vladimir (vlsitereg) wrote :

Yes, this problem is present in final release.

Revision history for this message
Robert McKee (bertmanphx) wrote :

Hello,
I am having the problem as well. I have two NFS mounts. The first on works perfectly. The second one I added never mounts, unless I mount it manually at the command line. When I mount it from the command line, I get no errors. Below is my fstab.

Robert?field.comment=Hello,
I am having the problem as well. I have two NFS mounts. The first on works perfectly. The second one I added never mounts, unless I mount it manually at the command line. When I mount it from the command line, I get no errors. Below is my fstab.

I do not have the udp switch being used. The NFS server is 9.04.

Robert

Revision history for this message
Marc MAURICE (dooblem) wrote :

Hello,

We have this problem too.
Maybe this bug is not nfs related but autofs related.
But I still don't understand why you mark this bug as Invalid.

Thanks in advance.
Merry Christmas.
Marc

Revision history for this message
Kees Cook (kees) wrote :

Using "nfsvers=2" worked for me, but if you need =3, this seems like a bug in util-linux.

Changed in util-linux (Ubuntu):
status: Invalid → Confirmed
Changed in util-linux (Ubuntu Vivid):
status: Confirmed → New
Changed in util-linux (Ubuntu Trusty):
status: New → Confirmed
tags: added: regression-release
Revision history for this message
Phillip Susi (psusi) wrote :

Can you run mount under strace -F -eexecve and see if the arguments it passes to mount.nfs are different when you add the -v? If not then the bug is in mount.nfs rather than mount.

Changed in util-linux (Ubuntu):
status: New → Incomplete
tags: added: rls-w-incoming
Revision history for this message
Kevin Kramer (kmkramer71) wrote :

stumbled across this trying to debug my mount issues. Here is my strace attempting a default mount from the command line. The same autofs setup (auto.master, etc) work fine on SL 6.6 fwiw

strace -f -eexecve mount server:/export/ufs/hp /mnt
execve("/bin/mount", ["mount", "server:/export/ufs/hp", "/mnt"], [/* 51 vars */]) = 0
Process 14364 attached
Process 14363 suspended
[pid 14364] execve("/sbin/mount.nfs", ["/sbin/mount.nfs", "server:/export/ufs/hp", "/mnt", "-o", "rw"], [/* 47 vars */]) = 0
mount.nfs: an incorrect mount option was specified
Process 14363 resumed
Process 14364 detached
--- SIGCHLD (Child exited) @ 0 (0) ---

Changed in util-linux (Ubuntu Utopic):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.