Skip to main content
Training task sharing enables collaborators to view training configurations, status, and logs. After recipients are granted access, they can use the task link to troubleshoot issues; computing resources, storage, and write permissions are managed separately.
  • A task link itself does not grant permissions. Whether recipients can access the task, read data, clone the configuration, or perform actions such as stopping or deleting depends on task visibility, feature permissions, resource permissions, and storage permissions.
  • Before sharing, check whether the startup command, environment variables, logs, mount path, or output path contains credentials, tokens, keys, internal addresses, or personal directories that should not be shared.

​
Choose a Collaboration Method

​
Confirm Authorization Mode

The training sharing entry point is affected by the Project Group permission mode. Before you begin configuration, determine which method to use based on the actual entry point on the page. In RBAC mode, legacy personal sharing API requests are denied. If the page does not provide the Personal Sharing entry, ask the project group administrator to verify the permission mode and data scope. Do not bypass the restrictions by switching tenant configurations.

​
Make Public to Project Group

Making a project group public allows users in the same project group with the appropriate viewing permissions to collaboratively troubleshoot tasks. Public status affects only task visibility and does not mean that recipients have been granted access permissions to the resource pool, Volume, datasets, or models.

​
Make Public When Creating

  1. Go to Training > Workloads.
  2. On the Personal Tasks tab, click Create.
  3. Select the Project Group to which the task belongs.
  4. Select Public within Project Group.
  5. After completing the task configuration, click Create to submit the task.
  6. In the task list or on the training task details page, verify the actual project group and visibility status.
  7. Ask recipients to use their own accounts to access the same tenant, region, cluster, and project group, and confirm that they can view the task details and required logs.
If a task has multiple retries, automatically fault-tolerant associated tasks, or diagnostic tasks, also ensure that the recipient can access the specific attempt that needs investigation.

​
Modify Visibility of an Existing Task

  1. Go to Training > Workloads.
  2. On the Personal Tasks tab, locate the target task and verify it by task ID, project group, and creation time.
  3. As needed, click Public to Project Group or Cancel Publication.
  4. Refresh the list or reopen the training task details page to confirm that the visibility status has been updated.
  5. Ask the recipient to revisit the task and verify the actual visible scope.
After canceling public access, if other users can still access the task, further check administrator permissions, broader data-scope permissions, or other authorization sources. Do not rely solely on the public status to determine whether access has been fully revoked.

​
Using Personal Shares

Personal sharing is available only in environments where the page provides the legacy Share entry. If RBAC is enabled in the current environment, use public Project Group sharing instead.
  1. Go to Training > Workloads.
  2. Open the Personal Tasks tab.
  3. Locate the target task and click Share.
  4. Select the recipient users. Saving submits the current complete list. When editing the shared-user list, retain users who still need access.
  5. After saving, refresh the list and verify the shared users.
  6. Recipients can go to the Shared Tasks tab in the same region and cluster to search for and view the task details and logs.
The sharing dialog requires that at least one user be retained. When revoking the last user, ask the Owner or an administrator to use and verify the platform-provided revocation method. Do not select an unrelated user to bypass validation. A personal share does not mean that authorization has been synchronized for all retry tasks. When investigating a specific retry or diagnostic task, verify access permissions separately using the specific task ID or attempt ID.

​
Collaborative Troubleshooting and Task Cloning

When troubleshooting collaboratively, provide the task link, task ID, region, cluster, project group, time of occurrence, latest attempt or container, and a sanitized error message. After obtaining access permissions, the recipient can first review the task details, events, and logs, then decide whether to clone and reproduce the issue. When reusing a configuration, select Clone. Before cloning the task, verify the following information again: Cloning creates a new task based on the original task configuration. It does not copy Volume data, checkpoint files, or process memory. To resume training, additionally configure the checkpoint access path and the loading logic in the training script.

​
Administrator Permissions Reference

In RBAC mode, users typically need functional permissions, authorized Project Groups, and an appropriate data scope to access Training. Write operations, such as stopping or deleting, also require the corresponding functional or API permissions. The scope of global is still limited to authorized Project Groups and does not indicate access across all Project Groups.
  • Write operations such as stopping and deletion also require authorization for the corresponding features.
  • For compatibility scenarios involving tenant administrators, historical tasks, and project group parsing exceptions, the actual server-side validation results shall prevail.
After adjusting permissions, have the recipient verify the task details, logs, and scope of necessary actions. High-risk permissions should first be validated on test resources. Do not verify permissions by stopping or deleting production tasks.

​
Frequently Asked Questions

First, verify the tenant, Region, Cluster, Project Group, and list filters. Then check whether the task has been made available to the Project Group or whether the recipient is viewing it on the Shared Tasks tab. If it is still not visible, ask an administrator to verify role permissions and the data scope.
This usually indicates that the recipient has view-only permissions. Write operations such as stopping and deleting require the corresponding feature permissions. The task owner can perform these actions, or you can apply through the organizational permission process.
Other users may still be able to access the task through administrator permissions, a broader data scope, or other authorization sources. After cancelling Public access, continue checking all authorization sources, and ask recipients to sign in again or refresh the page to verify.
Cloning does not copy the original user’s Volume or directory permissions. The recipient must separately request permissions for the Volume, directory, Dataset, or Model, and update the mount path and startup cmd accordingly.
Please provide the specific task ID, attempt ID, or associated task ID so that the visibility and log permissions for that attempt can be checked separately. Do not only verify whether the primary task list is visible.