Use storage mounts in Azure Container Apps

A container app has access to different types of storage. A single app can take advantage of more than one type of storage if necessary.

Note

Avoid using special characters in volume names to prevent deployment failures. For example, a volume named credentials.json contains a special character (.) which results in a deployment error.

Storage type	Description	Persistence	Usage example
Container-scoped storage	Ephemeral storage available to a running container	Data is available until container shuts down	Writing a local app cache.
Replica-scoped storage	Ephemeral storage for sharing files between containers in the same replica	Data is available until replica shuts down	The main app container writing log files that a sidecar container processes.
Azure Files	Permanent storage	Data is persisted to Azure Files	Writing files to a file share to make data accessible by other systems.

Note

Azure Container Apps doesn't support mounting file shares from Azure NetApp Files or Azure Blob Storage.

Ephemeral storage

A container app can read and write temporary data to ephemeral storage. Ephemeral storage can be scoped to a container or a replica. The total amount of container-scoped and replica-scoped storage available to each replica depends on the total number of vCPUs allocated to the replica.

vCPUs	Total ephemeral storage
0.25 or lower	1 GiB
0.5 or lower	2 GiB
1 or lower	4 GiB
Over 1	8 GiB

Container-scoped storage

A container can write to its own file system.

Container file system storage has the following characteristics:

• The storage is temporary and disappears when the container shuts down or restarts.
• Only processes running in the current container can see files written to this storage.

Replica-scoped storage

You can mount an ephemeral, temporary volume that's equivalent to EmptyDir (empty directory) in Kubernetes. This storage is scoped to a single replica. Use an EmptyDir volume to share data between containers in the same replica.

Replica-scoped storage has the following characteristics:

• Files persist for the lifetime of the replica.
  • If a container in a replica restarts, the files in the volume remain.
• Any init or app containers in the replica can mount the same volume.
• A container can mount multiple EmptyDir volumes.

To configure replica-scoped storage, first define an EmptyDir volume in the revision. Then define a volume mount in one or more containers in the revision.

Prerequisites

Requirement	Instructions
Azure account	If you don't have one, create an account for free.
Azure Container Apps environment	Create a container apps environment.

Configuration

When you configure replica-scoped storage by using the Azure CLI, you must use a YAML definition to create or update your container app.

1. To update an existing container app to use replica-scoped storage, export your app's specification to a YAML file named app.yaml.

   az containerapp show -n <APP_NAME> -g <RESOURCE_GROUP_NAME> -o yaml > app.yaml
   

2. Make the following changes to your container app specification.

   • Add a volumes array to the template section of your container app definition and define a volume. If you already have a volumes array, add a new volume to the array.
     • The name is an identifier for the volume.
     • Use EmptyDir as the storageType.
   • For each container in the template that you want to mount the volume, define a volume mount in the volumeMounts array of the container definition.
     • The volumeName is the name defined in the volumes array.
     • The mountPath is the path in the container to mount the volume.

   properties:
     managedEnvironmentId: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP_NAME>/providers/Microsoft.App/managedEnvironments/<ENVIRONMENT_NAME>
     configuration:
       activeRevisionsMode: Single
     template:
       containers:
       - image: <IMAGE_NAME1>
         name: my-container-1
         volumeMounts:
         - mountPath: /myempty
           volumeName: myempty
       - image: <IMAGE_NAME_2>
         name: my-container-2
         volumeMounts:
         - mountPath: /myempty
           volumeName: myempty
       volumes:
       - name: myempty
         storageType: EmptyDir
   

3. Update your container app by using the YAML file.

   az containerapp update --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> \
       --yaml app.yaml
   

For a full example, see the YAML specification.

To create a replica-scoped volume and mount it in a container, make the following changes to the container apps resource in an ARM template:

• Add a volumes array to the template section of your container app definition and define a volume. If you already have a volumes array, add a new volume to the array.
  • The name is an identifier for the volume.
  • Use EmptyDir as the storageType.
• For each container in the template that you want to mount the volume, define a volume mount in the volumeMounts array of the container definition.
  • The volumeName is the name defined in the volumes array.
  • The mountPath is the path in the container to mount the volume.

Example ARM template snippet:

{
  "apiVersion": "2022-03-01",
  "type": "Microsoft.App/containerApps",
  "name": "[parameters('containerappName')]",
  "location": "[parameters('location')]",
  "properties": {

    ...

    "template": {
      "revisionSuffix": "myrevision",
      "containers": [
        {
          "name": "main",
          "image": "[parameters('container_image')]",
          "resources": {
            "cpu": 0.5,
            "memory": "1Gi"
          },
          "volumeMounts": [
            {
              "mountPath": "/myempty",
              "volumeName": "myempty"
            }
          ]
        },
        {
          "name": "sidecar",
          "image": "[parameters('sidecar_image')]",
          "resources": {
            "cpu": 0.5,
            "memory": "1Gi"
          },
          "volumeMounts": [
            {
              "mountPath": "/myempty",
              "volumeName": "myempty"
            }
          ]
        }
      ],
      "scale": {
        "minReplicas": 1,
        "maxReplicas": 3
      },
      "volumes": [
        {
          "name": "myempty",
          "storageType": "EmptyDir"
        }
      ]
    }
  }
}

See the ARM template API specification for a full example.

To create a replica-scoped volume and mount it in a container, deploy a new revision of your container app by using the Azure portal.

1. In the Azure portal, go to your container app.

2. Select Revision management in the left menu.

3. Select Create new revision.

4. Select the container where you want to mount the volume.

5. In the Edit a container context pane, select the Volume mounts tab.

6. Under the Ephemeral storage section, create a new volume with the following information:

   • Volume name: A name for the ephemeral volume.
   • Mount path: The absolute path in the container to mount the volume.

7. Select Save to save changes and exit the context pane.

8. Select Create to create the new revision.

Azure Files volume

You can mount a file share from Azure Files as a volume in a container.

Important

Azure Container Apps supports only classic Azure file shares, which are created within a storage account (the Microsoft.Storage/storageAccounts/fileServices/shares resource type). Container Apps doesn't support the newer Microsoft.FileShares top-level resource type. If you try to mount a Microsoft.FileShares resource, the operation fails. To create a supported file share, see Create a classic Azure file share.

Azure Files storage has the following characteristics:

• Files written under the mount location are persisted to the file share.
• Files in the share are available via the mount location.
• Multiple containers can mount the same file share, including ones that are in another replica, revision, or container app.
• All containers that mount the share can access files written by any other container or method.
• More than one Azure Files volume can be mounted in a single container.

Azure Files supports both SMB (Server Message Block) and NFS (Network File System) protocols. You can mount an Azure Files share using either protocol. The file share you define in the environment must be configured with the same protocol used by the file share in the storage account.

For new SMB file mounts, use managed identity authentication (preview) instead of storage account keys. Container Apps uses a system-assigned or user-assigned managed identity assigned to the Container Apps environment, not the individual container app, to authenticate to Azure Files. This mode eliminates the need to retrieve, store, or rotate a storage account key. You must explicitly select managed identity authentication in the storage definition; existing storage account key mounts remain supported.

Managed identity authentication applies only to SMB shares. NFS shares use network-based access controls and don't use SMB authentication settings.

To enable Azure Files storage in your container, set up your environment and container app as follows:

• Create a storage definition in the Container Apps environment.
• If you're using NFS, your environment must be configured with a custom VNet and the storage account must be configured to allow access from the VNet. For more information, see NFS file shares in Azure Files .
• If you're using NFS, the storage account must not require encrypted NFS connections. Container Apps doesn't support encryption in transit for NFS file shares. If the storage account's Require Encryption in Transit for NFS setting is enabled, or if that setting isn't configured and Secure transfer required is enabled, the mount fails with an error such as mount.nfs: access denied by server while mounting. For more information, see Encryption in transit for NFS Azure file shares.
• If your environment is configured with a custom VNet, you must allow ports 445 and 2049 in the network security group (NSG) associated with the subnet.
• Define a volume of type AzureFile (SMB) or NfsAzureFile (NFS) in a revision.
• Define a volume mount in one or more containers in the revision.
• The Azure Files storage account used must be accessible from your container app's virtual network. For more information, see Grant access from a virtual network.

Prerequisites

Requirement	Instructions
Azure account	If you don't have one, create an account for free.
Azure Storage account	Create a storage account with a classic Azure file share.
Azure Container Apps environment	Create a container apps environment.
Managed identity for SMB authentication	Enable the environment's system-assigned managed identity or assign a user-assigned managed identity to the environment. See Manage environment identities.
Storage account settings for SMB managed identity authentication	Enable Managed Identity for SMB (SMBOAuth) on the storage account. Its SMB security settings must also allow Kerberos authentication.
Azure RBAC for SMB managed identity authentication	Assign the Storage File Data SMB MI Admin role to the selected environment identity at the storage account scope. See Assign a built-in RBAC role to the managed identity. To assign roles, you need Microsoft.Authorization/roleAssignments/write permission at that scope. Allow time for role assignments to propagate before mounting the share.

Configuration

When you configure a container app to mount an Azure Files volume by using Azure CLI, you must use a YAML definition to create or update your container app.

Install the latest Azure CLI and update the Container Apps extension:

az extension add --name containerapp --upgrade

For a step-by-step tutorial on mounting an SMB file share, see Create an Azure Files storage mount in Azure Container Apps.

1. Add a storage definition to your Container Apps environment.

   SMB

   Managed identity authentication (recommended)

   To use the environment's system-assigned managed identity, first enable it:

   az containerapp env identity assign --name my-env --resource-group my-group \
       --system-assigned
   

   Grant the identity the Storage File Data SMB MI Admin role on your storage account and enable Managed Identity for SMB as described in the prerequisites. Then create the storage definition:

   az containerapp env storage set --name my-env --resource-group my-group \
       --storage-name mystorage \
       --storage-type AzureFile \
       --azure-file-account-name <STORAGE_ACCOUNT_NAME> \
       --azure-file-identity system \
       --azure-file-share-name <STORAGE_SHARE_NAME> \
       --access-mode ReadWrite
   

   Replace <STORAGE_ACCOUNT_NAME> and <STORAGE_SHARE_NAME> with your storage account and file share names. The value system selects the environment's system-assigned managed identity.

   To use a user-assigned managed identity instead, assign it to the environment:

   az containerapp env identity assign --name my-env --resource-group my-group \
       --user-assigned <MANAGED_IDENTITY_RESOURCE_ID>
   

   Grant that identity the same role on the storage account. In the storage command, replace --azure-file-identity system with --azure-file-identity <MANAGED_IDENTITY_RESOURCE_ID>, using the identity's full Azure resource ID, not its client ID or principal ID.

   Don't combine --azure-file-identity with --azure-file-account-key or --azure-file-key-vault-secret-url. These authentication modes are mutually exclusive.

   Storage account key authentication (alternative)

   If you can't use managed identity authentication, you can use a storage account key instead:

   az containerapp env storage set --name my-env --resource-group my-group \
       --storage-name mystorage \
       --storage-type AzureFile \
       --azure-file-account-name <STORAGE_ACCOUNT_NAME> \
       --azure-file-account-key <STORAGE_ACCOUNT_KEY> \
       --azure-file-share-name <STORAGE_SHARE_NAME> \
       --access-mode ReadWrite
   

   Replace <STORAGE_ACCOUNT_NAME> and <STORAGE_ACCOUNT_KEY> with the name and key of your storage account. Replace <STORAGE_SHARE_NAME> with the name of the file share in the storage account.

   Valid values for --access-mode are ReadWrite and ReadOnly.

   NFS

   az containerapp env storage set --name my-env --resource-group my-group \
       --storage-name mystorage \
       --storage-type NfsAzureFile \
       --server <NFS_SERVER> \
       --azure-file-share-name <STORAGE_SHARE_NAME> \
       --access-mode ReadWrite
   

   Replace <NFS_SERVER> with the NFS server address in the format <STORAGE_ACCOUNT_NAME>.file.core.windows.net. For example, if your storage account name is mystorageaccount, the NFS server address is mystorageaccount.file.core.windows.net.

   Replace <STORAGE_SHARE_NAME> with the name of the file share in the format /<STORAGE_ACCOUNT_NAME>/<STORAGE_SHARE_NAME>. For example, if your storage account name is mystorageaccount and the file share name is myshare, the share name is /mystorageaccount/myshare.

   Valid values for --access-mode are ReadWrite and ReadOnly.

   Note

   To mount NFS Azure Files, you must use a Container Apps environment with a custom VNet. The Storage account must be configured to allow access from the VNet.

2. To update an existing container app to mount a file share, export your app's specification to a YAML file named app.yaml.

   az containerapp show -n <APP_NAME> -g <RESOURCE_GROUP_NAME> -o yaml > app.yaml
   

3. Make the following changes to your container app specification.

   • Add a volumes array to the template section of your container app definition and define a volume. If you already have a volumes array, add a new volume to the array.
     • The name is an identifier for the volume.
     • For storageType, use AzureFile for SMB, or NfsAzureFile for NFS. This value must match the storage type you defined in the environment.
     • For storageName, use the name of the storage you defined in the environment.
     • The mountOptions is a comma-separated string of mount options. For more information, see Use mountOptions settings in Azure Files.
     • The secrets list is a list of secrets to mount in the volume. For more information, see Mounting secrets in a volume.
   • For each container in the template that you want to mount Azure Files storage, define a volume mount in the volumeMounts array of the container definition.
     • The volumeName is the name defined in the volumes array.
     • The mountPath is the path in the container to mount the volume.
     • The subPath is the path in the volume to mount. If you don't specify this value, the volume root is mounted. For more information, see Sub path.
   SMB

   properties:
     managedEnvironmentId: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP_NAME>/providers/Microsoft.App/managedEnvironments/<ENVIRONMENT_NAME>
     configuration:
     template:
       containers:
       - image: <IMAGE_NAME>
         name: my-container
         volumeMounts:
         - volumeName: azure-files-volume
           mountPath: /my-files
           subPath: my-sub-path
       volumes:
       - name: azure-files-volume
         storageType: AzureFile
         storageName: mystorage
   

   NFS

   properties:
     managedEnvironmentId: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP_NAME>/providers/Microsoft.App/managedEnvironments/<ENVIRONMENT_NAME>
     configuration:
     template:
       containers:
       - image: <IMAGE_NAME>
         name: my-container
         volumeMounts:
         - volumeName: azure-files-volume
           mountPath: /my-files
           subPath: my-sub-path
       volumes:
       - name: azure-files-volume
         storageType: NfsAzureFile
         storageName: mystorage
   

4. Update your container app by using the YAML file.

   az containerapp update --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> \
       --yaml app.yaml
   

For a full example, see the YAML specification.

The following ARM template snippets demonstrate how to add an Azure Files share to a Container Apps environment and use it in a container app. For SMB managed identity authentication, enable or assign the identity on the environment and complete the storage account prerequisites before deploying the storage definition.

1. Add a storages child resource to the Container Apps environment.

   SMB

   Managed identity authentication (recommended)

   First, enable a managed identity on the Microsoft.App/managedEnvironments resource, not the Microsoft.App/containerApps resource. To enable the environment's system-assigned identity, add the following top-level identity property to your environment resource:

   {
     "identity": {
       "type": "SystemAssigned"
     }
   }
   

   Merge this fragment into your existing environment resource, keeping its other configuration. Use an environment API version that supports managed identities, such as 2026-03-02-preview. For the resource schema, see Microsoft.App/managedEnvironments.

   Enable Managed Identity for SMB (SMBOAuth) on the storage account and assign the environment identity the Storage File Data SMB MI Admin role at the storage account scope, as described in the prerequisites.

   Then use API version 2026-03-02-preview for the storage resource. Set properties.azureFile.identity to system to select the environment's system-assigned identity:

   {
     "type": "Microsoft.App/managedEnvironments/storages",
     "apiVersion": "2026-03-02-preview",
     "name": "[concat(parameters('environment_name'), '/myazurefiles')]",
     "properties": {
       "azureFile": {
         "accountName": "[parameters('storage_account_name')]",
         "identity": "system",
         "shareName": "[parameters('storage_share_name')]",
         "accessMode": "ReadWrite"
       }
     }
   }
   

   To use a user-assigned managed identity instead, add it to the environment's top-level identity property:

   {
     "identity": {
       "type": "UserAssigned",
       "userAssignedIdentities": {
         "[parameters('managed_identity_resource_id')]": {}
       }
     }
   }
   

   Define the managed_identity_resource_id parameter as a string containing the identity's full Azure resource ID. In the storage resource, set properties.azureFile.identity to [parameters('managed_identity_resource_id')] instead of system. Grant that identity the same role on the storage account.

   Preserve any identities already assigned to the environment. If you enable both identity types, use SystemAssigned,UserAssigned for the environment's identity.type and retain its userAssignedIdentities entries.

   Don't include accountKey or accountKeyVaultProperties when using managed identity authentication. For the storage resource schema, see Microsoft.App/managedEnvironments/storages.

   Storage account key authentication (alternative)

   To use a storage account key instead, set accountKey and omit identity. Define the storage_account_key template parameter as a secureString.

   {
     "type": "Microsoft.App/managedEnvironments/storages",
     "apiVersion": "2022-03-01",
     "name": "[concat(parameters('environment_name'), '/myazurefiles')]",
     "properties": {
       "azureFile": {
         "accountName": "[parameters('storage_account_name')]",
         "accountKey": "[parameters('storage_account_key')]",
         "shareName": "[parameters('storage_share_name')]",
         "accessMode": "ReadWrite"
       }
     }
   }
   

   These storage snippets assume that the environment and file share already exist. If you deploy them in the same template, add the environment and file share resources to the storage resource's dependsOn array. For managed identity authentication, also add a dependency on the role assignment if you create it in that template. A deployment dependency doesn't eliminate role assignment propagation delays.

   NFS

   {
     "type": "Microsoft.App/managedEnvironments",
     "apiVersion": "2023-05-01",
     "name": "[parameters('environment_name')]",
     "location": "[parameters('location')]",
     "properties": {
       "daprAIInstrumentationKey": "[parameters('dapr_ai_instrumentation_key')]",
       "appLogsConfiguration": {
         "destination": "log-analytics",
         "logAnalyticsConfiguration": {
           "customerId": "[parameters('log_analytics_customer_id')]",
           "sharedKey": "[parameters('log_analytics_shared_key')]"
         }
       },
       "workloadProfiles": [
         {
           "name": "Consumption",
           "workloadProfileType": "Consumption"
         }
       ],
       "vnetConfiguration": {
         "infrastructureSubnetId": "[parameters('custom_vnet_subnet_id')]",
         "internal": false
       }
     },
     "resources": [
       {
         "type": "storages",
         "name": "myazurefiles",
         "apiVersion": "2023-11-02-preview",
         "dependsOn": [
           "[resourceId('Microsoft.App/managedEnvironments', parameters('environment_name'))]"
         ],
         "properties": {
           "nfsAzureFile": {
             "server": "[concat(parameters('storage_account_name'), '.file.core.windows.net')]",
             "shareName": "[concat('/', parameters('storage_account_name'), '/', parameters('storage_share_name'))]",
             "accessMode": "ReadWrite"
           }
         }
       }
     ]
   }
   

   Note

   To mount NFS Azure Files, you must use a Container Apps environment with a custom VNet. The Storage account must be configured to allow access from the VNet.

2. Update the container app resource to add a volume and volume mount.

   SMB authentication is configured in the environment's storage definition. The app-level volume configuration is the same for managed identity and storage account key authentication. If you deploy the storage resource and container app in the same template, add the storage resource to the container app's dependsOn array.

   SMB

   {
     "apiVersion": "2023-05-01",
     "type": "Microsoft.App/containerApps",
     "name": "[parameters('containerappName')]",
     "location": "[parameters('location')]",
     "properties": {
   
       ...
   
       "template": {
         "revisionSuffix": "myrevision",
         "containers": [
           {
             "name": "main",
             "image": "[parameters('container_image')]",
             "resources": {
               "cpu": 0.5,
               "memory": "1Gi"
             },
             "volumeMounts": [
               {
                 "mountPath": "/myfiles",
                 "volumeName": "azure-files-volume",
                 "subPath": "my-sub-path"
               }
             ]
           }
         ],
         "scale": {
           "minReplicas": 1,
           "maxReplicas": 3
         },
         "volumes": [
           {
             "name": "azure-files-volume",
             "storageType": "AzureFile",
             "storageName": "myazurefiles"
           }
         ]
       }
     }
   }
   

   NFS

   {
     "apiVersion": "2023-11-02-preview",
     "type": "Microsoft.App/containerApps",
     "name": "[parameters('containerappName')]",
     "location": "[parameters('location')]",
     "properties": {
   
       ...
   
       "template": {
         "revisionSuffix": "myrevision",
         "containers": [
           {
             "name": "main",
             "image": "[parameters('container_image')]",
             "resources": {
               "cpu": 0.5,
               "memory": "1Gi"
             },
             "volumeMounts": [
               {
                 "mountPath": "/myfiles",
                 "volumeName": "azure-files-volume",
                 "subPath": "my-sub-path"
               }
             ]
           }
         ],
         "scale": {
           "minReplicas": 1,
           "maxReplicas": 3
         },
         "volumes": [
           {
             "name": "azure-files-volume",
             "storageType": "NfsAzureFile",
             "storageName": "myazurefiles"
           }
         ]
       }
     }
   }
   

   • Add a volumes array to the template section of your container app definition and define a volume. If you already have a volumes array, add a new volume to the array.
     • The name is an identifier for the volume.
     • For storageType, use AzureFile for SMB, or NfsAzureFile for NFS. This value must match the storage type you defined in the environment.
     • For storageName, use the name of the storage you defined in the environment.
     • The mountOptions is a comma-separated string of mount options. For more information, see Use mountOptions settings in Azure Files.
     • The secrets list is a list of secrets to mount in the volume. For more information, see Mounting secrets in a volume.
   • For each container in the template that you want to mount Azure Files storage, define a volume mount in the volumeMounts array of the container definition.
     • The volumeName is the name defined in the volumes array.
     • The mountPath is the path in the container to mount the volume.
     • The subPath (optional) is the path in the volume to mount. If you don't specify it, the volume root is mounted. For more information, see Sub path.

See the ARM template API specification for a full example.

To configure a volume mount for Azure Files storage in the Azure portal, add a file share to your Container Apps environment and then add a volume mount to your container app by creating a new revision. For new SMB mounts, select managed identity authentication.

1. In the Azure portal, navigate to your Container Apps environment.

2. For SMB managed identity authentication, select Settings > Identity and enable a system-assigned identity or add a user-assigned identity to the environment. Complete the storage account settings and role assignment described in the Azure Files prerequisites before adding the share.

3. In the navigation pane, under Settings, select Volume mounts.

4. Select Add.

5. Select Server Message Block (SMB) or Network File System (NFS), depending on the protocol used by your file share.

6. In the Add file share context pane, enter the following information:

   SMB

   • Name: A name for the environment's storage definition.
   • Storage account name: The name of the storage account that contains the file share.
   • Authentication: Select Managed identity (recommended).
   • Identity: Select the environment's system-assigned identity or a user-assigned identity assigned to the environment from the managed identity list. Select the identity that has the Storage File Data SMB MI Admin role on the storage account.
   • File share name: The name of the SMB file share.
   • Access mode: The access mode for the file share. Valid values are Read/Write and Read only.

   To use storage account key authentication instead, select Storage account key under Authentication and enter the storage account's access key. Choose one authentication method for the storage definition.

   NFS

   • Name: A name for the file share.
   • Server: The name of the server that contains the file share. This server name follows the format <STORAGE_ACCOUNT_NAME>.file.core.windows.net.
   • File share name: The name of the file share. This name follows the format /<STORAGE_ACCOUNT_NAME>/<FILE_SHARE_NAME>.
   • Access mode: The access mode for the file share. Valid values are Read/Write and Read only.

7. Select Add to exit the context pane.

8. Select Save to commit the changes.

9. Go to your container app.

10. In the navigation pane, under Application, select Revisions and replicas.

11. Select Create new revision.

12. In the Create and deploy new revision page, select the Volumes tab.

13. Select Add.

14. In the Add volume context pane, set the following values.

    • Volume type: Azure file volume.
    • Name: Enter a volume name.
    • File share name: Select the file share you created previously.
    • Mount options: Optionally, enter a comma-separated string of mount options. For more information, see Use mountOptions settings in Azure Files.

15. Select Add to exit the context pane.

16. In the Create and deploy new revision page, select the Container tab.

17. Select the container that you want to mount the volume in.

18. In the Edit a container context pane, select the Volume mounts tab.

19. Under Volume name, select the volume you created previously.

20. In Mount path, enter the absolute path in the container to mount the volume.

21. In Sub path (optional), enter the path in the volume to mount. If you don't specify this value, the volume root is mounted. For more information, see Sub path.

22. Select Save to save changes and exit the context pane.

23. Select Create to create the new revision.

Sub path

When you mount a file share from Azure Files, you can specify both a mount path and a sub path.

• Mount path: The path in the container where you want to mount the volume.
• Sub path: The path in the volume you want to mount.

The sub path is optional. If you don't specify a sub path, the volume root is mounted.

The sub path is a relative path from the volume root. Don't start the sub path with /. If you specify a sub path that starts with /, your container app might not start. For example, my-volume-folder is a valid sub path, but /my-volume-folder isn't.

The sub path can refer to either a folder or a file in the volume.

• If the sub path refers to a folder, the mount path should refer to an empty folder in the container.

• If the sub path refers to a file, the mount path should refer to a file that doesn't already exist in the container.

  For example, suppose the sub path is my-volume-folder/my-volume-file.txt, and the mount path is /my-container-folder/my-container-file.txt. The folder /my-container-folder should already exist in the container but shouldn't yet contain the file my-container-file.txt.

The system ignores any sub path trailing slashes.

Related content

• Tutorial: Create an Azure Files volume mount in Azure Container Apps
• Using subPath