Red Hat Bugzilla – Bug 746497
Configuration file ignored
Last modified: 2011-11-19 01:03:58 EST
After upgrading to nfs-utils-1.2.5-1.fc16.x86_64 rpc.idmapd stopped to recognize the Translation/Mapping configuration I had in my idmap.conf file.
I've reported this upstreams with more details and an explanation of what I believe is the problem. See https://bugzilla.linux-nfs.org/show_bug.cgi?id=205 for further information. With this report I wish to ask for the fix when it is available to be included in F16.
I believe I have hit the same problem with different symptoms. 'Domain' is ignored from idmapd.conf. It seems that idmapd in F16 is entirely ignoring its config file.
I've bisected nfs-utils, and the regression was introduced by this seemingly innocuous change to the build system: d7c64ddf66b04a225fab249af8a8fdd684551c5c. As far as I can tell, before this change, we were not linking against libnfsidmap, but after it we are.
Specifically, the bug seems to be caused by nfs4_init_name_mapping in libnfsidmap re-calling conf_init() *after* idmapd has already called it in main(). This wipes all previously parsed config. Although the config is then re-parsed, somehow config_bindings doesn't end up being populated the second time it runs. I haven't fully followed this through yet, so I haven't managed to work out why.
There's a very simple reproducer for this. Change Domain to something random in /etc/idmapd.conf, and run rpc.idmapd -vvf. The domain used is output almost immediately. If it outputs the random value from /etc/idmapd.conf it has succeeded. If it outputs a default value taken from the domain name of the host, it has failed.
I can confirm this, and that it causes real problems. For those having this problem, if the only problem is the Domain, here's my very ugly and hopefully very temporary work-around: I stop the idmapd service, change the hostname so that the default Domain comes out right, start idmapd, and then change the hostname back to what it should be. In other words, this works:
systemctl stop nfs-idmap.service
systemctl start nfs-idmap.service
A single restart (instead of stop/start) would probably work as well, but what's above is the way I have done it, and idmapd is working OK now (but the Domain was the only non-default setting I have). Of course, you'll have to do that after any reboot as well (could script it...).
Looking forward to a real fix!
If your only problem is the domain, maybe a slightly less ugly work-around would be to set
nfs-utils-1.2.5-3.fc16 has been submitted as an update for Fedora 16.
Goran: Unfortunately, that doesn't work. The latest versions of idmapd (with the borked config file reading) also disable the "-d" command line option. So there is, in fact, no way to have it use a different domain without fooling it with a fake hostname.
The comments with the nfs-utils update say this fixes the problem though, which is great. I'm waiting for it to pass through the release system....
> Unfortunately, that doesn't work.
Hm, I thought I used it for a while. But maybe that was earlier, trying to understand other issues I had.
Anyway, I completely agree it's good a version that fixes it is on the way. :-)
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing nfs-utils-1.2.5-3.fc16'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
nfs-utils-1.2.5-3.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.