Mount Azure Storage as a local share in App Service

Note

Mounting Azure Storage as a local share for App Service on Windows code is currently in preview.

This guide shows how to mount Azure Storage Files as a network share in Windows code in App Service. Only Azure Files Shares and Premium Files Shares are supported. The benefits of custom-mounted storage include:

  • Configure persistent storage for your App Service app and manage the storage separately.
  • Make static content like video and images readily available for your App Service app.
  • Write application log files or archive older application log to Azure File shares.
  • Share content across multiple apps or with other Azure services.

The following features are supported for Windows code:

This guide shows how to mount Azure Storage Files as a network share in a Windows container in App Service. Only Azure Files Shares and Premium Files Shares are supported. The benefits of custom-mounted storage include:

  • Configure persistent storage for your App Service app and manage the storage separately.
  • Make static content like video and images readily available for your App Service app.
  • Write application log files or archive older application log to Azure File shares.
  • Share content across multiple apps or with other Azure services.
  • Mount Azure Storage in a Windows container in a Standard tier or higher plan, including Isolated (App Service environment v3).

The following features are supported for Windows containers:

This guide shows how to mount Azure Storage as a network share in a built-in Linux container or a custom Linux container in App Service. See the video how to mount Azure Storage as a local share. The benefits of custom-mounted storage include:

  • Configure persistent storage for your App Service app and manage the storage separately.
  • Make static content like video and images readily available for your App Service app.
  • Write application log files or archive older application log to Azure File shares.
  • Share content across multiple apps or with other Azure services.

The following features are supported for Linux containers:

Prerequisites

Note

Azure Storage is non-default storage for App Service and billed separately, not included with App Service.

Limitations

  • Storage firewall is supported only through private endpoints and service endpoints (when VNET integration is used).
  • Azure blobs are not supported when configuring Azure storage mounts for Windows code apps deployed to App Service.
  • FTP/FTPS access to mounted storage not supported (use Azure Storage Explorer).
  • Mapping /mounts, mounts/foo/bar, /, and /mounts/foo.bar/ to custom-mounted storage is not supported (you can only use /mounts/pathname for mounting custom storage to your web app.)
  • Storage mounts cannot be used together with clone settings option during deployment slot creation.
  • Storage mounts are not backed up when you back up your app. Be sure to follow best practices to back up the Azure Storage accounts.
  • Storage mounts are not supported for native Windows (non-containerized) apps.
  • Azure blobs are not supported.
  • Storage firewall is supported only through private endpoints and service endpoints (when VNET integration is used).
  • FTP/FTPS access to mounted storage not supported (use Azure Storage Explorer).
  • Mapping [C-Z]:\, [C-Z]:\home, /, and /home to custom-mounted storage is not supported.
  • Storage mounts cannot be used together with clone settings option during deployment slot creation.
  • Storage mounts are not backed up when you back up your app. Be sure to follow best practices to back up the Azure Storage accounts.

Note

Ensure ports 80 and 445 are open when using Azure Files with VNET integration.

  • Storage firewall is supported only through service endpoints and private endpoints (when VNET integration is used). Custom DNS support is currently unavailable when the mounted Azure Storage account uses a private endpoint.
  • FTP/FTPS access to custom-mounted storage is not supported (use Azure Storage Explorer).
  • Azure CLI, Azure PowerShell, and Azure SDK support is in preview.
  • Mapping / or /home to custom-mounted storage is not supported.
  • Don't map the custom storage mount to /tmp or its subdirectories as this may cause timeout during app startup.
  • Storage mounts cannot be used together with clone settings option during deployment slot creation.
  • Storage mounts are not backed up when you back up your app. Be sure to follow best practices to back up the Azure Storage accounts.

Note

When VNET integration is used, ensure the following ports are open:

  • Azure Files: 80 and 445.
  • Azure Blobs: 80 and 443.

Mount storage to Windows code

Mount storage to Windows container

Mount storage to Linux container

  1. In the Azure portal, navigate to the app.

  2. From the left navigation, click Configuration > Path Mappings > New Azure Storage Mount.

  3. Configure the storage mount according to the following table. When finished, click OK.

    Setting Description
    Name Name of the mount configuration. Spaces are not allowed.
    Configuration options Select Basic if the storage account is not using private endpoints. Otherwise, select Advanced.
    Storage accounts Azure Storage account. It must contain an Azure Files share.
    Share name Files share to mount.
    Access key (Advanced only) Access key for your storage account.
    Mount path Directory inside your file/blob storage that you want to mount. Only /mounts/pathname is supported.
    Setting Description
    Name Name of the mount configuration. Spaces are not allowed.
    Configuration options Select Basic if the storage account is not using private endpoints. Otherwise, select Advanced.
    Storage accounts Azure Storage account. It must contain an Azure Files share.
    Share name Files share to mount.
    Access key (Advanced only) Access key for your storage account.
    Mount path Directory inside your file/blob storage that you want to mount. Do not use a root directory ([C-Z]:\ or /) or the home directory ([C-Z]:\home, or /home).
    Setting Description
    Name Name of the mount configuration. Spaces are not allowed.
    Configuration options Select Basic if the storage account is not using service endpoints or private endpoints. Otherwise, select Advanced.
    Storage accounts Azure Storage account.
    Storage type Select the type based on the storage you want to mount. Azure Blobs only supports read-only access.
    Storage container or Share name Files share or Blobs container to mount.
    Access key (Advanced only) Access key for your storage account.
    Mount path Directory inside the Linux container to mount to Azure Storage. Do not use / or /home.

Note

Adding, editing, or deleting a storage mount causes the app to be restarted.

Test the mounted storage

To validate that the Azure Storage is mounted successfully for the app:

  1. Open an SSH session into the container.

  2. In the SSH terminal, execute the following command:

    df –h 
    
  3. Check if the storage share is mounted. If it's not present, there's an issue with mounting the storage share.

  4. Check latency or general reachability of the storage mount with the following command:

    tcpping Storageaccount.file.core.windows.net 
    

Best practices

  • To avoid potential issues related to latency, place the app and the Azure Storage account in the same Azure region. Note, however, if the app and Azure Storage account are in same Azure region, and if you grant access from App Service IP addresses in the Azure Storage firewall configuration, then these IP restrictions are not honored.

  • In the Azure Storage account, avoid regenerating the access key that's used to mount the storage in the app. The storage account contains two different keys. Use a stepwise approach to ensure that the storage mount remains available to the app during key regeneration. For example, assuming that you used key1 to configure storage mount in your app:

    1. Regenerate key2.
    2. In the storage mount configuration, update the access the key to use the regenerated key2.
    3. Regenerate key1.
  • If you delete an Azure Storage account, container, or share, remove the corresponding storage mount configuration in the app to avoid possible error scenarios.

  • The mounted Azure Storage account can be either Standard or Premium performance tier. Based on the app capacity and throughput requirements, choose the appropriate performance tier for the storage account. See the scalability and performance targets for Files.

  • If your app scales to multiple instances, all the instances connect to the same mounted Azure Storage account. To avoid performance bottlenecks and throughput issues, choose the appropriate performance tier for the storage account.

  • It's not recommended to use storage mounts for local databases (such as SQLite) or for any other applications and components that rely on file handles and locks.

  • If you initiate a storage failover and the storage account is mounted to the app, the mount will fail to connect until you either restart the app or remove and add the Azure Storage mount.

  • When using Azure Storage private endpoints with the app, you need to enable the Route All setting.

  • When VNET integration is used, ensure app setting, WEBSITE_CONTENTOVERVNET is set to 1 and the following ports are open:

    • Azure Files: 80 and 445
  • The mounted Azure Storage account can be either Standard or Premium performance tier. Based on the app capacity and throughput requirements, choose the appropriate performance tier for the storage account. See the scalability and performance targets for Files

  • To avoid potential issues related to latency, place the app and the Azure Storage account in the same Azure region. Note, however, if the app and Azure Storage account are in same Azure region, and if you grant access from App Service IP addresses in the Azure Storage firewall configuration, then these IP restrictions are not honored.

  • In the Azure Storage account, avoid regenerating the access key that's used to mount the storage in the app. The storage account contains two different keys. Use a stepwise approach to ensure that the storage mount remains available to the app during key regeneration. For example, assuming that you used key1 to configure storage mount in your app:

    1. Regenerate key2.
    2. In the storage mount configuration, update the access the key to use the regenerated key2.
    3. Regenerate key1.
  • If you delete an Azure Storage account, container, or share, remove the corresponding storage mount configuration in the app to avoid possible error scenarios.

  • The mounted Azure Storage account can be either Standard or Premium performance tier. Based on the app capacity and throughput requirements, choose the appropriate performance tier for the storage account. See the scalability and performance targets for Files.

  • If your app scales to multiple instances, all the instances connect to the same mounted Azure Storage account. To avoid performance bottlenecks and throughput issues, choose the appropriate performance tier for the storage account.

  • It's not recommended to use storage mounts for local databases (such as SQLite) or for any other applications and components that rely on file handles and locks.

  • If you initiate a storage failover and the storage account is mounted to the app, the mount will fail to connect until you either restart the app or remove and add the Azure Storage mount.

  • When using Azure Storage private endpoints with the app, you need to enable the Route All setting.

    Note

    In App Service environment V3, the Route All setting is disabled by default and must be explicitly enabled.

  • To avoid potential issues related to latency, place the app and the Azure Storage account in the same Azure region. Note, however, if the app and Azure Storage account are in same Azure region, and if you grant access from App Service IP addresses in the Azure Storage firewall configuration, then these IP restrictions are not honored.

  • The mount directory in the custom container should be empty. Any content stored at this path is deleted when the Azure Storage is mounted (if you specify a directory under /home, for example). If you are migrating files for an existing app, make a backup of the app and its content before you begin.

  • Mounting the storage to /home is not recommended because it may result in performance bottlenecks for the app.

  • In the Azure Storage account, avoid regenerating the access key that's used to mount the storage in the app. The storage account contains two different keys. Use a stepwise approach to ensure that the storage mount remains available to the app during key regeneration. For example, assuming that you used key1 to configure storage mount in your app:

    1. Regenerate key2.
    2. In the storage mount configuration, update the access the key to use the regenerated key2.
    3. Regenerate key1.
  • If you delete an Azure Storage account, container, or share, remove the corresponding storage mount configuration in the app to avoid possible error scenarios.

  • The mounted Azure Storage account can be either Standard or Premium performance tier. Based on the app capacity and throughput requirements, choose the appropriate performance tier for the storage account. See the scalability and performance targets that correspond to the storage type:

  • If your app scales to multiple instances, all the instances connect to the same mounted Azure Storage account. To avoid performance bottlenecks and throughput issues, choose the appropriate performance tier for the storage account.

  • It's not recommended to use storage mounts for local databases (such as SQLite) or for any other applications and components that rely on file handles and locks.

  • When using Azure Storage private endpoints with the app, you need to enable the Route All setting.

  • If you initiate a storage failover and the storage account is mounted to the app, the mount will fail to connect until you either restart the app or remove and add the Azure Storage mount.

Next steps