Empty

The Empty (empty) mount type creates an empty directory. This storage is ephemeral storage, meaning that after a user signs out of the session, all data inside the directory is deleted permanently.

This mount type does not require any extra properties.

In YAML format:

storage:  
  profiles:  
    - name: "<name>"  
      mounts:  
        - name: "code"  
          mountPath: "/code"  
          type: "empty"
          permissionType: "<permission type>"  
      startDirectory: "<start directory>"  
      restrictNavigationOutsideMounts: <true/false>  
      addons:  
        directory: "<addons directory>"

Host

The Host (host) mount type mounts a directory from the Nodes host. This mount type expects the directory (hostPath) to be present on the Node; otherwise, the MATLAB pod does not start.

This mount type has these extra properties:

In YAML format:

storage:  
  profiles:  
     - name: "<name>"  
        mounts:  
        - name: "node_folder"  
          mountPath: "/share" 
          hostPath: "/share" 
          type: "host"
          subPath: "/exports/${subject.subjectId}"
          permissionType: "<permission type>"  
        startDirectory: "<start directory>"  
        restrictNavigationOutsideMounts: <true/false>  
        addons:  
          directory: "<addons directory>"

NFS

The NFS (nfs) mount type mounts an NFS directory and then makes it available to the MATLAB user.

This mount type expects that the NFS server allows mounting the NFS directories onto the MATLAB pods. The NFS administrator might need to allow access to the NFS server by the Kubernetes cluster, through the NFS exports list.

This mount type requires the following extra properties:

In YAML format:

storage:  
  profiles:  
    - name: "<name>"  
      mounts:  
        - name: "nfsHome"  
          mountPath: "/share" 
          type: "nfs" 
          server: "nfs" 
          subPath: "/exports/home/${subject.subjectId}"  
          mountOptions:
"rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,acregmin=60
0,acregmax=600,acdirmin=600,acdirmax=600,hard,nocto,noacl,proto=tcp,ti
meo=600,retrans=2,mountproto=tcp,local_lock=none,nolock"
         permissionType: "<permission type>"
      startDirectory: "<start directory>"
      restrictNavigationOutsideMounts: <true/false>
      addons:
        directory: "<addons directory>"

Delegated

The Delegated (delegated) mount type mounts a drive or directory using a specified executable. You can use this executable to customize the storage mount using options not natively supported by the other mount types. For example, your executable can mount an NFS drive and specify mount options using the Common Internet File System (CIFS) protocol, which the "nfs" mount type does not support.

By default, this mount type is not enabled. To enable it, add or update the storage field of your resource.yaml file to specify the disallowedMountTypes subfield, and do not include the "delegated" option in this subfield. For example, this sample YAML field enables all mount types.

storage:
  disallowedMountTypes: []

In addition to the default storage mount properties, this mount type has this additional property:

In YAML format:

storage:  
  profiles:  
    - name: "<profile name>"  
      mounts:  
        - name: "<mount name>"  
          mountPath: "<mount path>"  
          type: "delegated"
          permissionType: "none"
          args:
          -  "/opt/matlabonlineserver/my_mount_script.sh"
          timeoutInSeconds: 10

The executable that you write must support these options:

Your MATLAB Online Server installation includes a sample customizable shell script for mounting an NFS drive. The script is located in the resource proxy Docker^® image, which controls the storage layer for MATLAB users. It is located at this path:

mos-resource-proxy-image/main/src/main/scripts/example_mount.sh

The example_mount.sh script has these contents.

#!/bin/bash
 
usage()
{
    echo "usage   : example_mount [[-h]]"
    echo "example : ./example_mount.sh or ./example_mount.sh -h or"
    echo "./example_mount.sh start --mos-mount-dir /tmp or ./example_mount.sh stop --mos-mount-dir /tmp"
}
 
function run() {
    echo "$@"
    $@
}
 
MOS_MOUNT_DIR=""
MOUNT_OPERATION=""
NFS_SERVER="myserver"
NFS_SUBPATH="mysubpath"
 
while [ "$1" != "" ]; do
    case $1 in
        -h | --help )                        usage
                                             exit
                                             ;;
        --mos-mount-dir )                    shift
                                             MOS_MOUNT_DIR=$1
                                             ;;
        start )                              MOUNT_OPERATION=$1
                                             ;;
        stop )                               MOUNT_OPERATION=$1
                                             ;;
        # Other arguments can be processed the same way
        * )                                  usage
                                             exit 1
    esac
    shift
done
 
if [ -z "$MOS_MOUNT_DIR" ]
then
echo "Mount directory is empty"
exit 1
fi
 
case "${MOUNT_OPERATION}" in
    "start")
        echo "Starting mount operation on directory ${MOS_MOUNT_DIR}"
        run mkdir -p "$MOS_MOUNT_DIR"
        run sudo mount -t nfs -o rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,acregmin=600, \
acregmax=600,acdirmin=600,acdirmax=600,hard,nocto,noacl,proto=tcp,timeo=600,retrans=2,mountproto=tcp, \
local_lock=none,nolock ${NFS_SERVER}:${NFS_SUBPATH} "${MOS_MOUNT_DIR}"
        ;;
    "stop")
        echo "Stopping mount operation on directory ${MOS_MOUNT_DIR}"
        run sudo umount "${MOS_MOUNT_DIR}"
        ;;
    *)
        echo "Not a supported mount operation"
        exit 1
        ;;
esac
 
exit 0

In this script, you can customize the NFS_SERVER and NFS_SUBPATH variables to set the NFS folder you want to mount. Placeholders for specifying user names are supported. For more details, see Placeholders. Sample variable values are:

NFS_SERVER = "nfs"
NFS_SUBPATH = "exports/home/${subject.subjectId}"

By default, the executables you write can run the mount, unmount, chown, and chmod commands without requiring a password. If your executable uses other commands that normally require a password, you can customize the resource proxy image to run these commands without a password.

Suppose you want your executable to run mkdir without having to enter a password on folders that are normally password protected. You can write a Dockerfile to disable the password prompt in the resource proxy image and then rebuild the image.

This example assumes you are using Docker as your container management tool. If you are using Podman instead, replace docker with podman in the commands shown.

Persistent Volume Claim (PVC)

PVC (pvc) mount type mounts a Persistent Volume Claim that is available on the Kubernetes cluster and makes it available to the MATLAB user.

Refer to the following link for detailed information on Persistent Volumes: https://kubernetes.io/docs/concepts/storage/persistent-volumes.

This mount type requires the following extra properties:

These extra properties are shown in YAML format in the following example:

storage:
  profiles: 
    - name: "<name>" 
      mounts: 
        - name: "home" 
          mountPath: "/share" 
          type: "pvc" 
          claimName: "<pvc name>" 
          subPath: "/exports/home/${subject.subjectId}" 
          permissionType: "<permission type>"
      startDirectory: "<start directory>" 
      restrictNavigationOutsideMounts: <true/false> 
      addons: 
        directory: "<addons directory>"

When using a Persistent Volume Claim, keep these points in mind:

None

The None (none) permission type performs a mount with default access to the MATLAB process only.

This permission type is ideal for empty mount types (ephemeral storage) or anonymous read-only directories that are mounted.

This permission type does not require any extra properties.

In YAML format:

storage:  
  profiles:  
    - name: "<name>"  
      mounts:  
        - name: "code"  
          mountPath: "/code"  
          type: "empty"  
          permissionType: "none"  
      startDirectory: "<start directory>"  
      restrictNavigationOutsideMounts: <true/false>  
      addons:  
        directory: "<addons directory>"

Fixed

The Fixed (fixed) permission type performs a mount and then shares the directory with the same permissions that are specified (uid, gid) to the MATLAB process only.

This permission type is ideal for shared read-only directories.

This permission type requires the following extra properties:

In YAML format:

storage:  
  profiles:  
    - name: "<name>"  
      mounts:  
      - name: "public"  
        mountPath: "/public"  
        type: "nfs"  
        server: "nfs"  
        subPath: "/exports/nfs_share"  
        mountOptions: 
"ro,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,acreg
min=600,acregmax=600,acdirmin=600,acdirmax=600,hard,nocto,noacl,
proto=tcp,timeo=600,retrans=2,sec=sys,mountproto=tcp,local_lock=
none,nolock"  
        permissionType: "fixed"  
        uid: "1001"  
        gid: "1000"  
      startDirectory: "<start directory>"  
      restrictNavigationOutsideMounts: <true/false>  
      addons:  
        directory: "<addons directory>"

User

The User (user) permission type performs a mount and then shares the directory with the same permissions as that of the user (uid, gid) to the MATLAB process only if the placeholders are resolved. For more information, see Placeholders.

This permission type is ideal for mounting user-specific directories, such as an NFS home folder, which is readable and writable by the signed-in user only.

This permission type requires the following extra properties:

In YAML format:

storage:  
  profiles:  
  - name: "<name>"  
    mounts:  
      - name: "public"  
        mountPath: "/public"  
        type: "nfs"  
        server: "nfs"  
        subPath: "/exports/home/${subject.subjectId}"  
        mountOptions: 
"rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,acreg
min=600,acregmax=600,acdirmin=600,acdirmax=600,hard,nocto,noacl,
proto=tcp,timeo=600,retrans=2,mountproto=tcp,local_lock=none,nol
ock"  
        permissionType: "user"  
        uid: "${subject.uid}"  
        gid: "${subject.gid}"  
    startDirectory: "<start directory>"  
    restrictNavigationOutsideMounts: <true/false>  
    addons:  
      directory: "<addons directory>"

NFS - PVC Storage Profile

The following example provides instructions to create a Persistent Volume Claim where the data is stored in an NFS server. This newly created Persistent Volume Claim in MATLAB Online Server can provide data persistence to the MATLAB user upon signing in.

EBS (Elastic Block Storage) PVC Storage Profile

The following example provides instructions to create a Persistent Volume Claim where the data is stored in an AWS EBS volume, and for using this newly created Persistent Volume Claim in MATLAB Online Server to provide data persistence to the MATLAB user upon signing in.

EFS (Elastic File Storage) PVC Storage Profile

The following example provides instructions to create a Persistent Volume Claim where the data is stored in an AWS EFS volume, and for using this newly created Persistent Volume Claim in MATLAB Online Server to provide data persistence to the MATLAB user upon signing in.

Azure Files PVC Storage Profile

The following example provides instructions to create a Persistent Volume Claim where the data is stored in an Azure Files volume, and for using this newly created Persistent Volume Claim in MATLAB Online Server to provide data persistence to the MATLAB user upon signing in.