Files
2026-09-28 17:14:01 +02:00

7.5 KiB

Mounting Volumes

Managing mount points of local or network volumes can also be done in Hiera.

For more automatic network data setups please look at

Managing Mountpoints in Hiera

The configuration in Hiera is done with two parts:

  1. the definition of a mountpoint (mounter::def::$NAME)
  2. the list of mount points actually configured on a system (mounter::mounts)

Due to this the mountpoints can be prepared once on a high scope (e.g. for all systems in an environment), but then the individual systems pick out whatever is required for them.

Example:

mounter::def::scratch:
  ensure: 'mounted'
  mountpoint: '/scratch'
  device: '/dev/vg_data/lv_scratch'
  type: 'xfs'

mounter::mounts:
  - 'scratch'

The directory of the mountpoint is automatically created when missing.

For auto-mounts, add another option to the mountpoint definition:

  auto: true

NFS

Remote NFS mountpoints can be defined as in following example:

mounter::def::data1:
  'ensure': 'mounted'
  'device': 'x01dc-fs-1:/export/X01DC/Data1'
  'mountpoint': '/sls/X01DC/Data1'
  'type': 'nfs4'
  'options': 'sec=krb5'

mounter::def::controls:
  'ensure': 'mounted'
  'device': 'sls-hafs:/export/sls/controls'
  'mountpoint': '/gfa/.mounts/sls_controls'
  'type': 'nfs'

mounter::mounts:
  - 'data1'
  - 'controls'

Ideally use NFSv4 (type nfs4) and Kerberos authentication (option sec=krb5) is used. And of course also the NetApp side needs to be prepared accordingly.

Following options are possible for sec:

  • sys client enforces access control (default on NFS3)
  • krb5 server enforces access control, client user authenticates with Kerberos
  • krb5i server enforces access control, client user authenticates with Kerberos and traffic is integrity checked
  • krb5p server enforces access control, client user authenticates with Kerberos and traffic is fully encrypted

NFS and Kerberos also needs ID mapping, which is automatically configured to the default domain psi.ch. Should a different domain be required, you may set it with Hiera:

nfs_idmap::domain: 'ethz.ch'

Checkout Permanent Kerberos with gssproxy and Password Keytab if you want to access a Kerberos protected share, e.g. with background processes without having to type passwords (kinit) regularly.

Caching

NFS filesystem access can be speed up via local caching. This can easily done by specifying the mount option fsc.

!!! warning Due to a bug in the NFS client the fsc option need to be amended with the nosharecache option as well. See RedHat support case https://access.redhat.com/support/cases/?#/case/07772007 for more details.

If this option is specified Puppet will take care of the installation of the needed cachefilesd daemon and its configuration before doing the mount.

Example:

mounter::def::modules:
  ensure: 'mounted'
  mountpoint: '/modules'
  device: 'lx-fs.psi.ch:/modules'
  options: 'fsc,nosharecache,sec=krb5'
  type: 'nfs4'

mounter::mounts:
  - 'modules'

The default caching directory is /var/cache/fscache

The cachefilesd configuration can be tweaked by specifying following hiera keys:

cachefilesd::cachedir: '/mypath' # default: /var/cache/fscache
cachefilesd::tag: 'mytag'
cachefilesd::brun: 10
cachefilesd::bcull: 7
cachefilesd::bstop: 3
cachefilesd::frun: 10
cachefilesd::fcull: 7
cachefilesd::fstop: 3

More details about cachefilesd and its options can be found at: https://www.kernel.org/doc/html/v5.10/filesystems/caching/cachefiles and in the puppet module itself.

CIFS

CIFS with Multiuser Option and Kerberos

Mounting a CIFS share with the multiuser option and Kerberos has the advantage that no password is needed and each user gets personal access rights checked on the server side. But she/he needs to have, similar to AFS, an appropriate Kerberos ticket. Additionally the option cifsacl is required for showing the proper file owner.

mounter::def::scratch:
  ensure: 'mounted'
  device: '//scratch01.psi.ch/scratch'
  mountpoint: '/media/scratch'
  type: 'cifs'
  options: 'multiuser,sec=krb5,cifsacl'

mounter::mounts:
  - 'scratch'

For shares on NetApp (fs00.psi.ch until fs03.psi.ch) you can mount the data folder which contains all shares on this server:

mounter::def::fs00:
  ensure: 'mounted'
  device: '//fs00.psi.ch/data'
  mountpoint: '/cifs/fs00'
  type: 'cifs'
  options: 'multiuser,sec=krb5,cifsacl'

mounter::mounts:
  - 'fs00'

This only works if everybody has read access to the share itself, but that is not needed for subfolders. Else you need a password as below or a keytab (here feel free to ask the Linux Group for support).

Checkout Permanent Kerberos with gssproxy and Password Keytab if you want to access a Kerberos protected share, e.g. with background processes without having to type passwords (kinit) regularly.

CIFS with User and Password

Remote CIFS mountpoints can be defined as follows:

mounter::def::emf: 
  ensure: 'mounted'
  device: '//172.23.75.16/Users'
  mountpoint: '/emf/jeol2200fs/k2'
  type: 'cifs'
  options: 'credentials=/etc/cifs-utils/cifs_mpc2375,uid=35667,gid=35270,forcegid,file_mode=0660,dir_mode=0770'
  cifs:
    cifs_mpc2375:
      username: 'allowedWindowsUser'
      password: 'ENC[PKCS7,MIIBeQYJKoZIhvc...]'

mounter::mounts: 
  - 'emf'

In the above example, we need to create a credentials file with the content below the cifs -> $NAME parameter. This file will be called like the key below cifs and will be located in /etc/cifs-utils and will contain information about the username and password allowed to mount it. To be used the file needs to be referenced as credentials= in the mount options.

Systemd Automount

Adding the options noauto,x-systemd.automount will make the mount not happen on startup, but will be automounted on the first use of the mountpoint.

Bind Mounts

Bind mounts can be defined as follows:

mounter::def::e10550:
  'ensure': 'mounted'
  'device': '/gpfs/perf/MX/Data10-pro/e10550'
  'mountpoint': '/sls/MX/Data10/e10550'
  'type': 'none'
  'options': 'bind,_netdev,x-systemd.requires-mounts-for=/gpfs/perf/MX/Data10-pro'

Note that beside the mandatory bind option there is

  • _netdev to be set when the directory to bind (device) is on a network volume
  • x-systemd.requires-mounts-for=$OTHER_MOUNTPOINT ensures that systemd prepares the bind mount after the volume on which the directory to bind (device) is located

Another option are FUSE bind mounts with the bindfs tool. One use case is to get a directory with symlinks resolved to mount it later into a container:

mounter::def::certsro:
  #ensure: 'mounted'
  ensure: 'absent'
  mountpoint: '/mnt/certsro'
  device: '/etc/ssl/certs'
  type: 'fuse.bindfs'
  options: 'ro,resolve-symlinks,x-systemd.requires-mounts-for=/etc/ssl/certs'
  remounts: false

Here you need to set remounts: false because FUSE cannot do remounts.

Removing a Mount

Only removing a mount point definition from Hiera does not unmount and remove it from the node. This can then be done manually by unmounting it and removing it from /etc/fstab.

Alternatively an absent mount definition as in below example will automatically unmount and remove the mount /etc/fstab entry:

mounter::def::scratch:
  ensure: 'absent'
  mountpoint: '/media/scratch'

mounter::mounts:
  - 'scratch'

This configuration can then be removed again after it has been rolled out once to all concerned nodes.