NFSv4 : Linux client, Netapp Server -> Problem with id mapping

[davidmcgiven]

Dear Netapp Users,

I have a Linux client (ubuntu 8.04) that correctly mounts through NFSv3 an NFS share from a NetApp Filer (DataONTAP 7.2.1.1).

Due to firewall issues, I now need to use NFSv4 instead of v3. However, I'm having the problem of seeing all the files owned by nobody/nogroup.

Please, could anyone provide some advice ?

The command I'm using to mount it is :
mount -t nfs4 -o intr,proto=tcp filer:/vol/people /people/

These are the NetApp options :
nfs.v4.acl.enable            off
nfs.v4.enable                on
nfs.v4.id.domain             localdomain
nfs.v4.read_delegation       off
nfs.v4.write_delegation      off

The filer exports are :

/vol/people     -sec=sys,rw=machine1:machine2,root=master

In the linux box I've double checked that /etc/idmpad.conf domain is the same : "localdomain".

Just in case, I'm running the rpc.impad daemon on the linux client. This is the output for a single 'mount' and a single 'ls'

root@machine1:~# /usr/sbin/rpc.idmapd -vvvv -f
rpc.idmapd: libnfsidmap: using domain: localdomain

rpc.idmapd: libnfsidmap: using translation method: nsswitch

rpc.idmapd: Expiration time is 600 seconds.
rpc.idmapd: Opened /proc/net/rpc/nfs4.nametoid/channel
rpc.idmapd: Opened /proc/net/rpc/nfs4.idtoname/channel
rpc.idmapd: New client: 15
rpc.idmapd: Opened /var/lib/nfs/rpc_pipefs/nfs/clnt15/idmap
rpc.idmapd: New client: 16
rpc.idmapd: nss_getpwnam: name 'root@localdomain' domain 'localdomain': resulting localname 'root'

rpc.idmapd: Client 15: (user) name "root@localdomain" -> id "0"
rpc.idmapd: Client 15: (group) name "nobody" -> id "65534"
rpc.idmapd: nss_getpwnam: name 'nobody' domain 'localdomain': resulting localname '(null)'

rpc.idmapd: nss_getpwnam: name 'nobody' does not map into domain 'localdomain'

rpc.idmapd: Client 15: (user) name "nobody" -> id "65534"

Could someone please help me ? I'm puzzled because NFSv3 deals perfectly with user names and groups.

Well, Thanks.

Best,
David

[davidmcgiven]

This is strange because although in the Linux client all the files are listed as owned by nobody/nogroup, the permissions are actually working OK.

I.e : In the linux client I do "mkdir folder". Then "ls -ld folder". I see it's owned by nobody/nogroup.

Then I login in another Linux client that is mounting the same share with NFSv3 instead of NFSv4, and a "ls -ld folder" reveals the correct ownership.

I'm puzzled

[lovik_netapp · Accepted solution]

Hi David,

Have you tried configuring LDAP/NIS or local /etc/password file for UID to username mapping, as starting with NFSv4 the way UID and GIDs are exchanged and stored are changed therefore you need to have some kind of mapping in place for UID/GID.

Try looking in TR-3580 as it does have good explanation under 2.1 "LS –L LISTS THE OWNER AND GROUP AS NOBODY/NOBODY! WHY?"

Cheers,

[davidmcgiven]

Lovik,

Wonderful! Thank you very much! That TR condenses all the answers that I was looking for on the www during days!

And, I don't want to implement LDAP so I will have to populate the /etc/passwd file on the filer.

Apparently, this is an old discussion among unix users and also netapp developers on the implementation of NFSv4, having the UID/GID's passed as strings instead of numbers makes the transition from NFSv3 to NFSv4 painful and not as easy as it should be. Probably this is why NFSv4 is being adopted very slowly.

Best Regards

[davidgillies]

Can somebody please post the link to TR-3580 please? I've been searching all through NOW and all I'm getting hits to either TR (so every unrelated link) or 3580MA in the search results. What's the title of TR-3580?

Thanks

[lovik_netapp]

Looks like it's been pulled off from now site, anyway here you go.

http://dl.dropbox.com/u/6008738/NFSv4%20enhancements%20and%20Best%20Practices%20Guide%20tr-3580.pdf

[parisi]

TR-3580 should be accessible here:

http://www.netapp.com/us/system/pdf-reader.aspx?m=tr-3580.pdf

For additional NFSv4 with regards to clustered Data ONTAP:

http://www.netapp.com/us/system/pdf-reader.aspx?m=tr-4067.pdf