Bug 823848 - NFSv4 idmapper maps files to user nobody
NFSv4 idmapper maps files to user nobody
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nfs-utils (Show other bugs)
6.2
All Linux
medium Severity medium
: rc
: ---
Assigned To: Steve Dickson
Red Hat Kernel QE team
:
Depends On: 855416 855417
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-22 06:10 EDT by Ralf Wagner
Modified: 2013-03-07 11:32 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-07 11:32:57 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ralf Wagner 2012-05-22 06:10:18 EDT
A NFS Share from a Solaris Maschine is mounted on a redhat and on a Ubuntu Client via NFSv4.
 
The Ubuntu Client works fine, while the Redhat Client maps all files to user nobody.

I did some traffic sniffing with wireshark which shows that both clients receive basicly the same packets. The GETATTR reply call packet  contains a numeric uid as fattr4_owner. Both Clients (redhat+ubuntu) have passwd entries for that user.

As the /etc/idmap.conf files on both clients look basicly the same i have no idea where to look further - i already increased the verbosity of the idmapper to the maximum but still have no valuable hint in teh syslog.
Comment 2 Steve Dickson 2012-05-22 08:07:12 EDT
What version of nfs-utils are you using?
Comment 3 Ralf Wagner 2012-05-22 09:14:14 EDT
nfs-utils-1.2.3-15.el6.i686
nfs4-acl-tools-0.3.3-5.el6.i686
nfs-utils-lib-1.1.5-4.el6.i686
Comment 4 Steve Dickson 2012-05-23 08:22:52 EDT
(In reply to comment #0)
> 
> As the /etc/idmap.conf files on both clients look basicly the same i have no
> idea where to look further - i already increased the verbosity of the
> idmapper to the maximum but still have no valuable hint in teh syslog.
Could you please post the debugging out put that is logged to /var/log/messages?
Comment 5 Ralf Wagner 2012-05-23 12:01:09 EDT
Hi,

this is what a "ls <filename>" that returns "user nobody" produces in the syslog:

May 23 16:23:37 <servername> rpc.idmapd[3284]: nfs4_name_to_uid: calling nsswitch->name_to_uid
May 23 16:23:37 <servername> rpc.idmapd[3284]: nss_getpwnam: name 'root@<domainname>' domain '<domainname>': resulting localname 'root'
May 23 16:23:37 <servername> rpc.idmapd[3284]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0
May 23 16:23:37 <servername> rpc.idmapd[3284]: nfs4_name_to_uid: final return value is 0
May 23 16:23:37 <servername> rpc.idmapd[3284]: Client 6: (user) name "root@<domainname>" -> id "0"
May 23 16:23:37 <servername> rpc.idmapd[3284]: nfs4_name_to_gid: calling nsswitch->name_to_gid
May 23 16:23:37 <servername> rpc.idmapd[3284]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0
May 23 16:23:37 <servername> rpc.idmapd[3284]: nfs4_name_to_gid: final return value is 0
May 23 16:23:37 <servername> rpc.idmapd[3284]: Client 6: (group) name "root@<domainname>" -> id "0"
May 23 16:23:37 <servername> rpc.idmapd[3284]: nfs4_name_to_uid: calling nsswitch->name_to_uid
May 23 16:23:37 <servername> rpc.idmapd[3284]: nss_getpwnam: name '123' domain '<domainname>': resulting localname '(null)'
May 23 16:23:37 <servername> rpc.idmapd[3284]: nss_getpwnam: name '123' does not map into domain '<domainname>'
May 23 16:23:37 <servername> rpc.idmapd[3284]: nfs4_name_to_uid: nsswitch->name_to_uid returned -22
May 23 16:23:37 <servername> rpc.idmapd[3284]: nfs4_name_to_uid: final return value is -22
May 23 16:23:37 <servername> rpc.idmapd[3284]: Client 6: (user) name "123" -> id "99"
May 23 16:23:37 <servername> rpc.idmapd[3284]: nfs4_name_to_gid: calling nsswitch->name_to_gid
May 23 16:23:37 <servername> rpc.idmapd[3284]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0
May 23 16:23:37 <servername> rpc.idmapd[3284]: nfs4_name_to_gid: final return value is 0
May 23 16:23:37 <servername> rpc.idmapd[3284]: Client 6: (group) name "<groupname>@<domainname>" -> id "301"


--> the uid that is transmitted in the GETATTR reply call packet is '123'. 

When i compare these logs whith the logs i see on the ubuntu machine there is no such call "nss_getpwnam: name '123' " - so it seems like the ubuntu machine takes the uid that is transmitted over the wire as the local uid.
Comment 6 RHEL Product and Program Management 2012-05-26 12:03:26 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 7 Jonathan Abbey 2012-07-06 01:37:01 EDT
We appear to be seeing this from recent Fedora 16 kernels.  See bug #837998
Comment 8 Jonathan Abbey 2012-07-06 10:51:11 EDT
Er, never mind, we're seeing a problem on a Fedora 16 client with a Red Hat 6.2 / 6.3 server.  This bug is reporting a RHEL client problem.
Comment 9 J. Bruce Fields 2012-07-06 11:03:44 EDT
Are you using krb5 authentication on either client?

What kernel version are you using on the rhel client?  (And what about the ubuntu client?)
Comment 10 Samuel Hug 2012-07-12 06:36:51 EDT
Since the update to 6.3 on the NFS Server and Client we have the same issue.

Downgrading the nfs-utils package on the 6.3 clients from nfs-utils-1.2.3-26.el6.x86_64.rpm to nfs-utils-1.2.3-15.el6_2.1.x86_64.rpm and rebooting the system "solves" the issue.

We do not have krb5 authentication in use.
Comment 11 Steve Dickson 2012-07-24 15:27:02 EDT
This is where the '123' uid is coming from... 
   -> the uid that is transmitted in the GETATTR reply call packet is '123'. 

Is the 123 a valid uid?
Comment 12 Joshua Weage 2012-08-06 13:17:59 EDT
I'm seeing the same behavior with 6.3 server and client.  The UID is valid on the client, but is mapped to "nobody".  On the server, the UID and GID are set correctly on the file.
Comment 13 Joshua Weage 2012-08-20 12:44:06 EDT
More information:  if the user account exists with the same UID and username on client and server, ID mapping works.  If the UID on the server is different than the client, the user name mapping doesn't work, but it looks like permissions are still working correctly.
Comment 14 tiagormartins 2012-09-14 08:40:12 EDT
More information ... I downgrade from nfs-utils-1.2.3-26.el6.x86_64.rpm to nfs-utils-1.2.3-15.el6_2.1.x86_64.rpm and rebooting the system but it does not work. 

nfs-utils-lib-1.1.5-4.el6.x86_64
nfs4-acl-tools-0.3.3-5.el6.x86_64
nfs-utils-1.2.3-15.el6_2.1.x86_64

Linux XYZXYZ 2.6.32-279.5.2.el6.x86_64 #1 SMP x86_64 x86_64 x86_64 GNU/Linux
Comment 15 J. Bruce Fields 2012-09-25 11:12:06 EDT
(In reply to comment #13)
> More information:  if the user account exists with the same UID and username
> on client and server, ID mapping works.  If the UID on the server is
> different than the client, the user name mapping doesn't work

UID's and GID's do have to be synchronized.

(The only exception is if you're using both kerberos and NFSv4, in which case numeric ID's aren't used on the wire any more.)
Comment 16 Akihiro Matsushima 2012-09-27 04:45:34 EDT
Samuel, I guess the following patch solves your problem:
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=fd27c638898010438d404cd17120729ef1d680e2

Temporary workaround is https://bugzilla.redhat.com/show_bug.cgi?id=829362#c15
Comment 17 Steve Dickson 2012-10-10 14:24:30 EDT
(In reply to comment #16)
> Samuel, I guess the following patch solves your problem:
> http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;
> h=fd27c638898010438d404cd17120729ef1d680e2
> 
> Temporary workaround is
> https://bugzilla.redhat.com/show_bug.cgi?id=829362#c15

Unfortunately this is not the case for the nfs-utils-1.2.3-15 (RHEL6.2)
release, since the nfsidmap command is not used. The following patch is needed 
for both RHEL6.2 and RHEL6.3:

diff -up nfs-utils-1.2.3/utils/idmapd/idmapd.c.orig nfs-utils-1.2.3/utils/idmapd/idmapd.c
--- nfs-utils-1.2.3/utils/idmapd/idmapd.c.orig	2012-10-10 11:23:46.229652000 -0400
+++ nfs-utils-1.2.3/utils/idmapd/idmapd.c	2012-10-10 13:36:31.164381000 -0400
@@ -836,7 +836,7 @@ nametoidres(struct idmap_msg *im)
 
 	switch (im->im_type) {
 	case IDMAP_TYPE_USER:
-		ret = nfs4_name_to_uid(im->im_name, &uid);
+		ret = nfs4_owner_to_uid(im->im_name, &uid);
 		im->im_id = (u_int32_t) uid;
 		if (ret) {
 			im->im_status = IDMAP_STATUS_LOOKUPFAIL;
@@ -844,7 +844,7 @@ nametoidres(struct idmap_msg *im)
 		}
 		return;
 	case IDMAP_TYPE_GROUP:
-		ret = nfs4_name_to_gid(im->im_name, &gid);
+		ret = nfs4_group_owner_to_gid(im->im_name, &gid);
 		im->im_id = (u_int32_t) gid;
 		if (ret) {
 			im->im_status = IDMAP_STATUS_LOOKUPFAIL;
Comment 18 Paul B Schroeder 2012-12-03 13:03:10 EST
(In reply to comment #17)
> (In reply to comment #16)
> > Samuel, I guess the following patch solves your problem:
> > http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;
> > h=fd27c638898010438d404cd17120729ef1d680e2
> > 
> > Temporary workaround is
> > https://bugzilla.redhat.com/show_bug.cgi?id=829362#c15
> 
> Unfortunately this is not the case for the nfs-utils-1.2.3-15 (RHEL6.2)
> release, since the nfsidmap command is not used. The following patch is
> needed 
> for both RHEL6.2 and RHEL6.3:
Steve..  FYI, I grabbed the nfs-utils source RPM and rebuilt it with this patch.  It did not alleviate the issue for me.
Comment 19 Steve Dickson 2013-01-29 14:38:05 EST
(In reply to comment #18)
> (In reply to comment #17)
> > (In reply to comment #16)
> > > Samuel, I guess the following patch solves your problem:
> > > http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;
> > > h=fd27c638898010438d404cd17120729ef1d680e2
> > > 
> > > Temporary workaround is
> > > https://bugzilla.redhat.com/show_bug.cgi?id=829362#c15
> > 
> > Unfortunately this is not the case for the nfs-utils-1.2.3-15 (RHEL6.2)
> > release, since the nfsidmap command is not used. The following patch is
> > needed 
> > for both RHEL6.2 and RHEL6.3:
> Steve..  FYI, I grabbed the nfs-utils source RPM and rebuilt it with this
> patch.  It did not alleviate the issue for me.
Then we are looking at a different problem.... The above patch does indeed work when the server send uid strings instead of name@domain strings... 

Please do this, open another bz with output from setting verbose=2 (in /etc/idmapd.conf)
Comment 20 Paul B Schroeder 2013-01-31 01:15:43 EST
(In reply to comment #19)
> (In reply to comment #18)
> > (In reply to comment #17)
> > > (In reply to comment #16)
> > > > Samuel, I guess the following patch solves your problem:
> > > > http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;
> > > > h=fd27c638898010438d404cd17120729ef1d680e2
> > > > 
> > > > Temporary workaround is
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=829362#c15
> > > 
> > > Unfortunately this is not the case for the nfs-utils-1.2.3-15 (RHEL6.2)
> > > release, since the nfsidmap command is not used. The following patch is
> > > needed 
> > > for both RHEL6.2 and RHEL6.3:
> > Steve..  FYI, I grabbed the nfs-utils source RPM and rebuilt it with this
> > patch.  It did not alleviate the issue for me.
> Then we are looking at a different problem.... The above patch does indeed
> work when the server send uid strings instead of name@domain strings... 
> 
> Please do this, open another bz with output from setting verbose=2 (in
> /etc/idmapd.conf)
The output doesn't look to be all the helpful.  But here it is per your request:
https://bugzilla.redhat.com/show_bug.cgi?id=906199
Comment 22 Steve Dickson 2013-03-07 11:32:57 EST
I'm the original problem is fixed by the nfs-utils-1.2.3-36

Please feel free to reopen is this not the a case...

Note You need to log in before you can comment on or make changes to this bug.