Bug 829362 - wrong username/domain passed in nfs4 attribute requests
Summary: wrong username/domain passed in nfs4 attribute requests
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: 17
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Fedora Extras Quality Assurance
: 829344 852449 (view as bug list)
Depends On:
Blocks: 892194
TreeView+ depends on / blocked
Reported: 2012-06-06 14:42 UTC by Enrico Scholz
Modified: 2013-04-22 23:59 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 892194 (view as bug list)
Last Closed: 2012-12-20 15:54:29 UTC
Type: Bug

Attachments (Terms of Use)
Call nfs4_init_name_mapping() before getting the default domain (780 bytes, patch)
2012-07-02 09:15 UTC, Roland Hermans
no flags Details | Diff

Description Enrico Scholz 2012-06-06 14:42:46 UTC
Description of problem:

An operation like 'chown' creates requests which do not respect the settings in /etc/idmapd.conf.  E.g. my /etc/idmapd.conf is

Verbosity = 0

Nobody-User  = nobody
Nobody-Group = nobody

Method = nsswitch

Userspace uid/gid translation is done by nslcd (LDAP).  When there is done

 chown 505 ~/foo

an SETATTR request with an FATTR4_OWNER of 'ensc@intern.sigma-chemnitz.de' is issued.  Because the NFS4 domain is SIGMA-CHEMNITZ.DE, this operation will fail.

Strange thing is, that rpc.idmapd will be called for unknown (--> nobody mapping) users only.  E.g. 'strace -f -p <pidof-idmapd>' shows no activity for 'chown <valid-uid>' operations but for invalid uids only.  Adding '-vv' flags in /etc/request-key.d/id_resolver.conf shows expected data (only 'ensc@SIGMA-CHEMNITZ.DE, no 'ensc@intern.sigma-chemnitz.de').

GETATTR responses from the server are containing expected owner values like 'ensc@SIGMA-CHEMNITZ.DE' which are mapped correctly on the client.

Server is an RHEL6 machine, client an F17 one (F16 was fine). Shares are mounted by 

...:/home/ /home nfs4 comment=systemd.automount,exec,nodev,nosuid,rw,sec=krb5i,posix,nointr

Client's domainname is 'intern.sigma-chemnitz.de'.

Version-Release number of selected component (if applicable):


Comment 1 Enrico Scholz 2012-06-06 14:46:17 UTC
*** Bug 829344 has been marked as a duplicate of this bug. ***

Comment 2 Enrico Scholz 2012-06-07 11:26:41 UTC
/proc/keys seems to be filled with the wrong value:

| 3a94f691 I--Q--     1 perm 3f050000     0     0 id_resolv user:505: 29

I assume, the '29' at the end is the length of the incorrect 'ensc@intern.sigma-chemnitz.de' string.

Problem seems to be in /usr/sbin/nfsidmap which ignores 'Domain' setting in /etc/idmapd.conf and appends always the local dns domain name instead of the configured NFS4 domain name.

Comment 3 Enrico Scholz 2012-06-07 11:56:55 UTC
nfsidmap.c seems to miss a call to nfs4_init_name_mapping() which reads the configuration file.

Comment 4 Enrico Scholz 2012-06-07 12:10:19 UTC
call path is:

# nfsidmap <serial> user:<uid>

name_lookup(...) {
  nfs4_get_default_domain(..., domain, ...)    --->  libnfsidmap not initialized;
                                                     assumes local dns domain
  nfs4_uid_to_name(uid, domain) {
       nfs4_init_name_mapping(NULL);     --->  too late; domain is determined
       ... resolve uid ...
       ... append 'domain' ...

Instead of calling nfs4_init_name_mapping() within nfsidmap; the nfs4_get_default_domain() function from libnfsidmap can be modified to lazy call nfs4_init_name_mapping(NULL).

Comment 5 Enrico Scholz 2012-06-14 12:03:31 UTC
can we fix this please?  It breaks a lot of things.

Comment 6 Michal Žejdl 2012-06-27 19:37:17 UTC
Simillar problem here. F17 client, F14 server, NFS4 share /archiv:

[root@amanda ~]# LANG=C chown michal /archiv/eee
chown: changing ownership of `/archiv/eee': Remote I/O error

server messages:
server rpc.idmapd[8479]: nss_getpwnam: name '500' does not map into domain 'trodevci.cz'

tshark - F17 client (chown as root failed)

        Opcode: SETATTR (34)
                seqid: 0x00000000
                Data: 000000000000000000000000
                    recc_attr: FATTR4_OWNER (36)
                        fattr4_owner: 500
                            length: 3
                            contents: 500
                            fill bytes: opaque data

tshark - F14 client (chown as root works fine)

        Opcode: SETATTR (34)
                seqid: 0x00000000
                Data: 000000000000000000000000
                    recc_attr: FATTR4_OWNER (36)
                        fattr4_owner: michal@trodevci.cz
                            length: 18
                            contents: michal@trodevci.cz
                            fill bytes: opaque data

I tried to tweak /etc/request-key.conf and /etc/request-key.d/id_resolver.conf according to man nfsidmap, but without success.

I am using NIS via IPv4 and NFS4 via IPv6. F17 is broken for me - I can not start pulseaudio over NFS /home (Failed to create secure directory: Remote I/O error), libnotify is failing, Rhythmbox segfaults, I can not get lock for FPM2...

Comment 7 Enrico Scholz 2012-06-27 23:55:11 UTC

Index: nfs-utils-1.2.6/utils/nfsidmap/nfsidmap.c
--- nfs-utils-1.2.6.orig/utils/nfsidmap/nfsidmap.c
+++ nfs-utils-1.2.6/utils/nfsidmap/nfsidmap.c
@@ -285,6 +285,10 @@ int main(int argc, char **argv)
        if (!verbose) {
                verbose = get_config_verbose(PATH_IDMAPDCONF);
+       if (nfs4_init_name_mapping(conf_path))
+               xlog_err(1, "Unable to create name to user id mappings.");
        if (keystr) {
                rc = key_revoke(keystr, keymask);
                return rc;

fixes problem for me.

Comment 8 Roland Hermans 2012-07-02 09:15:41 UTC
Created attachment 595682 [details]
Call nfs4_init_name_mapping() before getting the default domain

I am observing the same problem as Enrico with an NFS client running Fedora 17. The man page of nfs4_uid_to_name contains the following text:

    The  nfs4_init_name_mapping()  function must be called before using any
    of these functions.  It reads defaults from the configuration  file  at
    the provided path, usually "etc/idmapd.conf".

There is no explicit mentioning of calling nfs4_init_name_mapping() before nfs4_get_default_domain(). As suggested in comment 4 the implementation of nfs4_get_default_domain() could be modified to lazy call nfs4_init_name_mapping() and the alternative is to modify nfsidmap.c as shown in comment 7.

However the diff proposed in comment 7 didn't work for me since my nfs-utils 1.2.6 source doesn't contain a conf_path variable. Therefore I have made this alternative patch which can be applied to nfs-utils-1.2.6-0.fc17.src.rpm

Comment 9 Roland Hermans 2012-07-02 09:39:16 UTC
Michal, the problem you describe in comment 6 is *not* related to the original problem description. In your case the uid is not translated to a name and passed as a number to the NFS server. The kernel parameter nfs.nfs4_disable_idmapping controls whether or not translation of uid/gid to name is done for NFSv4 filesystems with "sys" security. You can check the security of a mounted filesystem with mount and then look for the sec= option.

A few months ago the default value of this kernel parameter was changed. See http://comments.gmane.org/gmane.linux.nfs/46028 for the announcement. At least the 3.4.x kernels of Fedora 16 and 17 have nfs4_disable_idmapping enabled by default.

To get the same behavior as on your F14 client create a <name>.conf file in /etc/modprobe.d (e.g. /etc/modprobe.d/trodevci.conf) containing the following line:

options nfs nfs4_disable_idmapping=n

After a reboot uid to name mapping should be working on the client. And if your DNS domain name is different from the NFSv4 domain name you will then stumble upon the problem that is in the original problem description ;-).

Comment 10 Michal Žejdl 2012-07-02 19:13:26 UTC
Roland, thank you for clarification. I forgot to check modinfo nfs. Some of my F17 problems are solved now, some still persist, but this problem do not affect me. Sorry for noise.

Comment 11 Fedora Update System 2012-07-10 13:58:01 UTC
nfs-utils-1.2.6-4.fc17 has been submitted as an update for Fedora 17.

Comment 12 Fedora Update System 2012-07-11 23:52:52 UTC
Package nfs-utils-1.2.6-4.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing nfs-utils-1.2.6-4.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 13 oll 2012-08-07 10:25:31 UTC
It really look like the same issue as the bug I filled here :

Unfortunatly, this nfs-utils update doesn't solve the problem for me. The nfs4 client keeps on sending loginname@dnsname instead of loginname@realmdomain for setattr (using wireshark) despite a right loginname@realdomain in /proc/keys

Comment 14 Enrico Scholz 2012-08-13 08:55:23 UTC
Despite the changelog entries, nfs-utils-1.2.6-4.fc17 does *not* contain the required patch.

In master branch, it was added by the -rc3 patch but a similar one is missing for F17 + RHEL6.

Comment 15 Enrico Scholz 2012-08-20 16:15:23 UTC
Temporary workaround:

# rm -f /etc/request-key.d/id_resolver.conf
# nfsidmap -c
# systemctl start nfs-idmap.service

Comment 16 Enrico Scholz 2012-08-23 09:41:00 UTC
Steve, what is the reason that this bug report is completely ignored by you?   Issue is completely analyzed, patch exists and is applied upstream, issue breaks a lot of things and nfs is mission-critical.

Comment 17 oll 2012-08-27 11:01:50 UTC
Indeed, applying manually Enrico's patch solves this problem and all other side effects it implied (https://bugzilla.redhat.com/show_bug.cgi?id=846042)

Comment 19 Arif Saleem 2012-09-21 09:53:40 UTC
I'm using F17 x86_64 clients with CentOS 6.3 Server, and NFS4 home directories.
I'm not using LDAP - just local /etc/passwd files which are manually kept in sync with the accounts on the server (we only have 8 users).
Previously, I was using F17 on the server aswell and didn't have any problems. Since switching to CentOS 6.3 on the server we are having quite a bit of instability on the clients : pulseaudio won't start, empathy seems to cause random hangs and gnome-shell randomly freezes. I tried updating to nfs-utils-1.2.6-4.fc17 from updates-testing but that hasn't helped. My next step is to try rebuilding nfs-utils with Enrico's patch above. Just wanted to ask if anyone has already built a patched RPM that I could use?
Also, what is the way forward with this issue - just wondering what to look out for? TIA.

Comment 20 Arif Saleem 2012-09-21 20:51:15 UTC
I recompiled nfs-utils using Enrico's patch, and pulseaudio now works on my F17 Client Workstations! Thanks Enrico. If anyone else has use for the rpm :

Comment 21 Steve Dickson 2012-10-14 16:59:02 UTC
*** Bug 852449 has been marked as a duplicate of this bug. ***

Comment 22 Fedora Update System 2012-10-15 02:42:50 UTC
nfs-utils-1.2.6-5.fc17 has been submitted as an update for Fedora 17.

Comment 23 Fedora Update System 2012-10-15 23:32:26 UTC
Package nfs-utils-1.2.6-5.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing nfs-utils-1.2.6-5.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 24 M.T 2012-11-28 08:54:27 UTC
What about centos and redhat update release?

We have setup a centos 6.3 nfsv4 with dnsdomainname=in.ab.cd.ac.cy. WE have many nfs clients  (centos 6.3) some with dnsdomainname=in.ab.cd.ac.cy and some with dnsdomainname=ab.cd.ac.cy. I have setup the in /etc/idmapd.conf the domain variable to be ab.cd.ac.cy . Our users log on the clients with  their ldap accounts. User mapping works well , since the mapping on the user´s home directories served by nfs server, is corrected when users are logging on the clients. However I have noticed the following errors in server´s /var/log/messages files:
hermes rpc.idmapd[1715]: nss_getpwnam: name 'userx@in.ab.cd.ac.cy' does not map into domain 'ab.cd.ac.cy'
I run the tcpdump on the nfs server and among others I get the following :
10:38:21.950027 IP > 144 getattr fh 0,0/22
10:38:21.950071 IP > reply ok 240 getattr NON 3 ids 0/3 sz 0
10:38:21.950258 IP > 232 getattr fh 0,0/22
10:38:21.950301 IP > reply ok 60 getattr ERROR: No such file or directory
10:38:21.950587 IP > 156 getattr fh 0,0/22
10:38:21.950630 IP > reply ok 272 getattr NON 4 ids 0/15 sz 0
10:38:21.950793 IP > 136 getattr fh 0,0/22
10:38:21.950845 IP > reply ok 224 getattr NON 2 ids 0/9 sz 0
10:38:21.951011 IP > 224 getattr fh 0,0/22
10:38:21.951051 IP > reply ok 64 getattr ERROR: unk 10039
10:38:21.951199 IP > 176 getattr fh 0,0/22

Running the command rpc.idmapd -fvvvvvvvvvv on the nfs client (centos 6.3) I got the following:

rpc.idmapd: libnfsidmap: using domain: ab.cd.ac.cy
rpc.idmapd: libnfsidmap: Realms list: 'AB.CD.AC.CY'
rpc.idmapd: libnfsidmap: processing 'Method' list
rpc.idmapd: libnfsidmap: loaded plugin /usr/lib64/libnfsidmap/nsswitch.so for method nsswitch

rpc.idmapd: Expiration time is 600 seconds.
rpc.idmapd: nfsdopenone: Opening /proc/net/rpc/nfs4.nametoid/channel failed: errno 2 (No such file or directory)
rpc.idmapd: New client: 18
rpc.idmapd: Opened /var/lib/nfs/rpc_pipefs//nfs/clnt18/idmap
rpc.idmapd: New client: 1b
rpc.idmapd: New client: 1d
rpc.idmapd: New client: 1e

and these also if I execute the command ls -l on the nfs share

rpc.idmapd: nss_getpwnam: name 'userx@ab.cd.ac.cy' domain 'ab.cd.ac.cy': resulting localname 'userx'

rpc.idmapd: nfs4_name_to_uid: nsswitch->name_to_uid returned 0

rpc.idmapd: nfs4_name_to_uid: final return value is 0

rpc.idmapd: Client 18: (user) name "userx@ab.cd.ac.cy" -> id "2765"
rpc.idmapd: nfs4_name_to_uid: calling nsswitch->name_to_uid

I suspect that this is the same error as mentioned by Encrico on comment #1

Comment 25 Fedora Update System 2012-12-20 15:54:32 UTC
nfs-utils-1.2.6-4.fc17 has been pushed to the Fedora 17 obsolete repository.  If problems still persist, please make note of it in this bug report.

Comment 26 M.T 2012-12-28 13:34:48 UTC
I'm sorry if this is an obvious question - but will be an update also for centos? Do I have to report this as a new bug especially for Centos?

Comment 27 Ian Pilcher 2012-12-28 14:08:22 UTC
(In reply to comment #26)
> I'm sorry if this is an obvious question - but will be an update also for
> centos? Do I have to report this as a new bug especially for Centos?

This question is best asked on a CentOS mailing list:


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