Computer Laboratory

Filer access on Unix

This page describes how to arrange access to filer from self-managed Unix/Linux machines located in the department on the subnet

If you are using a lab-managed machine, this has already been set up for you, please see instructions for lab-managed machines.

If you want to access the filer via NFS from a personal Linux home computer or laptop via VPN, please see Markus Kuhn's page on remote NFS access without LDAP.

Setting up Kerberos

Access to the main departmental filer ( requires Kerberos authentication.

Required packages

Ensure that the packages krb5-user and nfs-common are installed:

$ sudo apt-get install krb5-user nfs-common

Configuring Kerberos

Update /etc/default/nfs-common to ensure it has


Update /etc/krb5.conf so that it has

default_realm = AD.CL.CAM.AC.UK

You should now be able to fetch a ticket-granting ticket (TGT) using your CRSID and departmental Kerberos password, and display it, using

$ kinit CRSID
Password for CRSID@AD.CL.CAM.AC.UK: *************
$ klist

Installing a keytab

To perform a mount, the Linux gssd also needs to obtain a Kerberos ticket for user root. Instead of a password, it uses a keytab file. By default, when gssd finds a keytab in /etc/krb5.keytab it uses that to obtain a TGT for root (/etc/krb5ccmachine_AD.CL.CAM.AC.UK).

Request a keytab file for your system from sys-admin and install it in /etc/krb5.keytab (permissions: chmod go-rwx).

Testing a manual mount

Once both you and root have a Kerberos TGT, you should be able to manually mount the filer. Try:

$ sudo mount /mnt
$ ls /mnt/vol
vol0  vol1  vol2  vol3  vol4  vol5  vol6  vol7  vol8  vol9  voltest

User and group mappings (LDAP)

For correct display of the owner and groups of files (e.g. with ls -l), the passwd and group databases of your system need to be linked to a departmental LDAP server.

Install libnss-ldap. When asked, the 'LDAP server Uniform Resource Identifier:' should be 'ldap://' and 'Distinguished name of the search base:' should be 'dc=cl,dc=cam,dc=ac,dc=uk'. Use the default LDAP version of 3. Select not to 'Make local root Database admin:'. Accept No for 'Does the LDAP database require login?'.
These values are used to setup /etc/ldap.conf.

Check that /etc/nsswitch.conf has 'ldap' listed for passwd, group and automount (if autofs is to be used).

Automounter setup

The low-level name space exported by the filer is not very convenient, because it shows how the file space is spread across volumes and qtrees. The customary filespace on lab-managed Linux machines (/homes, /usr/groups, /anfs, etc.) is created via autofs mapping tables that are disseminated via LDAP, along with a small number of symbolic links.

Required packages

To run autofs, ensure that the packages autofs and autofs-ldap are installed, e.g. by running

$ sudo apt-get install autofs-ldap

Mapping tables from LDAP

Autofs uses a different LDAP library configured by /etc/ldap/ldap.conf, therefore make sure this file also points to the departmental LDAP server using:

BASE dc=cl,dc=cam,dc=ac,dc=uk
URI ldap://

To configure autofs to use this LDAP server, check that /etc/nsswitch.conf has 'ldap' listed for automount.

(It seems to be OK to use the default +auto.master in /etc/auto.master, rather than needing to change it to +auto_master.)

Testing autofs

After a restart of autofs it should create a mount point such as /auto/groups, and allow access to /auto/groups/linux.

The symbolic links normally installed by the package cl-autofs-dirs may be of use:

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

Note that linking /home to /homes may allow access to user home directories using '~$crsid', but is probably not a good idea if local home directories are in /home. Instead, use '/homes/$crsid'.

Choice of NFS version

The departmental filer supports both NFSv3 and NFSv4.0, two very different protocols. Recent Linux versions now use NFSv4 by default, if available. NFSv4 can be faster when used across high-latency networks (remote WAN access), but can cause the following problems:

  • If an application creates a new file with option O_EXCL, i.e. with the sytem call open(..., O_CREAT|O_EXCL|O_WRONLY, ...) (e.g., bash with option “noclobber” set), the file may end up with unexpected permission bits (typically rwx------).
  • If the uid and gid of a file are not listed by the departmental LDAP server, they will be shown as user name "nobody" and group name "nogroup", respectively.
  • In some Linux versions (e.g., Ubuntu 14.04), lookup of user and group names also occasionally fails due to caching bugs.

Background: When looking at file metadata (e.g. with stat or ls -l) NFSv3 simply sends the numeric uid and gid of files. NFSv4 instead sends human-readable strings such as [Javascript required], and a client-side idmapd process has to convert these back into numeric uid and gid values via LDAP.

This additional conversion by idmapd can occasionally fail, e.g. for uids and gids not listed in LDAP. Therefore, display of owner and group metadata can be more robust when forcing the use of NFSv3.

Therefore, on the fast Lab LAN, NFSv3 currently still remains a safer choice.

To force autofs to use NFSv3, make sure /etc/default/autofs sets


How to force manual mounts to use NFSv3 is described in “man nfsmount.conf”, e.g. using

[ NFSMount_Global_Options ]