Bug 823848

Summary: NFSv4 idmapper maps files to user nobody
Product: Red Hat Enterprise Linux 6 Reporter: Ralf Wagner <ralf_wagner1>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED CURRENTRELEASE QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.2CC: akihiro.matsushima, bfields, chuck, devurandom, gbailey, jonabbey, joshua.weage, paulbsch, rrajaram, shug, tiagormartins, toracat, villapla
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-07 16:32:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 855416, 855417    
Bug Blocks:    

Description Ralf Wagner 2012-05-22 10:10:18 UTC
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 12:07:12 UTC
What version of nfs-utils are you using?

Comment 3 Ralf Wagner 2012-05-22 13:14:14 UTC
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 12:22:52 UTC
(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 16:01:09 UTC
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 Program Management 2012-05-26 16:03:26 UTC
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 05:37:01 UTC
We appear to be seeing this from recent Fedora 16 kernels.  See bug #837998

Comment 8 Jonathan Abbey 2012-07-06 14:51:11 UTC
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 15:03:44 UTC
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 10:36:51 UTC
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 19:27:02 UTC
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 17:17:59 UTC
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 16:44:06 UTC
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 12:40:12 UTC
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 15:12:06 UTC
(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 08:45:34 UTC
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 18:24:30 UTC
(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 18:03:10 UTC
(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 19:38:05 UTC
(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 06:15:43 UTC
(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 16:32:57 UTC
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...