nfs4_disable_idmapping settings is not working as expected

SUSE Linux Enterprise Desktop SLED Configure-Administer
1

Hello All,

This is relevant to the SuSE TID 7014266 (https://www.suse.com/support/kb/doc/?id=7014266) , actually by default nfsv4 always send usernames instead of uid, for example if we run chown file the username should be sent to the NFS server.

We have a SUSE Linux Enterprise Server 11 Service Pack 2 but this solution does not work for me.
Actually I wanted to have the reverse thing of what TID is for, which mean, I want to send fqdn (usernames) while doing chown from the Suse Linux clients as I have the idmap on client and same mapping are accessed by NFS server as well. So I want to send username instead of uid. So I was trying to set the following but chown always send uid. even though I have the following setting

suselinux11:/home/15282 # echo 0 > /sys/module/nfs/parameters/nfs4_disable_idmapping
suselinux11:/home/15282 # cat /sys/module/nfs/parameters/nfs4_disable_idmapping
N

details :

from /proc/mounts

x.x.x.x:/nis_share/ /home/15282 nfs4 rw,relatime,vers=4,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=x.x.x.x,minorversion=0,local_lock=none,addr=x.x.x.x 0 0 <<<<<<< it is indeed version 4 of nfs.

suselinux11:/home # id adn1
uid=10006(adn1) gid=10000(domain users) groups=10000(domain users),10001(BUILTIN\users) <<< notice uid

I then ran chown with username to change file owner

suselinux11:/home/15282 # chown adn1 file1
suselinux11:/home/15282 # ll
total 136
-rw-r–r-- 1 adn1 root 0 Feb 23 05:47 file1 <<<<<<

I took network traces on client and in the set attribute I see the uid being sent instead of username even though I have nfs4_disable_idmapping is set to N which is 0.

suselinux11:/home/15282 # cat /sys/module/nfs/parameters/nfs4_disable_idmapping
N

from traces :

Opcode: SETATTR (34)
*** stateid
*** Attr mask: 0x00000010 (Owner)
******* reco_attr: Owner (36)
*********** fattr4_owner: 10006 <<<< uid of adn1
*************** length: 5
*************** contents: 10006 <<<
*************** fill bytes: opaque data

suselinux11:/home/15282 # cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 2

Can anyone please comment on what is wrong here ? Thanks in Advance.

2

adnanckm,

It appears that in the past few days you have not received a response to your
posting. That concerns us, and has triggered this automated reply.

These forums are peer-to-peer, best effort, volunteer run and that if your issue
is urgent or not getting a response, you might try one of the following options:

Be sure to read the forum FAQ about what to expect in the way of responses:
http://forums.suse.com/faq.php

If this is a reply to a duplicate posting or otherwise posted in error, please
ignore and accept our apologies and rest assured we will issue a stern reprimand
to our posting bot…

Good luck!

Your SUSE Forums Team
http://forums.suse.com

3

Hmmm… I agree with you that if “nfs4_disable_idmapping” is still at the default of 0 or N, that I’d expect to see names instead of numbers in the setattr parameters.

However, if you’ve been changing the value of the setting, keep in mind that a new value only comes into effect for a new mount. An existing mount (mounted while the setting was 1/Y) will continue to send UID# even if you change the setting to 0/N.

Another “gotcha” is that if idmapd (on the nfs client machine) has died, been killed, or was never started, that will cause UID# to be send instead of username@domain. Does “rcnfs status” report that idmapd is running? Or can you find it with “ps aux | grep idmapd”? In the days before NFSv4, even if you didn’t run “rcnfs start” and just did a mount manually, all was well, because the nfs client didn’t really rely on much else to be started first. But (at least on SLES 11 SP2, I didn’t try others) if you don’t run “rcnfs start” and just do a manual nfsv4 mount, the mount will succeed, but idmapd will not be running. And then you’ll get UID#s instead of names.

Today I tried chown on a SLES 11 SP2 nfsv4 clients – with nfs4_disable_idmapping set to 0/N, and idmapd running – and then checked with tcpdump/wireshark, and it did indeed send username@domain within the setattr, not the UID# of the user.

Darcy