Kerberized NFS on Mac - clhedrick/kerberos GitHub Wiki
Return to main: Kerberos
The Mac supports Kerberized mounts for v3 and v4. They mostly just work. Obviously you need /etc/krb5.conf and a key table for your host in /etc/krb5.keytab.
Other than that, here are some notes:
- Error messages on mount have nothing to do with the cause.
- By default they use a user port to communicate with the server. If you have "insecure" on the server, that's fine. If not, add resvport to the mount options.
- If things fail, it may take a couple of minutes before a retry might work. Also, after a umount, immediate attempt to mount will fail, with obscure error messages about RPC service not found.
- You will need valid /etc/krb5.conf and /etc/krb5.keytab.
- As a user, kinit so you have a valid credential cache. I used default_cc_name = /tmp/krb5cc_%{uid}, so my credentials went into a /tmp file. I don't know how many different locations their NFS server checks.
- If you are using two factor authentication, you'll need the MIT Kerberos clients. I used the "kerberos5" package from Macports. I have a copy of kgetcred built it, which you'll need to get the initial ticket for 2FA. I have a Mac version of skinit using these tools.
- Here's a v4 mount: mount -t nfs -o vers=4,sec=krb5 c217-nfs.cs.rutgers.edu:/home /mnt. With Linux, the client finds out from the server that it needs to use Kerberos, and it mounts with the highest available version. Mac doesn't seem to do that.
- For V4 to work, idmapping must be working. To set it up, you must tell the system your Kerberos domain, dscl . -create Config/NFSv4Domain RealName CS.RUTGERS.EDU
- You can specify v3, obviously. With V3 your uids and gids need to be synchronized with the server. At least the ones you care about, which is probably just your own user.
- Root can access any file for which there are currently valid Kerberos credentials. That's not the case on Linux, though obviously root can su to the user and access files.
- I recommend telling spotlight not to index the mounts. I was unable to get it to accept the actual mount point, so I exempted /exports
- Failures aren't necessarily on the Mac side. I had a failure with a Centos file server which turned out to be on the Linux end. I had to restart the Linux system. I beieve the issue was the spotlight was trying to index the drive, and the Kerberos ticket had expired. The server should just give an error, but it seems to have run out of file descriptors. The issue did not occur with a Centos 6 server mounted with version 3.
I was able to do a mount from home through
ssh -L2049:c217-nfs.cs.rutgers.edu:2049 [email protected]
We have the Kerberos web proxy set up, so ssh only has to forward the NFS traffic. krb5.conf has
kdc = https://services.cs.rutgers.edu/KdcProxy"
The mount is then
sudo mount -o nocallback,vers=4,sec=krb5,proto=tcp,port=2049 c217-nfs.cs.rutgers.edu:/home /mnt
(localhost if you're at home using the ssh proxy)
For the mount it appears to use [email protected], not the machine principal, so it looks like krb5.keytab isn't needed.
Without setting both ports it seems to try to use rpcbind. I had continuing issues with that. There still may be issues if I try to replicate this. The error connection refused seems to be due to port 111. NFS 4 has the server callback the client in some locking situations. nocallback disables that. NFS 4.1 avoids the callback, but it looks like OSX doesn't support 4.1.