Skip to main content
In the GPFS shared file system, permissions are granted for the entire Volume by default. Authorized users can usually access all content under the Volume root directory. If you need least-privilege isolation without splitting the Volume, you can configure directory-level permissions. After directory-level permissions are enabled, newly started workloads no longer mount the entire Volume. Read and write permissions for each subdirectory must be configured separately, and subdirectories without configured permissions will not be mounted to newly started workloads.

​
Applicable Scenarios

  • Multiple users share the same large-capacity Volume but can access only their own directories.
  • Public datasets, team directories, and personal directories need to be managed in the same Volume.
  • Some directories need to be made available to other users in read-only mode.
  • Training, Develop, or Inference can be mounted only to specified subdirectories.

​
Directory Type

Directory-level permissions support three types of directories: The paths of public directories and Custom subdirectories must be actual subdirectories within the Volume namespace and cannot directly use the Volume root directory. The root path of a user directory can be the Volume root directory or a subdirectory under the Volume root directory.

​
Permission Configuration Requirements

  • Directory-level permissions are enabled for the target Volume.
  • The current account has permission to manage the Volume or the relevant directories.
  • Users requiring authorization are within the authorized user scope of the Volume.
  • Public directories, custom subdirectories, and user directory root paths have been planned.
  • It has been confirmed whether existing development environments, training jobs, or inference services still mount the Volume as a whole.

​
Configure Directory Permissions

Go to Resources > Volume, open the Directory Permissions tab, and select the Volume to configure. The directory permissions page is organized into Public Directories, Custom Subdirectories, and User Directories. In each section, you can search for directories, view authorized users, permissions, usage, and update times, and perform actions such as granting authorization, setting quotas, or removing access.

​
Configure Public Directory

The public directory is suitable for storing shared team data, base models, checkpoints, dependency caches, or read-only reference files. In the Public Directory section, click Add Public Directory. When configuring a public directory, Specify:
  • Directory path.
  • Permission type: read-only or read-write.
  • Remark information.
Permissions for the shared directory apply to users authorized for this Volume. After the permissions are modified, users will be validated against the new permissions when they subsequently mount and access the directory. If a public directory no longer needs to be exposed, you can remove its configuration. Removing the configuration does not guarantee deletion of the underlying directory or data; actual data handling depends on platform behavior.

​
Configure a Custom Subdirectory

Custom subdirectories are suitable for Project Groups, experimental tasks, or team collaboration directories. In the Custom Subdirectory section, click Add Subdirectory. When creating a custom subdirectory, specify the directory path. After it is created, you can use User Authorization to grant specified users read-only or read/write permissions. When updating the authorization list, the latest configuration prevails. When you delete a custom subdirectory configuration, its authorization configuration is also removed. Before deleting it, ensure that this will not affect tasks that are using the directory.

​
Configure User Directory

The user directory provides each user with a personal dedicated directory. In the User Directory section, click Modify User Directory to set the root path for user directories. The system automatically generates a corresponding user directory for each user authorized for the Volume. The path is typically:
Users have read and write permissions for their own directories by default. When collaboration is needed, you can authorize the user directory to other users through User Authorization. By default, other users are granted read-only access, which can be configured as read-write as needed. To limit the size of a user directory, set a quota for the corresponding directory in the user directory list. User directories are automatically generated by the system for authorized users and do not need to be created manually one by one.

​
Authentication Rules When Submitting Tasks

Directory-level permissions take effect when you submit from Develop, Training, or Inference. The authentication rules are as follows:
  • If directory-level permissions are enabled for a Volume, newly launched workloads must be mounted to authorized subdirectories.
  • If a subdirectory is mounted but is outside the range that the current user is authorized to mount, the submission will be rejected.
  • If read-write mounting is requested for a read-only directory, the submission will be rejected.
  • If read-only mounting is requested for a read-write directory, the submission can be accepted.
  • Volumes without directory-level permissions enabled are unaffected. Their submission method is the same as for standard whole-volume mounts.
When submitting a task, users can typically select only directories they have permission to access, such as personal directories, authorized directories, and public directories.

​
View Directory Usage

The Directory Permissions page displays the usage of public directories, custom subdirectories, and user directories. Based on the usage, you can determine whether to clean up data, adjust directory quotas, or expand the Volume. If there is a delay in directory usage statistics, refer to the latest refreshed results on the page.

​
Impact on Existing Instances

If an existing development environment, training job, or inference service has mounted a Volume as an entire volume, enabling directory-level permissions for that Volume may trigger directory-level authorization checks during subsequent operations such as modification, restart, bringing online, or taking offline. If the original mount method does not match the directory-level permission policy, the operation may be interrupted because permission validation fails. Before enabling directory-level permissions, adjust existing instances to mount by subdirectory, or confirm that the relevant users will not be affected by directory-level permissions.