[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Reply to: