# 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
- [Windows Drives in Home Directory](windows_drives_in_home)
- [Central Storage Mount](central_storage_mount)
- [autofs](autofs)
- [AFS](afs)


## 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': 'nfs'
  'options': 'nfsvers=4.2,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 (option `nfsvers=4.2`) 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](../basic/gssproxy_with_keytab) if you want to access a Kerberos protected share, e.g. with background processes without having to type passwords (`kinit`) regularly.

## 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](../basic/gssproxy_with_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

## 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 defintion 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 concernded nodes.