Using an External NFS Server
As an alternative, you can install an NFS server that is external to the cluster. This is not the recommended approach.
no_root_squash option has security implications,
which is a reason to choose internal NFS instead.
Before creating a CML workspace, the storage administrator must create a directory that will be exported to the cluster for storing ML project files for that workspace. Either a dedicated NFS export path, or a subdirectory in an existing export must be specified for each workspace.
Each CML workspace needs a unique directory that does not have files in it from a different or previous workspace. For example, if 10 CML workspaces are expected, the storage administrator will need to create 10 unique directories. Either one NFS export and 10 subdirectories within it need to be created, or 10 unique exports need to be created.
For example, to use a dedicated NFS share for a workspace named “workspace1” from NFS server “nfs_server”, do the following:
- Create NFS export directory “/workspace1”.
Change ownership for the exported directory
CML accesses this directory as a user with a UID and GID of 8536.
chown 8536:8536 /workspace1
Make the export directory group-writeable and set the GID:
chmod g+srwx /workspace1
- CML accesses this directory as a user with a UID and GID of 8536. Therefore, run
Provide the NFS export
path nfs_server:/workspace1when prompted by the CML Control Plane App while creating the workspace.
To use a subdirectory in an existing NFS share, say
nfs_server:/export, do the following:
Create a subdirectory
chown 8536:8536 /export/workspace1
Set GID and make directory group writeable:
chmod g+srwx /export/workspace1
Provide the export path
nfs_server:/export/workspace1when prompted by the CML Control Plane App.
- Create a subdirectory