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@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@cylon:~$ sudo start idmapd > start: Job is already running: idmapd > examachine@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/ slanga...@ubuntu.com vor...@debian.org -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/662711 Title: idmap should be started by default because mount.nfs now negotiates NFSv4 before NFSv3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/662711/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
