Bug 823848
Summary: | NFSv4 idmapper maps files to user nobody | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Ralf Wagner <ralf_wagner1> |
Component: | nfs-utils | Assignee: | Steve Dickson <steved> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Red Hat Kernel QE team <kernel-qe> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.2 | CC: | 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
What version of nfs-utils are you using? 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 (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? 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. 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. We appear to be seeing this from recent Fedora 16 kernels. See bug #837998 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. Are you using krb5 authentication on either client? What kernel version are you using on the rhel client? (And what about the ubuntu client?) 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. 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? 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. 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. 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 (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.) 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 (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; (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. (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) (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 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... |