You are not logged in.
Hi,
My logs are flooded with an error from request-key:
request-key: /etc/request-key.d/id_resolver.conf Missing macro nameid_resolver.conf contains the regular nfsidmap command:
create id_resolver * * /usr/bin/nfsidmap %k %dAny clues on what I'm missing?
Thank you in advance.
Last edited by geekmiki (2013-08-21 08:28:31)
Offline
Hi, some weeks old, but I have the exact same issue. What is this and how can we make it stop?
Offline
Getting this here too.
Offline
Hi,
My logs are flooded with an error from request-key:
request-key: /etc/request-key.d/id_resolver.conf Missing macro nameid_resolver.conf contains the regular nfsidmap command:
create id_resolver * * /usr/bin/nfsidmap %k %dAny clues on what I'm missing?
Thank you in advance.
Getting exactly the same thing. Goggling around didn't help.
Anybody any clues ?
I am using NFS and samba.
Will disable samba first.
Mektub
Follow me on twitter: https://twitter.com/johnbina
Offline
Hi,
I exactly have the same problem. It's killing my SSD uselessly. Somebody has something new about that ?
Offline
Hello
Same here. This started happening after an update on my Synology NAS to which I connect using NFS...
Offline
From a quick skim of request-key.c, "Missing macro name" is only supposed to occur when you have a % sign by itself in an argument (macro escape with no macro signification). That is obviously not the case here, as %k and %d should both be parsed in the same argument as their aforementioned escape character.
There's either a bug in the config file parser or in its documentation, because the format matches the description on the man page for request-key.conf, but this error is spawned anyway.
I noted a workaround, however: if you explicity define -t, the error quits appearing in the log. My file now looks like this and the error is gone:
create id_resolver * * /usr/bin/nfsidmap -t 600 %k %dDebian, Ubuntu, and RHEL all also include the explicit -t. Arch excluded it probably because they didn't see the sense in explicitly defining the default value, but again, it seems there is a bug in the parser or some other impediment that makes this line misbehave without the explicit time flag. It is also possible that the documentation has incorrectly specified the format. This can probably also be worked around by explicitly defining another flag.
Last edited by cookiecaper (2014-01-01 19:11:50)
Offline
After employing this work around, I noted a new line in my log, seemingly occuring every time the request-key.d/id_resolver.conf line was processed:
nfsidmap[3870]: nss_getpwnam: name 'admin' not found in domain 'localdomain'I googled and followed the advice of someone on a mailing list to change /etc/hosts's localhost.localdomain mapping to localhost.domain. This may have other unexpected implications but it is working for the time being, without spamming my log.
Offline