3

I have a Mac OS X file server that serves via SMB/CIFS and AFP. The server is a domain client via the golden triangle approach, but this results in a very large UID for the users. This is fine for my current setup, but I'd like to get NFS working as well. Obviously I need to do some UID mapping, but I'm not sure how to go about doing this. Any advice?

churnd
  • 3,977
  • 5
  • 33
  • 41
  • 1
    I'm not sure why you obviously need to do some UID mapping? Are the UIDs too big for NFS to use? or is consistency the problem? or? – Kamil Kisiel Jun 04 '09 at 19:54
  • 1
    The UIDs vary from client to server systems. Rather than going around and changing them all and suffering the possible unforseen consequences of doing that, I wanted to consider mapping them first. – churnd Jun 04 '09 at 19:57
  • Don't the UIDs, come from one of the directory servers (AD or OD)? Why would you need to change the UID on the client? – Zoredache Jun 04 '09 at 21:49
  • No, we have AD with no unix attributes, so the golden triangle approach on OS X generates a very large random number based on the GSUID (or something like that): http://www.bombich.com/mactips/activedir.html. Also, the unix clients aren't part of AD. I don't have admin rights on the AD domain so I don't want to join the unix clients to it. Hence, the need to do mapping. – churnd Jun 05 '09 at 15:22

4 Answers4

7

In most NFSv3 implementations, particularly kernel-level servers, this isn't possible apart from some limited mappings like root to nobody. In NFS v4 you have rpc.idmapd which performs the NFSv4 ID <-> UID mapping on the server and allows you to get more flexible.

If you can't use NFSv4, the recommended way to deal with it for NFSv3 is to have your users come from a directory service such as LDAP, or another common database. Typically all the system users for daemons etc. will come from /etc/passwd while all the human users come from an external source. This will ensure consistent UIDs across the board and eliminate the need for any kind of mapping.

Kamil Kisiel
  • 11,946
  • 7
  • 46
  • 68
  • I figured that would be the case. However, my NFSv4 experience is limited. It seems that most people are hesitant to adopt it. Not really sure why. – churnd Jul 06 '09 at 13:46
3

Well, after further research, I've found that nfs-user-server will allow you to do this sort of mapping. It's kind of a bummer, because the main reason I wanted to use NFS over CIFS was speed. nfs-user-server runs in userspace, so it's not as fast as nfs-kernel-server. Doesn't seem to be a optimal solution.

churnd
  • 3,977
  • 5
  • 33
  • 41
3

I want to add that there's a major gotcha to NFSv4's UID mapping approach (see Kamil's comment): It doesn't work for AUTH_SYS / AUTH_UNIX authentication, which is what you have if the different computers aren't using LDAP or Kerberos or some other shared access control system.

Here's the rub: NFSv4 will use textual (that is, non-numeric) IDs when describing file ownership across the wire, which is what you think you want, but the RPC layer still uses numeric UID and GID values. Simple AUTH_SYS authentication punts back to RPC, and then you're stuck again. Here's an example of what this looks like (tshark capture of client->server packet, captured on the server side):

Frame 26 (306 bytes on wire, 306 bytes captured)
...
Remote Procedure Call, Type:Call XID:0x2790a46d
...
    Credentials
        Flavor: AUTH_UNIX (1)
        Length: 48
        Stamp: 0x00419c55
        Machine Name: localhost.localdomain
            length: 21
            contents: localhost.localdomain
            fill bytes: opaque data
        UID: 500
        GID: 500
        Auxiliary GIDs
        GID: 500
    Verifier
        Flavor: AUTH_NULL (0)
        Length: 0
Network File System
...
Eric Anderson
  • 161
  • 4
0

I haven't configured it on OSX, but what you're looking for is called idmapd. On an OSX box, the daemon is actually called rpc.idmapd. (Note: NOT imapd.)

Karl Katzke
  • 2,596
  • 1
  • 21
  • 24