iTranslated by AI
Mounting Azure Files in Azure Container Apps
Introduction
This article records my experience mounting an Azure Files volume in Azure Container Apps.
It is a verification of the following article:
Steps
Azure Files supports both SMB (Server Message Block) and NFS (Network File System) protocols. You can mount an Azure Files share using either protocol.
It states that both are supported. While the choice depends on requirements, I will use NFS since this ACA uses a custom VNet.
- For workloads that require fast permanent storage and multiple concurrent small random reads/writes, make sure to go for Azure Files Share Premium tier
- For apps that write/read large sequential files, Azure Files Share (standard) might be a good option
Common scenarios
SMB file shares are used by many applications for end-user file sharing, and file sharing to back up databases and applications. SMB file shares are often used in the following scenarios:
- End-user file shares, such as team shares and home directories
- Backing storage for Windows-based applications (such as SQL Server databases, line-of-business applications created for Win32 or .NET local file system APIs)
- Developing new applications and services (especially if the application or service has random I/O and hierarchical storage requirements)
Common scenarios
NFS file shares are often used in the following scenarios:Backing storage for Linux/UNIX-based applications, such as line-of-business applications written using Linux or POSIX file system APIs (even if POSIX compliance isn't required).
Workloads that require POSIX-compliant file shares, case sensitivity, or Unix-style permissions (UID/GID).
Developing new applications and services (especially if the application or service has random I/O and hierarchical storage requirements).
I asked Copilot which is better, SMB or NFS
Here is a tutorial for using SMB
Creation
Following the documentation, I created a Storage Account with Premium SKU and granted access from the Env's subnet.
- Add volume to Env
- Add mount to App
Regarding mount options, I referred to the following document and will set them accordingly.
mountOptions:
- nconnect=4 # improves performance by enabling multiple connections to share
- noresvport # improves availability
- actimeo=30 # reduces latency for metadata-heavy workloads
Immediately, I couldn't start due to a mount error...
Container 'aca-in-vnet-nginx' was terminated with exit code '1' and reason 'VolumeMountFailure'. Shell command exited with non-zero status code. StatusCode = 32 | StdOut = | StdErr = mount.nfs: access denied by server while mounting acastorage2026.file.core.windows.net:/acastorage2026/nginx-share
The solution was written here.
Remove “Secure Transfer Required”
On the Storage Accountt, go to Settings > Configuration and disable Secure transfer required. If this is not done, you’ll see a volume mount failure later on with a message of mount.nfs: access denied by server while mounting in Container App system logs
Since it's also stated as below, I'll try disabling it for now.
We recommend requiring secure transfer for all storage accounts, except when NFS Azure file shares are used with network-level security.
The mount was successful, and the container started.
Verification from another replica
As expected, it is mounted, and file sharing is confirmed.
Trying subPath
A subpath is a path relative to the volume root. Do not start a subpath with /. Specifying a subpath that starts with / may cause the Container App to not start. For example,
my-volume-folderis a valid subpath, but/my-volume-folderis not.
A subpath can refer to a folder or a file within the volume.
- If the subpath refers to a folder, the mount path must refer to an empty folder in the container.
- If the subpath refers to a file, the mount path must refer to a file that does not yet exist in the container.
For example, assume a subpathmy-volume-folder/my-volume-file.txtand a mount path/my-container-folder/my-container-file. The folder/my-container-foldermust already exist in the container, but it should not yet contain the filemy-container-file.txt.
The system ignores subpaths with a trailing slash.
subPath itself is a Kubernetes mechanism, but the documentation is unclear, so I'll try it out.
As a preliminary step, using the mount from earlier, I'll prepare files and directories on Azure Files as follows:
root@aca-in-vnet-nginx--0000012-5cc9d54bcf-5lqbw:/azurefiles# tree
.
|-- subDir1
| `-- ORIGINAL_PATH_IS_SUBDIR1.txt
|-- subDir2
| |-- ORIGINAL_PATH_IS_SUBDIR2.txt
| `-- subDir2File1.txt
|-- subDir3
| |-- ORIGINAL_PATH_IS_SUBDIR3.txt
| `-- subDir31
| |-- ORIGINAL_PATH_IS_SUBDIR31.txt
| `-- subDir31File1.txt
`-- testFromApp.txt
5 directories, 7 files
I'll try mounting each with a specified subPath.
Results
This means it's likely that you can also specify subdirectories and files for mounting.
This description seems to be the source of confusion.
For example, assume a subpath
my-volume-folder/my-volume-file.txtand a mount path/my-container-folder/my-container-file. The folder/my-container-foldermust already exist in the container, but it should not yet contain the filemy-container-file.txt.
I think something is wrong because .txt is missing.
It should probably correctly state: "...and a mount path /my-container-folder/my-container-file.txt."
I've submitted a PR.
Discussion
This usage is similar to App Service mounts.
Other
Troubleshooting articles regarding mounting:
Discussion