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

exa 662711 at bugs.launchpad.net
Wed Aug 17 14:53:48 UTC 2011


Dear Steve,

Thank you for your interest in the matter. It's costing me precious
time, so all help is greatly appreciated. Many thanks!

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

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

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

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.

So, idmapd is running, then what is with the nfs-common config? Oh,
well, it does work now, but why didn't it work before? Issuing sudo
start idmapd didn't change anything?

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.

Slightly at a loss, although happy that my problem is solved by a Deus
Ex Machina :)

The point is that, I had to restart idmapd, *even though* the
configuration was correct, and the system claimed it to be already
running. Those who suffer from this bug, please take note. And please
can somebody test this (somewhat unexpected) workaround on a vanilla
11.04 system? Note that I didn't add anything to fstab. That's why it's
a little strange. That is to say, there is definitely a bug but I can't
pinpoint where exactly.

If you need extra information from my system, please let me know.

Cheers,

-- 
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




More information about the foundations-bugs mailing list