Department of Computer Science and Technology

Filer access on macOS

Your directory on the filer can be accessed directly from macOS whilst your computer is physically within the building (or via VPN). Access is also permitted from the VLAN290 network on which unmanaged machines are connected, and via the local “Internal-CL” wireless network.

To access the lab filespace you must have a valid departmental Kerberos login, i.e. the same password as for using lab-managed Linux or Windows machines in the DC.CL.CAM.AC.UK Active Directory domain.

You can choose between two ways of accessing the filer:

  • NFSv3 protocol – Behaves like lab-managed Unix/Linux. Files created will have Unix/POSIX-style access control permissions (see “man chmod”), symbolic links are fully supported, and the protocol is very fast on LANs. This option is in particular much preferable for anyone who mostly collaborates with Unix/Linux users, or who uses their Mac commonly from the shell command-line.
  • SMB 2/3 protocol – Behaves 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 was the only protocol supported in our previous filer “elmer”, but since the October 2019 migration to a new filer “wilbur”, this is now the less recommended option.

Preventing the creation of .DS_Store files

Before accessing the filer for the first time from macOS, please perform the following step.

Users of the macOS Finder application who browse filer directories where they have communal write access risk becoming a nuisance to other users because Finder litters every folder it visits with a .DS_Store file (to store custom attributes of the folder such as the position of icons, etc.)

To disable the creation of these nuisance files on remote file servers by your NFS/SMB/WebDAV client, execute the following command in Terminal:

$ defaults write DSDontWriteNetworkStores true

This is also likely to speed up the display of folders in Finder.

See also:

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, Internal-CL, VPN). You need macOS Sierra (10.12) or newer.

First you need to a get a Kerberos ticket with

$ kinit crsid@DC.CL.CAM.AC.UK

This ticket lasts for 10 hours or until you log out. You can check its expiry time with “klist”.

If you ever get “permission denied” errors with NFS, first of all try another “kinit”.

A note for older users: If you haven't reset your departmental Kerberos password in the past decade (since the departmental Active Directory server was upgraded to Windows Server 2008), then you may have to reset your password first before it will work on macOS, otherwise our Kerberos Server will not yet have had a chance to store an AES-compatible hash of your password.

Configuring LDAP

The following instructions are for Macs that have not yet already been joined to an Active Directory domain. If you find that your Mac shows in the second step below next to “Network Account Server:” an Active Directory domain and a green bullet, better contact Graham Titmus for advice first.

To help macOS Directory Services receive the departmental automount tables, as well as the tables for mapping between numeric user and group identifiers and the corresponding names, you have to configure it with the “Open Directory Utility” to connect to a departmental Unix LDAP server:

  • 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 click the button 'Open Directory Utility...'.
  • In the Directory Utility, again open the padlock using your admin password. Under 'Services', double-click 'LDAPv3'; on the menu that opens, click 'Show Options' and then 'New...'.
  • In the 'New LDAP Connection' menu that pops up, set 'Server Name or IP Address:' to ''. Among the options 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'. The screen should then look like the screnshot below. Then press 'OK'.

ldap configuration settings

Back in the Directory Utility main window you can check whether under 'Search policy' and 'Authentication' it now says 'Custom path' and has under '/Local/Default' the second directory domain '/LDAPv3/' added. If not, click '+' to add it, then press 'Apply'. Close the Directory Utility main window

Once you have succeeded, the little bullet in front of '' on the 'Users & Groups' tool 'Login Options' menu will have changed from grey to green.

Command-line configuration

Alternatively, you can also run (as root) the commands

$ sudo bash
# dsconfigldap -a
# cd /Library/Preferences/OpenDirectory/Configurations/LDAPv3/
# curl -O
# killall opendirectoryd

To remove the configuration again, you can use

# dsconfigldap -r


As soon as you have pointed your macOS system at the LDAP server, as described above, it should discover there the departmental automount tables and start using them. A reboot may be required the first time.

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 still accessed via these five symbolic links:

/homes      -> /auto/homes
/anfs       -> /auto/anfs
/a          -> /Nfs/Mounts
/global     -> /anfs/glob
/usr/groups -> /auto/groups

However, Apple's System Integrity Protection policy (introduced with macOS El Capitan) prevents you from creating the fifth symbolic link at /usr/groups. So you will have to access /auto/groups directly, instead of via the traditional /usr/groups prefix.

On macOS 10.15 “Catalina”, the entire root partition is now a read-only filesystem, and therefore none of the above symbolic links can be created any more. However, Catalina supports a new type of “synthetic firmlink” defined in /etc/synthetic.conf that may be of help here (see “man synthetic.conf”). [We may also decide phase out all these historic symbolic links in future anyway. The entire organization of the departmental filer namespace should be reviewed following the October 2019 migration.]

Testing user name mappings

You should now also be 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 macOS 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”.

Manual mounting

If you want to manually mount the filer instead, as a quick test, 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). Example:

$ mkdir cl-filer
$ kinit crsid@DC.CL.CAM.AC.UK”
$ mount cl-filer
$ ls cl-filer/userfiles/$USER/unix_html/

A much better option is to set up LDAP-based automounting, as described above, which then allows you to use the same paths as you are used to in lab-managed Linux machines. That also ensures correct display of file owners and groups. But laptop owners may want to be cautious, see the Bugs section below.

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 macOS.


  • The departmental LDAP server should support either Kerberos or TLS encryption and authentication, so it can't be impersonated by a hostile network.
  • Setting up an LDAP connection on a laptop may cause some startup delays if the LDAP server is not reachable. You can configure timeouts in the Open Directory Utility (under Services | LDAPv3 | | Edit... | Connection):

    Users can try to reduce some of these. A neater solution would be preferable.

  • LDAP on a laptop may also pose security risks on untrusted networks as long as we do not support and require TLS or Kerberos encryption and authentication of the LDAP connection. Therefore the LDAP setup is at the moment mainly recommended for stationary macOS machines located in the department.
  • 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”.
  • The filer namespace should be redesigned. Two goals might be:
    • make the paths look the same as under Windows and Unix (e.g., /auto vs. \\filer), except for the slashes.
    • Phase out the need to create five symlinks on the root partition.


Access via SMB

To mount an SMB share, you first need to make sure that you have obtained a Kerberos ticket with “kinit [Javascript required]” (same as for NFS access).

Then start “Finder” and select the menu item “Go | Connect to Server ...” and type in as the “Server Address:” the required smb:// path that you want to mount.

Example mount points that currently work (this can change in the near future):

  • To mount your superhome (contains contains your unix_home and windows_home):
  • To mount your group space
  • To mount webserver related filespaces (/auto/anfs/www* on NFS)

If you get a GUI password prompt as below, click “Cancel” and use “kinit” instead:

The previously recommended path smb:// is now served by a DFS server. It appears that DFS redirecting currently does fully work on macOS (e.g. mounting smb:// works, but mounting smb:// mounts a folder that contains empty folders such as security). It appears that macOS follows DFS redirects on the initial mount, but does not deal with them when an application such as Finder later encounters a DSF redirect while traversing the mounted filesystem.

See also: