IDMAP in Mountain Lion as a NFSv4 Client
Hi all,
we are currently trying to setup new Mac Minis running Mountain Lion (10.8.3) in our student lab as NFSv4 clients. The server they should connect to is based on Solaris 11.1. It runs NFS, Kerberos (MIT) and OpenLDAP.
At first, we encountered the problems described in https://www.illumos.org/issues/3368 and in http://serverfault.com/questions/435716/setting-up-a-mac-mountain-lion-nfs-clien t-to-securely-access-debian-nfs-server/. NFSv4 access functioned in principle (but IDMAP didn't), but it was awfully slow (an "ls -l" in a NFS directory with about 20 entries took about 5 minutes). After some sniffing aroung with Wireshark, we recognized that the NFS server always answers the owner IDs and group IDs appended by the string @<our.domain.name> whenever the NFS client asked for them (when doing an "ls -l", for example). This is absolutely correct to the NFSv4 standard, but it remineded myself that we haven't set the NFSv4 domain name on the Mountain Lion clients, yet.
We then set the NFSv4 domain name using "dscl" as described in the man page of "opendirectoryd" of 10.8.3. After a reboot (most probably, restarting "opendirectoryd" and/or "gssd" would have been sufficient, too) the slowliness of NFSv4 was gone!
NFSv4 and Kerberos work... Almost...
What still doesn't work is the ID mapping: For all files on the NFS shares, I see the owner "nobody" (UID when doing "ls -ln": 4294967294 = 2^32 - 2) and the group "nobody" (GID same as UID) while our Mountain Lion clients are configured correctly to do LDAP lookups (i.e. the command "id" works and resolves LDAP usernames to LDAP user IDs and LDAP group names to LDAP group IDs). Since increasing the verbosity of the IDMAP part of NFS (by playing aroung with the sysctl variable
vfs.generic.nfs.client.idmap_ctrl| nfs4_id2guid: idmap failed for <nameOfGroup>@<our.domain.name> G error 2
| nfs4_id2guid: fallback map for <nameOfGroup>@<our.domain.name> G got guid abcdefab_cdefabcd_efabcdef_00000063
| nfs4_id2guid: idmap/fallback results differ for <nameOfGroup>@<our.domain.name> G - idmap error 2 fallback abcdefab_cdefabcd_efabcdef_00000063
| nfs4_id2guid: idmap failed for <myUsername>@<our.domain.name> error 2
| nfs4_id2guid: fallback map for <myUsername>@<our.domain.name> got guid ffffeeee_ddddcccc_bbbbaaaa_00000063
| nfs4_id2guid: idmap/fallback results differ for <myUsername>@<our.domain.name> - idmap error 2 fallback ffffeeee_ddddcccc_bbbbaaaa_00000063
According to [2], it seems that the IDMAP part of the NFS kernel module isn't able to lookup the Apple GUID of the files' groups and owners. After then, it tries some fallback mechanisms which don't work, either. As a result - all NFS files get "nobody:nobody" as owner and group IDs. Do I interpret that correctly?
I am aware that we didn't introduce the Apple GUIDs in our setup. They are neither stored in the user records nor in the group records in our LDAP directory. And we don't have a special IDMAP tree in our LDAP, either. Maybe we need all of these to get the correct owner and group resolution, but we also have Linux clients that use NFSv4 to connect to our Solaris server. There we've just stated our NFSv4 domain name in "/etc/idmapd.conf" and configured that for owner and group ID resolution the NSS environment should be used:
| [Translation]
| Method = nsswitch
My questions are: Isn't there any easy solution like this one in Mountain Lion to configure the NFSv4 IDMAP correctly? If that is not possible - what exactly to I have to store in our LDAP? I suppose that we need GUIDs for each group and user and a special IDMAP branch, but how does this have to look like? The same like the one which can be used for Samba like stated here?
Thank you very much for any help in advance!
Kind regards,
Steffen
[1] http://www.opensource.apple.com/source/xnu/xnu-2050.18.24/bsd/nfs/nfs.h
[2] http://www.opensource.apple.com/source/xnu/xnu-2050.18.24/bsd/nfs/nfs4_subs.c
