# rpc.idmapd not mapping

## awalker

After a kernel upgrade from 2.6 to 3.4 on one of my machines, rpc.idmapd no longer correctly maps names to IDs. Instead, the uid/gid for everything is 4294967294. I figured maybe I messed up with idmapd.conf. Nope, md5 is the same on all of the servers. I set the verbosity to 10, with the following being generated in syslog:

```
Jun 25 14:21:39 [rpc.idmapd] libnfsidmap: using domain: lan.nfs_

Jun 25 14:21:39 [rpc.idmapd] libnfsidmap: loaded plugin /usr/lib64/libnfsidmap/nsswitch.so for method nsswitch_

Jun 25 14:21:39 [rpc.idmapd] Expiration time is 600 seconds.

Jun 25 14:21:39 [rpc.idmapd] Opened /proc/net/rpc/nfs4.nametoid/channel

Jun 25 14:21:39 [rpc.idmapd] Opened /proc/net/rpc/nfs4.idtoname/channel

Jun 25 14:21:39 [rpc.idmapd] New client: 0

Jun 25 14:21:39 [rpc.idmapd] Opened /var/lib/nfs/rpc_pipefs//nfs/clnt0/idmap

Jun 25 14:21:39 [rpc.idmapd] New client: 12

Jun 25 14:21:39 [rpc.idmapd] New client: 19

Jun 25 14:21:39 [rpc.idmapd] New client: 32

Jun 25 14:21:39 [rpc.idmapd] New client: a

Jun 25 14:21:39 [rpc.idmapd] New client: d
```

I'm not sure what it's supposed to show, but based on other similar logs I've found, it's not showing any sort of query requests. Here's the config options from my kernel regarding d/inotify and nfs:

```
CONFIG_DNOTIFY=y

CONFIG_INOTIFY_USER=y

# CONFIG_FANOTIFY is not set

CONFIG_NFS_FS=y

CONFIG_NFS_V3=y

CONFIG_NFS_V3_ACL=y

CONFIG_NFS_V4=y

# CONFIG_NFS_V4_1 is not set

# CONFIG_ROOT_NFS is not set

# CONFIG_NFS_USE_LEGACY_DNS is not set

CONFIG_NFS_USE_KERNEL_DNS=y

CONFIG_NFSD=y

CONFIG_NFSD_V2_ACL=y

CONFIG_NFSD_V3=y

CONFIG_NFSD_V3_ACL=y

CONFIG_NFSD_V4=y

# CONFIG_NFSD_FAULT_INJECTION is not set

CONFIG_NFS_ACL_SUPPORT=y

CONFIG_NFS_COMMON=y
```

Lastly, the kernel/package info:

```
3.4.2-gentoo-r1 x86_64

nfs-utils-1.2.2-r2, then nfs-utils-1.2.6

libnfsidmap-0.24
```

Does anyone have any advice on how I can address this issue?

----------

## alex.blackbit

2.6 -> 3.4 is a big step.

did you update the rest of your system too?

glibc with current kernel headers comes to mind.

----------

## awalker

Everything updated in one go. Will try recompiling glibc.

Edit: Considering everything else runs without any displayed error before recompiling glibc, what all should I recompile after? The only symptom shown is idmapd not properly mapping.

Extra edit: Before creating this thread, I verified revdep-rebuild -i, perl-cleaner, and python-updater showed nothing out of the ordinary.

----------

## kimmie

The reason you are seeing no activity from rpc.idmapd is that in kernel 3.4 and above, the default is to disable the id mapper when you use nfs4 and sec=sys.

Reading the doco, it looks like sec=sys and the id mapper can be used to correctly map uid/gid to name where the client and server have different mappings in /etc/passwd and /etc/group. This simply isn't true.

That's because with sec=sys the id mapper doesn't come into play in the authentication part of the nfs protocol, only the file attributes part. With sec=sys authentication, nfs just passes the client uid/gid which is used directly by the server. So permissions checks will be screwed if client and server uid and gid don't align. To confuse things further, when the client creates a new file it is the authentication credentials that are used, so the file gets created at the server with the client's uid/gid. After that nfs uses idmap to get the file attributes, so the uid/gid (which originally came from the client) gets mapped at the server, and you end up seeing the server's name for a client uid/gid. Borkage! On the other hand, if the file was originally created at the server, you will see the correct name at the client, even if the uid/gid differs. But permissions checking will still be broken.

If you want to see this for yourself, you can re-enable id mapping; it is controlled by the nfs4_disable_idmapping module parameter on the client and server modules:

```
$ # at the client (module is nfs)

$ echo N | sudo tee /sys/module/nfs/parameters/nfs4_disable_idmapping

$ # at the server (module is nfsd)

$ echo N | sudo tee /sys/module/nfsd/parameters/nfs4_disable_idmapping
```

Anyway, the upshot of this is that id mapping doesn't won't do what you expect it to unless the uid/gid is the same at the client and server. In which case you don't need id mapping, and that's why it is disabled by default.

Note that when you are using kerberos (sec=krb?), it's the kerberos tokens and not the uid/gid that get passed in the authentication part of the protocol. These do get correctly mapped, hurrah.

I could find no good links which completely explained the situation, lots of googling, searching the nfs newsgroup archive on gmane, looking at the NFS protocol specs and finally using wireshark to look at the NFS view of creating a file from the client is what convinced me of all this.

----------

