Bug#582003: nfs-common: nfs client ignores "port=2049" option when mounting
 

Package: nfs-common
Version: 1:1.2.2-1
Severity: normal
Tags: sid

Hi,

I'm trying to mount an NFS server that isn't registered in the portmapper. I
believe this has worked in the past and something changed moderately recently
(probably between 2009-11-19 and 2010-5-1) that broke this behaviour.

The options supplied to mount (via -o) are:

nfsvers=2,nolock,udp,noac,intr,rw,mountport=<mount >,port=2049

(where <mount> is the UDP port of the NFS mount daemon; the mount daemon isn't
bound to some well-known port, but is discovered by a support script)

An attempt to mount the NFS server using the above options fails. Watching the
network traffic, I see the following SunRPC calls:

1. SunRPC NULL call to a MOUNT service (running on UDP port <mount>) ... this
is successful
2. SunRPC MNT call to a MOUNT service (running on UDP port <mount>) ... this
is successful
3. SunRPC GETPORT call to Portmap service .. this is unsuccessful (no
registered program)

The failing GETPORT call to portmapper is querying for program 10000003 (NFS),
version 2, proto UDP. The failure of this call is expected: the NFS server
isn't registered in the portmapper service, so such a query should fail.
However, what isn't clear is why the client is calling the Portmapper service
since the port number has been supplied in the mount options ("port=2049")

What is interesting is if a different port value is specified (e.g.,
"port=2050") then the network interaction changes to:

1. SunRPC NULL call to a MOUNT service ... this is successful
2. SunRPC MNT call to a MOUNT service ... this is successful
3. SunRPC NULL call to UDP port 2050 ... this is unsuccessful (no reply)

Since there is no program listening on port 2050, the attempt to call NULL on
that port will have no reply (the mount will eventually time-out); however,
notice how no attempt is made to contact the Portmapper service to discover the
NFS daemon port.

I'd speculate that the problem here is that port=2049 is somehow used as a
place-holder value indicating that the NFS daemon port value is unknown. If
so, then the system will be unable to distinguish between a mount request with
options including "port=2049" and options without any "port" option. However,
the behaviour of the NFS client should be different: if port=2049 is specified
then the RPC portmapper lookup is unnecessary and should be avoided.

It's unclear to me whether the problem is in mount.nfs or with the Linux kernel
itself (fs/nfs). I've assigned it to nfs-common as an initial guess, but the
problem may lie in the kernel code.

NB, I'm running the Nouveau kernel, which is based on 2.6.32 whilst waiting for
2.6.33 (and the Nouveau DRM driver) to appear in sid. This NFS problem could
be an artifact of using this kernel; but I've scanned the changelog of the
2.6.32 kernels and there doesn't seem to be a fix for this issue mentioned.

Cheers,

Paul.



-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'oldstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-20100317 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages nfs-common depends on:
ii adduser 3.112 add and remove users and groups
ii initscripts 2.87dsf-10 scripts for initializing and shutt
ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib
ii libcap2 1:2.17-2 support for getting/setting POSIX.
ii libcomerr2 1.41.11-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



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100517152309.31520.88093.reportbug@zitpcx6184.de sy.de">http://lists.debian.org/20100517152309.31520.88093.reportbug@zitpcx6184.de sy.de

Bug#582003: nfs-common: nfs client ignores "port=2049" option when mounting
 

On Mon, 2010-05-17 at 17:23 +0200, Paul Millar wrote:
> Package: nfs-common
> Version: 1:1.2.2-1
> Severity: normal
> Tags: sid
>
> Hi,
>
> I'm trying to mount an NFS server that isn't registered in the portmapper. I
> believe this has worked in the past and something changed moderately recently
> (probably between 2009-11-19 and 2010-5-1) that broke this behaviour.
>
> The options supplied to mount (via -o) are:
>
> nfsvers=2,nolock,udp,noac,intr,rw,mountport=<mount >,port=2049
>
> (where <mount> is the UDP port of the NFS mount daemon; the mount daemon isn't
> bound to some well-known port, but is discovered by a support script)
>
> An attempt to mount the NFS server using the above options fails. Watching the
> network traffic, I see the following SunRPC calls:
>
> 1. SunRPC NULL call to a MOUNT service (running on UDP port <mount>) ... this
> is successful
> 2. SunRPC MNT call to a MOUNT service (running on UDP port <mount>) ... this
> is successful
> 3. SunRPC GETPORT call to Portmap service .. this is unsuccessful (no
> registered program)
>
> The failing GETPORT call to portmapper is querying for program 10000003 (NFS),
> version 2, proto UDP. The failure of this call is expected: the NFS server
> isn't registered in the portmapper service, so such a query should fail.
> However, what isn't clear is why the client is calling the Portmapper service
> since the port number has been supplied in the mount options ("port=2049")
[...]

Right. For whatever reason, mount.nfs processes the options into a
canonical form and at this point it will lose the port=2049 option.
Please can you test the following patch:

--- nfs-utils-1.2.2.orig/utils/mount/stropts.c
+++ nfs-utils-1.2.2/utils/mount/stropts.c
@@ -434,8 +434,8 @@
if (po_append(options, new_option) == PO_FAILED)
return 0;

- po_remove_all(options, "port");
- if (nfs_pmap->pm_port != NFS_PORT) {
+ if (po_remove_all(options, "port") == PO_FOUND ||
+ nfs_pmap->pm_port != NFS_PORT) {
snprintf(new_option, sizeof(new_option) - 1,
"port=%lu", nfs_pmap->pm_port);
if (po_append(options, new_option) == PO_FAILED)
--- END ---

You can find a version of the nfs-utils package including this patch
under <http://people.debian.org/~benh/>.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

Bug#582003: nfs-common: nfs client ignores "port=2049" option when mounting
 

Hi Ben,

On Wednesday 19 May 2010 05:44:56 Ben Hutchings wrote:
[...]
> > However, what isn't clear is why the client is calling the
> > Portmapper service since the port number has been supplied in the mount
> > options ("port=2049")
>
> [...]
>
> Right. For whatever reason, mount.nfs processes the options into a
> canonical form and at this point it will lose the port=2049 option.
> Please can you test the following patch:

[...]

Ah! That would explain it.

I've applied the patch and rebuilt mount.nfs. There's now no portmapper
interaction (when port=2049 is specified) and mounting the NFS server works
fine.

Many thanks!

Paul.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201005191001.03889.paul.millar@desy.de">http://lists.debian.org/201005191001.03889.paul.millar@desy.de