skip to primary navigationskip to content

Department of Computer Science and Technology



Filer access on macOS

You can choose between two ways of accessing the departmental 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, especially on LANs. This option is in particular much preferable for anyone who mostly collaborates with Unix/Linux users, or who uses macOS 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 recognizable as such, and this can cause problems. Mandatory locking is available on SMB, which can also cause problems (e.g., you can't overwrite a PDF while it is being displayed).

Generally, NFS works better with Unix tools and SMB works better with Microsoft Office.

For both forms of access, your computer either needs to be connected to an appropriate subnet within the William Gates Building (e.g., the “Internal-CL” wifi or one of the wired connections for lab-managed machines), or you need to set up and connect the Computer Laboratory VPN.

You will also need 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.

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

You need macOS Sierra (10.12) or newer for Kerberized NFS to work.

Configuring LDAP

The following instructions assume a self-managed Mac not joined to the DC.CL.CAM.AC.UK Active Directory domain. If you have a departmental desktop Mac that shows in the second step below, next to “Network Account Server:”, the Active Directory domain and a green bullet, your machine is domain joined, and you may find that you don’t have to use kinit, as you will already automatically get a Kerberos ticket when you log in. You can still add the LDAPv3 server as a second directory service, to obtain the NFS automount tables and UID/GID mappings. Contact Markus Kuhn for help.

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:

  • Open '(Apple)|System Settings...|Users & Groups'.
  • [Only on macOS 12 or earlier:] If you see there 'Login Options', click on that. Then click the padlock symbol and unlock it with your admin password. (You may later be asked for that admin password a few more times.)
  • Next to 'Network Account Server' click 'Join...' (or 'Edit...') and then on the menu that pops up click the button 'Open Directory Utility...'.
  • In the Directory Utility, 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 screenshot 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.

One more thing [only for laptops]: 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):

tab with timeout values

Reduce the first two timeouts to e.g. 3 seconds.

Automount symlinks

Configuring LDAP will (after reboot and kinit) 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 usually accessed in a shortened form 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 (since macOS El Capitan) now prevents us now from creating the fifth symbolic link at /usr/groups. So on Macs you will have to access /auto/groups directly, instead of via the traditional /usr/groups prefix.

Newer macOS versions (since Catalina) now write-protect the root directory entirely, therefore we can't directly create the above symlinks (even as root). Instead, use the following commands to create equivalent “synthetic firmlinks” (see “man synthetic.conf”):

% sudo zsh
# curl -o /etc/synthetic.conf
# reboot

Testing your NFS access

After the reboot (and if you are outside the department: after reconnecting the CL VPN), you should now be able to

$ kinit your-crsid@DC.CL.CAM.AC.UK
your-crsid@DC.CL.CAM.AC.UK's password: your-departmental-password
$ ls -l /anfs/www/tools
total 12
drwxrwsr-x 3 mgk25 wwwpages 4096 Sep 29 14:26 bin
drwxrwsr-x 9 mgk25 wwwpages 4096 Oct  6 09:22 share
drwxrwsr-x 4 mgk25 wwwpages 4096 Sep 26  2019 windows

Congratulations, you now have LDAP-configured auto-mounted Kerberos-authenticated NFSv3 access to the departmental filer!

If you get “Operation not permitted” errors with automounted NFS files or folders, see below on how to enable “Network Volumes” access for the affected application.

The Kerberos ticket you get with “kinit” lasts for 10 hours or until you log out. After that you need to run “kinit” again. You can check the expiry time of your ticket with “klist”.

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

You can use the (undocumented) option “kinit --keychain your-crsid@DC.CL.CAM.AC.UK” to persistently store your Kerberos password in your macOS keychain. After doing that once, “kinit” will no longer ask for your password. To delete the password, open the “Keychain Access” application and look there for login / Passwords / DC.CL.CAM.AC.UK.


If things don't work, here are some additional hints:

  • If you get an “Operation not permitted” error when trying to access an automounted NFS folder, then check under “(Apple)|System Settings...|Privacy & Security|Files and Folders” if the application you were using (e.g., “Terminal”) is allowed there to access “Network Volumes”. If not, you need to enable that there, and possibly restart the affected application. (This problem should not occur if you have System Integrity Protection disabled.) In case that fails, you can also reset these settings from the command line using tccutil, and if that still doesn't have the desired effect on an Intel-based Mac also try resetting PRAM/NVRAM.
  • 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.
  • Check (with “which kinit”) that you are actually using Apple's /usr/bin/kinit. There have been cases were downloaded application environments added their entire own Kerberos installation to the user's PATH, which can use different default settings or credential-cache locations than the operating system. Anaconda’s krb5 package has been known to do that.
  • IPv4 connectivity might be required for automounting to work (an automount attempt seems to not even acquire a service ticket on IPv6-only macOS Catalina, even though manual mounting works).
  • There is no need for the username or the uid on the client to match the one on the server.


  • The departmental LDAP server should support either Kerberos or TLS encryption and authentication, so it can't be impersonated by a hostile network.
  • 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:
    • phase out /usr/groups/
    • 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.
  • Explore Kerberos Single Sign-on extension (needs MDM, user guide) to auto-refresh Kerberos TGT in a battery-friendly way.


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: