> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scitix.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Manage Training sharing and Project Group visibility

> Learn how to use Project Group public sharing or personal sharing to let other users view, troubleshoot, or clone Training, and verify resource, volume, and write permissions.

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.

> [!TIP]
>
> * 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

| Collaboration Goal | Recommended Approach | Key Considerations |
| - | - | - |
| Allow other users to view task configurations, status, and logs | Use **Make Project Group Public** or **Personal Share**, depending on what the current environment supports. | Both parties must be in the correct tenant, Region, Cluster, and Project Group. Use task IDs to distinguish tasks with the same name or retried tasks. |
| Allow other users to stop, delete, or manage tasks | Have the task owner perform the action, or request the required feature permissions and data scope. | Visibility controls only whether a task can be viewed; it does not automatically grant write permissions for actions such as Stop or Delete. |
| Reuse a task configuration | After viewing the task, use **Clone** to create a new task. | Cloning carries over the configuration, but the recipient should use their own resources, output directory, and accessible storage. |
| Read data, models, checkpoints, or output files | Request access permissions separately for the Volume, directory, Dataset, or Model. | Task sharing does not automatically grant read/write permissions for storage directories. For Volume directory authorization, see [Configure Volume Directory-Level Permissions](/siverse/resources/configure-volume-directory-permissions.md). |

## 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.

| Current environment | Available methods | Where to use |
| - | - | - |
| Project Group role-based access control (RBAC) is enabled | Public within Project Group or share with a Project Group. | Configure this when creating a task, or adjust the visibility of an existing task in the task list or training task details page. |
| RBAC is not enabled, and the page provides a personal sharing entry | Share with specified users. | Find the task on the **Personal Tasks** tab and click **Share**. |

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:

| Check Item | Description |
| - | - |
| Image | Ensure that the image version is correct and that the target Region and Cluster can pull the image. |
| Compute Resources | Ensure that the recipient has an available resource pool, instance specification, and the required quota. |
| Data and Storage | Ensure that the Volume, directories, Dataset, Model, and checkpoint are accessible to the recipient. |
| Output Path | Use a separate output directory to avoid overwriting the original task results. |
| Startup Command | Replace user-specific paths, credentials, and non-reusable parameters. |

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.

| Data Scope | Tasks viewable within the authorized Project Group |
| - | - |
| Personal | Tasks you created. |
| Public | Tasks marked as public. |
| Personal and Public | Tasks you created and public tasks. |
| All (global) | Tasks within the authorized Project Group. |

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

> **What should I do if the recipient cannot find a task?**
>
> 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.

> **Why can't users access a task even after receiving its link?**
>
> A task link is used only to locate the task and does not grant access permissions. First grant visibility through Project Group sharing or personal sharing, then confirm that the recipient has the required permissions for the corresponding Project Group and data scope.

> **What should I do if I can view a task but cannot stop or delete it?**
>
> 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.

> **Why can other users still see the task after it is no longer Public?**
>
> 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.

> **Why is the original storage unavailable after cloning a task?**
>
> 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.

> **What should I do if some retry logs are not visible?**
>
> 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.

## Related Documentation

* [Create Training](/siverse/training/create-training-tasks.md)
* [Find, View, and Manage Training Tasks](/siverse/training/view-and-manage-training-tasks.md)
* [Configure Volume directory-level permissions](/siverse/resources/configure-volume-directory-permissions.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.