Bug 829362

*** Bug 829344 has been marked as a duplicate of this bug. ***

/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.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.

nfsidmap.c seems to miss a call to nfs4_init_name_mapping() which reads the configuration file.

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
                                               above
       ... 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).

can we fix this please?  It breaks a lot of things.

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)
            stateid
                seqid: 0x00000000
                Data: 000000000000000000000000
            obj_attributes
                attrmask
                    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)
            stateid
                seqid: 0x00000000
                Data: 000000000000000000000000
            obj_attributes
                attrmask
                    recc_attr: FATTR4_OWNER (36)
                        fattr4_owner: michal
                            length: 18
                            contents: michal
                            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...

trivial

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.

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

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 ;-).

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.

nfs-utils-1.2.6-4.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/nfs-utils-1.2.6-4.fc17

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:
https://admin.fedoraproject.org/updates/FEDORA-2012-10532/nfs-utils-1.2.6-4.fc17
then log in and leave karma (feedback).

It really look like the same issue as the bug I filled here :
https://bugzilla.redhat.com/show_bug.cgi?id=846042

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

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.

Temporary workaround:

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

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.

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)
Thx.

Hi
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.

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 :
http://arif.easyss.net/rpms/nfs-utils-1.2.6-4.1.fc17.x86_64.rpm

*** Bug 852449 has been marked as a duplicate of this bug. ***

nfs-utils-1.2.6-5.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/nfs-utils-1.2.6-5.fc17

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:
https://admin.fedoraproject.org/updates/FEDORA-2012-16174/nfs-utils-1.2.6-5.fc17
then log in and leave karma (feedback).

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.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 10.16.13.217.974009862 > 10.16.1.23.2049: 144 getattr fh 0,0/22
10:38:21.950071 IP 10.16.1.23.2049 > 10.16.13.217.974009862: reply ok 240 getattr NON 3 ids 0/3 sz 0
10:38:21.950258 IP 10.16.13.217.990787078 > 10.16.1.23.2049: 232 getattr fh 0,0/22
10:38:21.950301 IP 10.16.1.23.2049 > 10.16.13.217.990787078: reply ok 60 getattr ERROR: No such file or directory
10:38:21.950587 IP 10.16.13.217.1007564294 > 10.16.1.23.2049: 156 getattr fh 0,0/22
10:38:21.950630 IP 10.16.1.23.2049 > 10.16.13.217.1007564294: reply ok 272 getattr NON 4 ids 0/15 sz 0
10:38:21.950793 IP 10.16.13.217.1024341510 > 10.16.1.23.2049: 136 getattr fh 0,0/22
10:38:21.950845 IP 10.16.1.23.2049 > 10.16.13.217.1024341510: reply ok 224 getattr NON 2 ids 0/9 sz 0
10:38:21.951011 IP 10.16.13.217.1041118726 > 10.16.1.23.2049: 224 getattr fh 0,0/22
10:38:21.951051 IP 10.16.1.23.2049 > 10.16.13.217.1041118726: reply ok 64 getattr ERROR: unk 10039
10:38:21.951199 IP 10.16.13.217.1057895942 > 10.16.1.23.2049: 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.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.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

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.

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?

(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:

  http://www.centos.org/modules/tinycontent/index.php?id=16