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?
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.
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==
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 [email protected]
Boulder, CO 80301 http://www.nwra.com
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)