[Bug 662711] Re: idmap should be started by default because mount.nfs now negotiates NFSv4 before NFSv3

[Steve Langasek]

On Wed, Aug 17, 2011 at 02:53:48PM -0000, exa wrote:
> I've now checked my nfs-common config, it had the following relevant
> bits:

> # Do you want to start the statd daemon? It is not needed for NFSv4.
> NEED_STATD=yes
> ...
> # Do you want to start the idmapd daemon? It is only needed for NFSv4.
> NEED_IDMAPD=yes

Ok.

> GSSD is turned off by default, and I hope it has nothing to do with this
> bug.

Yes, gssd is unrelated unless you are using sec=krb5* mount options.

> For testing purposes I'm using a single NFS4 export line (but it fails with any config, that is not relevant):
> /exports 	*(ro,fsid=0,no_subtree_check,async)

> After this point I restarted nfs server, and the mount still failed to
> produce correct uid/gid values, but then....

> So, well, does idmapd run? Yes, I've checked:
> examachine at cylon:~$ ps aux | grep idmap
> 1000     32731  0.0  0.0  13124  1060 pts/3    S+   17:31   0:00 grep --color=auto idmap
> examachine at cylon:~$ sudo start idmapd
> start: Job is already running: idmapd
> examachine at cylon:~$ ps aux | grep idmap
> root       622  0.0  0.0  27336   888 ?        Ss   17:35   0:00 rpc.idmapd
> 1000      2038  0.0  0.0  13128  1060 pts/3    S+   17:47   0:00 grep --color=auto idmap

Is this on the client or server?

The above output doesn't make sense to me.  First you show ps output with no
idmapd running; then you show the output of a 'start' command that reports
that it's already running; then it appears in the ps output.  None of these
things follow from one another.

It may be that you're encountering a bug in the startup of idmapd at boot,
unrelated to this bug report.  There is an SRU awaiting verification for
precisely such an issue: bug #811823.

> However, AFTER the above command, strangely, idmapd suddenly starts
> giving the right behavior, could it be a permissions  or locking problem
> or something trivial like that? Or starting idmapd only if nfs I believe
> I'm using the desktop installation.

As mentioned, idmapd will not start up automatically if it doesn't detect
that it's needed.  When it declines to start for this reason, the upstart
job will be left in 'stopped' state.  So it should be enough to edit the
config file and run 'service idmapd start' once to fix the problem.

> Ok, the problem might be with the logic that looks at whether nfs4
> entries are present on the fstab. I might want to mount them from the
> command line, etc, and I shouldn't have to start daemons manually to
> make that happen.

Yes, that's the bit here that I've confirmed is a bug in nfs-utils.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to nfs-utils in Ubuntu.
https://bugs.launchpad.net/bugs/662711

Title:
  idmap should be started by default because mount.nfs now negotiates
  NFSv4 before NFSv3

Status in “nfs-utils” package in Ubuntu:
  Triaged

Bug description:
  I have a NFS client/server setup where both client and server are
  Ubuntu 10.10 (both upgraded from 10.4)

  To make UID and GID mapping trivial, I've made sure that clients and
  server all have the same users and groups with the same IDs. This used
  to work fine. However now the client is always displaying 4294967294
  for the UID and GID but - and here is the strange bit - if I create a
  file on the client it shows up on the server with the correct user and
  group (but on the client still with 4294967294).

  I posted this originally on the forums, and decided to file this bug
  when 2 other people reported having the same problem since upgrading
  to 10.10. In both cases they were using Ubuntu as client and Solaris
  as server. See thread here:
  http://ubuntuforums.org/showthread.php?p=9983624

  Additional info:

  /etc/exports line on the server:
  data/fileserver 192.168.1.0/255.255.255.0(rw,sync,no_subtree_check)

  /etc/fstab line on the client:
  htpc:/data/fileserver /data/fileserver nfs defaults 0 0

  Trying to chown a file on the client gives the error "chown: changing
  ownership of `somefile': Invalid argument"

  ProblemType: Bug
  DistroRelease: Ubuntu 10.10
  Package: nfs-common 1:1.2.2-1ubuntu1
  ProcVersionSignature: Ubuntu 2.6.35-22.34-generic 2.6.35.4
  Uname: Linux 2.6.35-22-generic x86_64
  NonfreeKernelModules: nvidia
  Architecture: amd64
  Date: Mon Oct 18 15:40:16 2010
  ProcEnviron:
   PATH=(custom, user)
   LANG=en_US.utf8
   SHELL=/bin/bash
  SourcePackage: nfs-utils

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/662711/+subscriptions