Prepare Azure storage for Mount Points

Last published : Nov 09, 2026
Azure Mount Points give a project shared, persistent file storage on Azure Files, mounted into its workspaces at /mnt/<mount-point-name>. Every workspace that mounts one reads and writes the same files.
Project owners can create a Mount Point in two ways:
  • Azure Files (Create New) provisions a new file share from a storage class.
  • Azure Files (Attach Existing) connects to a file share that already exists, either through a storage class that names the share, or by entering the storage account, its access key, and the share name.
This page describes what Citrix SecurSpaces™ needs from the cluster and from Azure for each of these. To turn the feature on, see Mount point storage. For the project owner's steps, see Mount Points.
Related information
Mount point storage

Provide storage classes for Create New

A storage class can back Azure Files (Create New) when its provisioner is file.csi.azure.com and it has no shareName parameter. The AKS built-in classes azurefile-csi and azurefile-csi-premium qualify.
  • The Storage Class list shows each class by its skuName parameter, for example Premium_LRS. Give each class a different skuName, so project owners can tell them apart.
  • To let project owners increase a Mount Point's Volume Capacity later, set allowVolumeExpansion: true. Capacity can be increased, but never decreased.
  • With the AKS built-in classes, reclaimPolicy is Delete. Deleting a Create New Mount Point then deletes its file share and the data in it.

Provide storage classes for Attach Existing

A storage class that has a shareName parameter names one existing file share. Project owners see it under the Storage Class connection method of Azure Files (Attach Existing), not under Create New.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: team-datasets
provisioner: file.csi.azure.com
parameters:
  skuName: Premium_LRS
  shareName: datasets
reclaimPolicy: Retain
Warning
Set reclaimPolicy: Retain on every storage class that names an existing share. Deleting the Mount Point removes only its claim on the share, and the storage class's reclaim policy decides what happens next. Kubernetes uses Delete when no policy is set.

Prepare a manual connection

With the Manual Connection method, a project owner enters the Storage Account, its Access Key, and the File Share Name. No storage class is needed.
  • SecurSpaces checks the storage account, key, and share when the Mount Point is created, and again whenever the key is changed. The check runs from the SecurSpaces control plane over HTTPS, to https://<storage-account>.file.core.windows.net. The control plane must be able to reach that address. Only the Azure public cloud is supported.
  • Workspaces mount the share over SMB, so the cluster nodes must be able to reach the storage account on port 445.
  • The access key is stored only in the cluster, as a Kubernetes Secret. It isn't stored in the SecurSpaces database, and it's deleted with the Mount Point.
If the check fails, the project owner sees that the key is invalid, that the share wasn't found, or that the storage account couldn't be reached.

Change the access key

The access key is the only connection detail that can be changed after a Mount Point is created.
  1. In Azure, make sure the new key is active. For example, regenerate the storage account's second key.
  2. In SecurSpaces, edit the Mount Point and enter the new key in Access Key. SecurSpaces checks the key, then updates it in the cluster.
  3. Only then, revoke or regenerate the old key in Azure.
If you revoke the old key first, every workspace that uses the share loses access until the new key is entered.

How the share is mounted

Azure Files Mount Points use SMB. Every file and folder is owned by the workspace user, with user and group ID 1000. Permissions come from the mount options rather than from the share:
Access Folders Files
Read/Write 0755 0644
Read Only 0555 0444
Permissions changed inside a workspace aren't kept. SMB on Azure Files encrypts traffic in transit, so no extra mount option is needed for encryption.

What deleting a Mount Point removes

Mode What SecurSpaces removes The file share
Create New The claim. The storage class's reclaim policy then applies. Deleted with the AKS built-in classes, whose policy is Delete.
Attach Existing, Storage Class The claim. The storage class's reclaim policy then applies. Kept when the storage class uses Retain.
Attach Existing, Manual Connection The claim, the volume, and the Secret that holds the access key. Kept.
A Mount Point can't be deleted while a workspace, a workspace template, or a deleted workspace that can still be restored uses it. For more information, see Mount point limits and behavior.

What isn't supported

  • Azure Files over NFS.
  • Azure Blob Storage, including Azure Data Lake Storage (ADLS) Gen2. The Enable Azure Blob Storage switch can't be turned on.
  • A cluster with both Azure and AWS Mount Point storage classes. Mount Points are then unavailable. See Mount point storage.
  • Mount Points in a region other than the primary region.