An AgenticSpace is an isolated workspace within an AgenticFS that is allocated to a single agent end-user. It supports capacity quotas, file count quotas, access isolation, and performance isolation. This topic describes how to create, modify, and delete an AgenticSpace using the console or OpenAPI. It also explains how to mount an AgenticSpace on an ECS instance or in an Agent Sandbox.
Limitations
You must have an AgenticFS file system. Currently, only accounts on the allowlist can create AgenticFS file systems. To use this feature, submit a ticket.
A single AgenticFS supports up to 500,000 AgenticSpaces. A single AgenticSpace supports up to 1 PiB of capacity and 1 billion files.
Paths do not support renaming or symbolic links. Nested AgenticSpaces are not supported.
Only NFS v3 on Linux is supported. SMB and Windows are not supported. You can mount an AgenticSpace on any Linux compute node that supports NFS v3, such as an ECS instance or a Container Compute Service (ACS) Agent Sandbox.
Create an AgenticSpace
You can create an AgenticSpace by using the console or OpenAPI. When creating an AgenticSpace, you must specify a path and quotas. The following table describes the key parameters.
Parameter | Required | Description |
AgenticSpace Path (API parameter: | Yes | The absolute path of the directory in the file system. The path must start and end with a forward slash ( |
Size Limit (API parameter: | Yes | The capacity limit for the AgenticSpace. Unit: Byte. Valid range: 10 GiB to 1,024,000 GiB. Step: 1 GiB. |
File Count Limit (API parameter: | Yes | The file count limit for the AgenticSpace. Valid range: 10,000 to 1,000,000,000 (1 billion). Step: 1. |
Method 1: Use the console
Log on to the NAS console and navigate to the AgenticSpace tab of the target AgenticFS file system.
Click Create AgenticSpace, specify the parameters as described in the table above, and then submit the form.
Method 2: Use OpenAPI
Call the CreateAgenticSpace operation. The following code provides a request example:
POST /AgenticSpace/Create HTTP/1.1
Host: nas.aliyuncs.com
Content-Type: application/json
{
"FileSystemId":"031*******",
"FileSystemPath":"/test5/",
"RegionId":"cn-shanghai",
"Azone":"cn-shanghai-f",
"Quota.SizeLimit":"110595407872",
"Quota.FileCountLimit":100004
}View and modify quotas
In the AgenticSpace list, you can view the following fields: Directory Path, zone, Capacity Quota (GiB), Current Capacity (GiB), File Count Quota, Current File Count, and creation time. To adjust the capacity and file count quotas, click Edit in the Actions column for the target AgenticSpace. You can also call the SetAgenticSpaceQuota operation.
The new quota must be greater than the current usage. Otherwise, the modification fails.
Access points
An access point is an NFS protocol entry point for AgenticFS that provides a mount target, permission checks, and traffic isolation. AgenticFS supports access points at two levels of granularity:
AgenticFS level: Targets the AgenticFS root directory. This level is intended for trusted scenarios, such as platform operations and batch management of AgenticSpaces via OpenAPI. Mounting the AgenticFS root directory is not supported in the current version.
AgenticSpace level: The access point targets a single AgenticSpace. After mounting, the client's view is restricted to the corresponding AgenticSpace. This is the standard entry point for launching agent sessions.
RAM access authorization
Access points support RAM-based access policies to control which applications and RAM users or roles can access specific AgenticFS file systems and AgenticSpaces. We recommend granting the nas:ClientMount permission to a RAM user and using the nas:AccessPointArn condition to restrict which access points they can mount. The following policy is an example:
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": [
"nas:ClientMount"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"nas:AccessPointArn": "<accesspointARN>"
}
}
}
]
}The following table describes key parameters.
Parameter | Description |
nas:AccessPointArn | The ARN of the access point. Example: |
To prevent unauthorized access to other AgenticSpaces, we recommend using separate RAM roles and access points for different agent applications and end-users.
Mount an AgenticSpace
Get the mount target from the AgenticSpace list.
On your ECS (Linux) instance, install the NFS client:
# CentOS / Alibaba Cloud Linux sudo yum install -y nfs-utils # Ubuntu / Debian sudo apt-get install -y nfs-commonRun the mount command and verify the result by using the
df -hcommand:sudo mount -t ALINAS -o tls,vers=3,ram <mount-target>:/ /mnt
In the current version, only AgenticSpaces can be mounted. Mounting the AgenticFS root directory is not supported.
Mount an AgenticSpace
An AgenticSpace can be mounted in two typical scenarios: mounting directly on an ECS instance by using the ALINAS client, or mounting as a CSI volume in an ACS cluster by using an Agent Sandbox (SandboxClaim). Both scenarios require the RAM authorization described in the Access points section. The compute node must also be in the same VPC as the AgenticFS access point.
Note: In the current version, only AgenticSpaces can be mounted. Mounting the AgenticFS root directory is not supported.
Scenario 1: Mount on an ECS instance
Get the mount target from the AgenticSpace list. The mount target is the NFS domain name for the AgenticSpace access point. When mounted, your view is restricted to that AgenticSpace.
On your ECS (Linux) instance, install the NFS client:
# CentOS / Alibaba Cloud Linux sudo yum install -y nfs-utils # Ubuntu / Debian sudo apt-get install -y nfs-commonConfigure the RAM AK/SK credential for access point authentication:
sudo mkdir -p /etc/aliyun/alinas sudo tee /etc/aliyun/alinas/.credentials > /dev/null <<EOF [NASCredentials] accessKeyID = <YourAccessKeyID> accessKeySecret = <YourAccessKeySecret> EOFRun the mount command and verify the result using the
df -hcommand:sudo mount -t ALINAS -o tls,vers=3,ram <mount-target>:/ /mnt/agenticspace
Scenario 2: Mount in an Agent Sandbox via CSI
This scenario applies to containerized agent instances that are launched in an ACS cluster by using an Agent Sandbox (SandboxSet/SandboxClaim). The AgenticSpace is mounted as a persistent workspace in the sandbox container.
Prerequisites
An active ACS cluster is in the same VPC as the AgenticFS access point.
You have installed the
ack-agent-sandbox-controllercomponent in the ACS cluster and configured the sandbox warm pool by using a SandboxSet. For more information, see the Container Service documentation about creating an Agent Sandbox.The RAM user for mounting is authorized according to the sample policy in the Access points section.
Step 1: Create a Secret and a PersistentVolume (PV)
Store the RAM user's AK/SK in a Secret and create a PersistentVolume (PV) that points to the AgenticSpace access point:
apiVersion: v1
kind: Secret
metadata:
name: nas-secret
namespace: sandbox-system
stringData:
akId: <YourAccessKeyID>
akSecret: <YourAccessKeySecret>
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: nas-agenticspace-pv
labels:
alicloud-pvname: nas-agenticspace-pv
spec:
capacity:
storage: 500Gi
accessModes:
- ReadWriteMany
csi:
driver: nasplugin.csi.alibabacloud.com
volumeHandle: nas-agenticspace-pv
nodePublishSecretRef:
name: nas-secret
namespace: sandbox-system
volumeAttributes:
server: "<AgenticSpace_access_point_domain>"
path: "/"
vers: "3"
mountprotocol: "alinas"
filesystemtype: "standard"
mountOptions:
- tls,ram
- vers=3Apply the configuration, then run kubectl get pv to confirm that the PV status is Available.
Step 2: Mount by using a SandboxClaim
In the SandboxClaim, reference the PV created in the previous step by using dynamicVolumesMount and specify the mount path in the container:
apiVersion: agents.kruise.io/v1alpha1
kind: SandboxClaim
metadata:
name: code-interpreter-claim
namespace: default
spec:
templateName: code-interpreter # SandboxSet name
replicas: 1
claimTimeout: 5m
ttlAfterCompleted: 15m
dynamicVolumesMount:
- pvName: nas-agenticspace-pv
mountPath: "/workspace"Step 3: Verify the mount
Find the Pod that corresponds to the SandboxClaim and enter the container to verify the mount path:
kubectl get sandbox -n default -l agents.kruise.io/claim-name=code-interpreter-claim
kubectl -n default exec -it <sandbox-pod-name> -- sh
df -h | grep workspaceDelete an AgenticSpace
Before you delete an AgenticSpace, unmount all its access points and back up your data. This operation is irreversible.
To delete an AgenticSpace, click Delete in the Actions column for that space in the management list, or call the DeleteAgenticSpace operation. After an AgenticSpace is deleted, you can create a new one at the same path.
FAQ
Why do I receive an "access denied" error when mounting?
Ensure the ECS instance and the AgenticFS are in the same VPC.
Why do I receive a "no space" error when writing data?
This error occurs when you reach the capacity or file count quota limit. To resolve this, increase the quota or delete files in the AgenticSpace to free up space.
Can I migrate an AgenticSpace across different AgenticFS file systems?
This is not currently supported. You must create a new AgenticSpace and copy the data at the application layer.
Can I use SMB or Windows to access an AgenticSpace?
AgenticFS currently supports only the NFS v3 protocol and Linux clients.