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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
