[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