rpc.idmapd: nss_getpwnam: name '#' does not map into domain

rpc.idmapd: nss_getpwnam: name '#' does not map into domain

[Orion Poplawski]

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?

Re: rpc.idmapd: nss_getpwnam: name '#' does not map into domain

[Orion Poplawski]

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?

These *appear* to be triggered by the following types of requests:


Network File System, Ops(3): PUTFH SETATTR GETATTR
    [Program Version: 4]
    [V4 Procedure: COMP (1)]
    Tag: <EMPTY>
        length: 0
        contents: <EMPTY>
    minorversion: 0
    Operations (count: 3)
        Opcode: PUTFH (22)
            filehandle
                length: 28
                [hash (CRC-32): 0xcdbd24f8]
                decode type as: unknown
                filehandle: 010006018355CA85FB1E02DF00000000000000000A00682B...
        Opcode: SETATTR (34)
            stateid
                seqid: 0x00000000
                Data: 000000000000000000000000
            obj_attributes
                attrmask
                    recc_attr: FATTR4_OWNER (36)
                        fattr4_owner: 612
                            length: 3
                            contents: 612
                            fill bytes: opaque data
                    recc_attr: FATTR4_OWNER_GROUP (37)
                        fattr4_owner_group: 1001
                            length: 4
                            contents: 1001
            attr_vals: <DATA>
                length: 16
                contents: <DATA>
        Opcode: GETATTR (9)
            GETATTR4args
                attr_request
                    bitmap[0] = 0x0010011a
                        [5 attributes requested]
                        mand_attr: FATTR4_TYPE (1)
                        mand_attr: FATTR4_CHANGE (3)
                        mand_attr: FATTR4_SIZE (4)
                        mand_attr: FATTR4_FSID (8)
                        recc_attr: FATTR4_FILEID (20)
                    bitmap[1] = 0x0030a23a
                        [9 attributes requested]
                        recc_attr: FATTR4_MODE (33)
                        recc_attr: FATTR4_NUMLINKS (35)
                        recc_attr: FATTR4_OWNER (36)
                        recc_attr: FATTR4_OWNER_GROUP (37)
                        recc_attr: FATTR4_RAWDEV (41)
                        recc_attr: FATTR4_SPACE_USED (45)
                        recc_attr: FATTR4_TIME_ACCESS (47)
                        recc_attr: FATTR4_TIME_METADATA (52)
                        recc_attr: FATTR4_TIME_MODIFY (53)

Re: rpc.idmapd: nss_getpwnam: name '#' does not map into domain

[Myklebust, Trond]

T24gV2VkLCAyMDEzLTA4LTE0IGF0IDE5OjI0ICswMDAwLCBPcmlvbiBQb3BsYXdza2kgd3JvdGU6
DQo+IE9yaW9uIFBvcGxhd3NraSA8b3Jpb25ALi4uPiB3cml0ZXM6DQo+IA0KPiA+IA0KPiA+IE9u
IG91ciBFTDYgbmZzIHNlcnZlcnMgd2Ugc2VlIHBlcmlvZGljIG1lc3NhZ2VzIGxpa2U6DQo+ID4g
DQo+ID4gQXVnIDE0IDEyOjU1OjE5IGFsZXhhbmRyaWEgcnBjLmlkbWFwZFsxOTIzN106IG5zc19n
ZXRwd25hbTogbmFtZSAnNjEyJyBkb2VzDQo+ID4gbm90IG1hcCBpbnRvIGRvbWFpbiAnY29yYS5u
d3JhLmNvbScNCj4gPiANCj4gPiBJIGltYWdpbmUgdGhhdCB0aGlzIGlzIGNhdXNlZCBieSBhIGNs
aWVudCBhY3R1YWxseSBwYXNzaW5nIHRoZSB1aWQgaW5zdGVhZA0KPiA+IG9mIHRoZSB1c2VybmFt
ZSBmb3Igc29tZSByZWFzb24gYnV0IEkgaGF2ZSBubyBpZGVhIGhvdyB0byB0cmFjayBkb3duIHdo
aWNoLg0KPiA+ICBBbnkgaWRlYXM/DQoNCkFyZSB5b3Ugc2VlaW5nIGFueSBfYWN0dWFsXyBhcHBs
aWNhdGlvbiBlcnJvcnM/DQoNCj4gVGhlc2UgKmFwcGVhciogdG8gYmUgdHJpZ2dlcmVkIGJ5IHRo
ZSBmb2xsb3dpbmcgdHlwZXMgb2YgcmVxdWVzdHM6DQo+IA0KPiANCj4gTmV0d29yayBGaWxlIFN5
c3RlbSwgT3BzKDMpOiBQVVRGSCBTRVRBVFRSIEdFVEFUVFINCg0KVGhhdCBpcyAxMDAlIGV4cGVj
dGVkIGJlaGF2aW91ciBpZiB5b3UgYXJlIHVzaW5nIEFVVEhfU1lTIG9uIHRoZSBjbGllbnQNCihz
ZWUgdGhlIGV4cGxhbmF0aW9uIGluIFJGQzM1MzBiaXMpLiBUaGUgZGVmYXVsdCB0aGVyZSBpcyB0
byB1c2UNCnVubWFwcGVkIHVpZHMgYW5kIGdpZHMgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkg
d2l0aCBORlN2MywgYW5kIHRvDQplbnN1cmUgdGhhdCB0aGUgbmFtZXMvZ3JvdXBzIHVzZWQgYnkg
TkZTdjQgbWF0Y2ggdGhlIHVpZHMvZ2lkcyB1c2VkIGJ5DQp0aGUgQVVUSF9TWVMgYXV0aGVudGlj
YXRpb24uDQoNCkluIHRoZSBjYXNlIHdoZXJlIHRoZSBORlN2NCBzZXJ2ZXIgZG9lc24ndCBzdXBw
b3J0IHRoYXQgbW9kZSBvZg0Kb3BlcmF0aW9uLCBpdCBpcyBleHBlY3RlZCB0byByZXR1cm4gTkZT
NEVSUl9CQURPV05FUiAoYWx0aG91Z2ggTGludXgNCmNsaWVudHMgYWxzbyBhY2NlcHQgTkZTNEVS
Ul9CQUROQU1FKSBpbiB3aGljaCBjYXNlIHRoZSBjbGllbnQgd2lsbA0Kc3dpdGNoIHRvIHVzaW5n
IG1hcHBlZCBpZHMuDQoNCi0tIA0KVHJvbmQgTXlrbGVidXN0DQpMaW51eCBORlMgY2xpZW50IG1h
aW50YWluZXINCg0KTmV0QXBwDQpUcm9uZC5NeWtsZWJ1c3RAbmV0YXBwLmNvbQ0Kd3d3Lm5ldGFw
cC5jb20NCg==

Re: rpc.idmapd: nss_getpwnam: name '#' does not map into domain

[Orion Poplawski]

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

Re: rpc.idmapd: nss_getpwnam: name '#' does not map into domain

[J. Bruce Fields]

On Wed, Aug 14, 2013 at 02:27:48PM -0600, Orion Poplawski wrote:
> 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.

Could be.  Newer idmapd may have some other changes here too, I don't
remember.

Note newer upstream server kernels will accept numeric id's from the
client.

--b.