Information for Mac OS X users
Accessing NetApp filespace
Your normal file space held on the departmental NetApp file server can be accessed directly from Mac OS X whilst your computer is physically within the building (or via VPN). Access is permitted from the network on which unmanaged machines are connected and the local wireless network.
To access the lab filespace you must have a valid login (Kerberos password) for using lab-managed Linux or Windows machines.
You can choose between two ways of accessing the filer:
- SMB/CIFS protocol – Behaves very much like access from Windows, in particular most files you create will be managed by the filer using Windows NTFS-style access controls. Symbolic links created under Unix/Linux will not be recognizeable as such, but mandatory locking is available. This option may be preferable for anyone who mostly collaborates with Windows users.
- NFSv3 protocol – Behaves more like lab-managed Unix/Linux. Files created will have Unix-style access control permissions (see “man chmod”), symbolic links are fully supported, and the protocol is very fast on LANs. This option may be preferable for anyone who mostly collaborates with Unix/Linux users, or uses their Mac commonly from the shell command-line.
The NFSv4 protocol tries to combine the best of both worlds, but is currently disabled on the filer.
Access via SMB/CIFS
Start the “Finder” and select the menu item “Go | Connect to Server ...” and then type in as the “Server Address:” the required folder that you want to mount.
Example mount points:
- To mount your windows_home:
- To mount your unix_home:
- To mount your “super home” (contains both of the above):
- To mount your group space
The “userid@” prefix is not needed if the login name on your Mac is already your CRSID.
In versions of OS X prior to Lion
You need to know which volume you are on – something like homes-3. Please note that the actual volume your files are stored on may change without notice so if a mount fails please check that your files are still on the same volume before reporting a fault. Mount smb://firstname.lastname@example.org/homes-N, where N is the location of your home directory and browse down to your files. You will then be presented for your credentials.
Only one uid/password mapping is permitted by CIFS/SMB per host connection. It is therefore sensible to add this to your keychain to simplify future access.
The Mac OS X SMB method will only mount explicit mountpoints provided by our fileserver, there is no auto-mount facility available here so you cannot use the userfiles mapping to reach your files.
Access via NFS
Access via NFS is currently only available from within the Computer Laboratory, and requires a connection to a suitable local network, (e.g. VLAN 290).
Create the file /etc/krb5.conf and fill it as follows:
[libdefaults] default_realm = AD.CL.CAM.AC.UK allow_weak_crypto = true [domain_realm] .cl.cam.ac.uk = AD.CL.CAM.AC.UK
- The default_realm setting just avoids that you have to type crsid@AD.CL.CAM.AC.UK at each invocation of kinit.
- The allow_weak_crypto=true is unfortunately still necessary because, at the moment, the only encryption scheme that both the filer and OS X manage to agree on is des-cbc-crc, using weak 56-bit DES encryption keys. OS X 10.9 appears to support only des-cbc-crc, des-cbc-md5, des-cbc-md4, and des3-cbc-sha1 as encryption types for NFS session keys, whereas our Active Directory server only supports aes256-sha1, aes128-sha1, des-cbc-crc, des-cbc-md5, arcfour-hmac-md5. Therefore, allow_weak_crypto=true will be necessary until Apple finally supports AES or RC4 session keys in its NFS implementation.
- The domain_realm entry is not strictly necessary, as our DNS servers provide equivalent information (try “host -t txt _kerberos.cl.cam.ac.uk”), but it helps to avoid one “gssd: No credentials found for CL.CAM.AC.UK” warning in /var/log/system.log.
To access the filer, you need to get a fresh Kerberos ticket using your password. They last about a day by default. If you did not already get a ticket during your last Kerberos-authenticated login, you can request one manually via the shell command line
$ kinit crsid crsid@AD.CL.CAM.AC.UK's Password: [type your Kerberos password]
Note: An added benefit of having a Kerberos ticket is that SMB mount's will no longer require a password, and neither will logins with “ssh -K” to lab-managed Linux machines.
Mounting a directory
Once Kerberos is set up and you have a ticket, just create an empty directory as a mount point and then mount the desired export. You can do this under your normal user identity in your home directory (no sudo required).
$ mkdir cl-filer $ mount filer.cl.cam.ac.uk:/vol/userfiles/crsid cl-filer
NFSv3 communicates only numeric user and group identifiers, therefore if you type “ls -l” in a mounted folder, you may see the owner and group to which a file belongs displayed as integer numbers (e.g., “1597” instead of “mgk25”), because these numeric user identifiers will not exist in the local user and group directory of OS X.
To help OS X Directory Services to translate numeric user and group identifiers into user and group names, you have to configure it to consult a departmental Unix LDAP server.
The following steps have been tested by Markus Kuhn on OS X 10.9.4:
- Under “(Apple)|System Preferences|Users & Groups” click on “Login Options”. Then click the padlock symbol and unlock it with your admin password.
- Next to “Network Account Server:” click “Join...” and then on the menu that pops up “Open Directory Utility...”.
- In the Directory Utility, again open the padlock using your admin password. Under “Services” double-click “LDAPv3” and on the menue that opens click “Show Options” and then click “New...”.
- In the “New LDAP Connection” menue that pops up, set Server Name or IP Address:” to “ldap-serv1.cl.cam.ac.uk”. Among the radio buttons underneath, make sure that “Use for authentication” is ticked. Then click “Continue”.
- Back on the list of options, for the server you just added, set “LDAP Mappings” to “RFC2307”. You will then be prompted for “Search Base Suffix” and should enter enter “dc=cl,dc=cam,dc=ac,dc=uk”. Then press “OK”.
You can check whether under “Search policy” and “Authentication” it now says “Custom path” and has under “/Local/Default” the second directory domain “/LDAPv3/ldap-serv1.cl.cam.ac.uk” added. If not, click “+” to add it, then press “Apply”.
Once you have succeeded, the little bullet in front of “ldap-serv1.cl.cam.ac.uk” on the “Users & Groups” tool “Login Options” menue will have changed from grey to green, and you should now be now able to look up LDAP user and group names, for example with the command line “dscacheutil -q user -a name mgk25”. Finally, try “ls -l” on a mounted filer directory and check whether each file shows a non-numeric user and group identifier.
Note: It is not a problem if your local OS X numeric user identity (e.g., 501) differs from the one used at the department: since we are using Kerberos authentication, the filer ignores the client-side UID and decides access-control solely based on your Kerberos name (“principal”), which you gave to “kinit”.
Warning: For historic reasons, our Unix LDAP server still defines a number of UID and GID values below 1000, although these are today reserved for use by the client operating system. Where local and LDAP UIDs/GIDs overlap, they may be displayed incorrectly in commands like “id” or “ls -l”.
As soon as you have pointed your OS X system at the LDAP server as described above, it will discover there the departmental automount tables and start using them. This will result in the appearance of new directories /auto/homes, /auto/groups, /auto/userfiles, /auto/anfs, and /Nfs/Mounts in your local filesystem.
On lab-managed Linux machines, these are (for historic reasons) usually accessed via symbolic links, which you may also want to create with the following shell commands:
ln -s /auto/homes /homes ln -s /auto/anfs /anfs ln -s /Nfs/Mounts /a ln -s /anfs/glob /global ln -s /auto/groups /usr/groups
Unfortunately, the actual mounts underneath the /auto/*/
directories do not yet work: “cd /auto/homes” results in “Input/output
error” and a system.log entry about a failed “parse_entry: getmapent”.
[To be continued ...]
OS X Server – Open Directory Administration
Appendix B explains what the OS X Directory Service expects to find in an LDAP server. In fact, we could change the departmental LDAP setup (/usr/groups/admin/ldap-server/ldif/master.ldif) and point to it via DHCP such that OS X clients nearly make all the above configurations automatically.
- Autofs: Automatically Mounting Network File Shares in Mac OS X. Technical White Paper, Apple, June 2009