From: Orion Poplawski <orion@cora.nwra.com>
To: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: rpc.idmapd: nss_getpwnam: name '#' does not map into domain
Date: Wed, 14 Aug 2013 14:27:48 -0600 [thread overview]
Message-ID: <520BE844.9030408@cora.nwra.com> (raw)
In-Reply-To: <1376510917.29258.55.camel@leira.trondhjem.org>
On 08/14/2013 02:08 PM, Myklebust, Trond wrote:
> On Wed, 2013-08-14 at 19:24 +0000, Orion Poplawski wrote:
>> Orion Poplawski <orion@...> writes:
>>
>>>
>>> On our EL6 nfs servers we see periodic messages like:
>>>
>>> Aug 14 12:55:19 alexandria rpc.idmapd[19237]: nss_getpwnam: name '612' does
>>> not map into domain 'cora.nwra.com'
>>>
>>> I imagine that this is caused by a client actually passing the uid instead
>>> of the username for some reason but I have no idea how to track down which.
>>> Any ideas?
>
> Are you seeing any _actual_ application errors?
Not that I'm aware of.
>> These *appear* to be triggered by the following types of requests:
>>
>>
>> Network File System, Ops(3): PUTFH SETATTR GETATTR
>
> That is 100% expected behaviour if you are using AUTH_SYS on the client
> (see the explanation in RFC3530bis). The default there is to use
> unmapped uids and gids for backward compatibility with NFSv3, and to
> ensure that the names/groups used by NFSv4 match the uids/gids used by
> the AUTH_SYS authentication.
>
> In the case where the NFSv4 server doesn't support that mode of
> operation, it is expected to return NFS4ERR_BADOWNER (although Linux
> clients also accept NFS4ERR_BADNAME) in which case the client will
> switch to using mapped ids.
Thanks, finally came across that. I'm wondering if it is worth changing
libnfsidmap to not log this message in these cases.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion@nwra.com
Boulder, CO 80301 http://www.nwra.com
next prev parent reply other threads:[~2013-08-14 21:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-14 19:09 rpc.idmapd: nss_getpwnam: name '#' does not map into domain Orion Poplawski
2013-08-14 19:24 ` Orion Poplawski
2013-08-14 20:08 ` Myklebust, Trond
2013-08-14 20:27 ` Orion Poplawski [this message]
2013-08-16 20:51 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=520BE844.9030408@cora.nwra.com \
--to=orion@cora.nwra.com \
--cc=Trond.Myklebust@netapp.com \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.