Bug#582107: mounts default to version 4, don't fall back automatically
Package: nfs-common
Version: 1:1.2.2-1
Severity: normal
I don't mean to intrude in this bug report, but I have been experiencing
a similar issue for several months. I did not report a bug for two
reasons:
1) I believed there must have been some recent change upstream (late
2009 or early 2010) which caused the mounting behavior of NFS to change.
2) I mostly use custom-compiled kernels, and only keep a Debian kernel
installed in case I do something completely stupid with my own kernels
and need a safety net.
In short, I didn't think there was a bug: I guessed the change in NFS
mounting behavior was related to a transition to NFSv4, which I have not
been using in my kernels. Upon closer inspection, I think there may be
a bug after all.
I don't mount NFS shares using /etc/fstab, but instead have a one-liner
script which I run when the "fileserver" machine is actually turned on
and I want to use it:
mount -t nfs -o rw,async,hard,intr fileserver:/path/to/files /local/mount/point
My homemade kernel fails with this error message
mount.nfs: an incorrect mount option was specified
while running the same command with the Debian kernel succeeds. (My
homemade kernel also succeeds if I add "nfsvers=3" to the mount
options.) When my script first failed a few months ago, I assumed that
upstream had changed to prefer NFSv4 and that NFSv3 had to be manually
selected.
When I began compiling my own kernels a few years ago, NFSv4 was
experimental and I chose not to enable it; the '.config' settings I use
(both on my desktop machine and on the "fileserver" machine) for NFS
look like this:
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
# CONFIG_NFSD_V4 is not set
CONFIG_NFS_COMMON=y
In other words, the NFS server on "fileserver" only supports NFSv3.
Looking more carefully at the man pages for 'mount' and 'nfs', I now see
that nfs-client _should_ be able to automatically negotiate a
connection; NFSv4 has nothing to do with the problem, since my one-liner
script is using a mount type of "nfs" (and not "nfs4").
I wonder whether the OP is using a Debian kernel or a custom-compiled
one? For me, Debian kernels mount NFSv3 just fine; only my custom build
does not work.
(I just wanted to add this information to the bug report, in case it is
helpful in some way. I will soon be adding NFSv4 support to my home
network -- long overdue -- and the "nfsvers=3" workaround wasn't very
difficult to use anyway.)
Dave W.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (990, 'unstable'), (350, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.34+drt100429.0818fe9.desktop.kms (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages nfs-common depends on:
ii adduser 3.112 add and remove users and groups
ii initscripts 2.88dsf-5 scripts for initializing and shutt
ii libc6 2.10.2-8 Embedded GNU C Library: Shared lib
ii libcap2 1:2.17-2 support for getting/setting POSIX.
ii libcomerr2 1.41.12-1 common error description library
ii libevent-1.4-2 1.4.13-stable-1 An asynchronous event notification
ii libgssapi-krb5-2 1.8.1+dfsg-2 MIT Kerberos runtime libraries - k
ii libgssglue1 0.1-4 mechanism-switch gssapi library
ii libk5crypto3 1.8.1+dfsg-2 MIT Kerberos runtime libraries - C
ii libkrb5-3 1.8.1+dfsg-2 MIT Kerberos runtime libraries
ii libnfsidmap2 0.23-2 An nfs idmapping library
ii librpcsecgss3 0.19-2 allows secure rpc communication us
ii libwrap0 7.6.q-18 Wietse Venema's TCP wrappers libra
ii lsb-base 3.2-23.1 Linux Standard Base 3.2 init scrip
ii netbase 4.41 Basic TCP/IP networking system
ii portmap 6.0.0-2 RPC port mapper
ii ucf 3.0025 Update Configuration File: preserv
nfs-common recommends no packages.
nfs-common suggests no packages.
-- no debconf information
Reply to: