Theoretical Foundation: Create and Configure a File Share in Azure Files

1. Initial Intuition

In any company, there's a need for a shared network drive: a folder that multiple computers and servers access simultaneously, as if it were a local folder, but is actually on a central server. In the corporate on-premises world, this is done with Windows file servers (via SMB protocol) or Linux servers (via NFS).

Azure Files is exactly this file server hosted in the cloud. It exposes file shares that any machine (Windows, Linux, macOS, Azure VM, on-premises server) can mount as a network drive, without having to manage the underlying server.

A file share in Azure Files is equivalent to a "shared drive" or "network folder" that you mount with a drive letter (Z:, Y:) on Windows or as a mount point on Linux.

2. Context

2.1 Why Azure Files exists

Before Azure Files, migrating workloads to the cloud that depended on file shares was a difficult problem. Legacy applications use standard file system calls (open, read, write, rename) that don't work against blob storage REST APIs.

Azure Files solves this by exposing a real file system via industry-standard protocols, allowing applications to be migrated without code changes.

2.2 Position in the Azure ecosystem

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

2.3 Main use cases

Lift-and-shift of legacy applications: Applications that depend on \\server\folder work without modification pointing to an Azure file share.
Shared storage for VMs: Multiple VMs mount the same share to share configurations, logs, or application data.
Replacement of on-premises file servers: Elimination of physical fileservers.
Azure File Sync: Bidirectional synchronization between local servers and Azure, with local cache.
Containers and AKS: Persistent volumes shared between pods.

3. Building the Concepts

3.1 Supported protocols

Azure Files supports two file sharing protocols, and the protocol choice is made per file share, not per Storage Account:

SMB (Server Message Block):

Native Windows protocol for file sharing
Supported versions: SMB 2.1 (no encryption) and SMB 3.x (with encryption in transit)
Compatible with: Windows, Linux (via cifs-utils client), macOS
Port: TCP 445

NFS (Network File System):

Native Linux/Unix protocol for file sharing
Supported version: NFS 4.1
Compatible with: Linux only
Requires Premium FileStorage account type
Requires Private Endpoint or Service Endpoint (no public internet access)

Criteria	SMB	NFS
Operating system	Windows, Linux, macOS	Linux only
Required account type	Standard or Premium	Premium FileStorage only
Public internet access	Yes (port 445)	No (requires VNet)
Identity-based authentication	Yes (Azure AD, AD DS)	No (UID/GID based)
Encryption in transit	SMB 3.x	IPSec (configured on client)

3.2 Storage account types for Azure Files

Not every Storage Account supports all file share types. The account choice determines available capabilities:

Account type	Tier	Protocol	Max IOPS	Latency
Standard GPv2	Hot/Cool	SMB	Up to 10,000	Double-digit milliseconds
Premium FileStorage	Premium SSD	SMB and NFS	Up to 100,000+	Sub-millisecond

Important point: Premium FileStorage is an account type exclusive to Azure Files. It's not the same as Premium GPv2. You cannot create blob containers or queues in a FileStorage account.

3.3 Capacity and quotas

Standard (GPv2):

Maximum capacity per file share: 100 TiB (with Large File Shares enabled)
Default capacity without Large File Shares: 5 TiB
Billing: per GB stored and per transactions

Premium (FileStorage):

Capacity defined at creation (provisioned)
Minimum provisioned: 100 GiB
Maximum: 100 TiB
Billing: for provisioned capacity (not actual usage)
IOPS and throughput are proportional to provisioned capacity

Critical billing difference: Standard charges for what you use. Premium charges for what you provision, even if you don't use it. This means you should size Premium carefully.

3.4 Access tiers in Standard file shares

Just like Blob Storage has Hot/Cool/Archive tiers, Azure Files Standard has tiers:

Tier	Optimized for	Storage cost	Transaction cost
Transaction Optimized	Workloads with many transactions	High	Low
Hot	Frequent and balanced usage	Medium	Medium
Cool	Rarely accessed data	Low	High

The default tier when creating via portal is Transaction Optimized. For infrequently accessed shares, Cool significantly reduces storage cost at the price of more expensive transactions.

A snapshot is a read-only and incremental copy of the file share state at a specific moment. Snapshots capture only the differences from the previous state, saving space.

Characteristics:

Up to 200 snapshots per file share
Unlimited retention (you choose when to delete)
Can be used to restore individual files or the entire share
Can be accessed directly via Windows "Previous Versions" or via special path on Linux

3.6 Azure File Sync

Azure File Sync is a separate service that extends Azure Files by creating a local cache on Windows servers on-premises or on VMs:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

File Sync enables cloud tiering: rarely accessed files stay only in the cloud, freeing local space. When accessed, they are downloaded automatically and transparently.

4. Structural View

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Practical Operation

When creating a file share, you define:

Name: 3 to 63 characters, lowercase, numbers and hyphens. Must start and end with letter or number.
Protocol: SMB or NFS (NFS only on Premium FileStorage accounts).
Quota: Maximum size the share can reach. In Standard, it's the growth limit. In Premium, it's the provisioned capacity that determines IOPS.
Access tier: Transaction Optimized, Hot or Cool (Standard only).
Backup: Enabled via Azure Backup directly at creation.

Azure Files provides a ready PowerShell script in the portal (Connect > select authentication method > copy script). The equivalent manual script is:

# Mount with access key (simple authentication)
$connectTestResult = Test-NetConnection -ComputerName myaccount.file.core.windows.net -Port 445
if ($connectTestResult.TcpTestSucceeded) {
    # Store credential in Windows credential manager
    cmd /c "cmdkey /add:`"myaccount.file.core.windows.net`" /user:`"localhost\myaccount`" /pass:`"<access key>`""
    
    # Mount the drive
    New-PSDrive -Name Z -PSProvider FileSystem -Root "\\myaccount.file.core.windows.net\myshare" -Persist
} else {
    Write-Error "Port 445 blocked. Check firewall."
}

To persist the mount after reboot on Windows, use the -Persist parameter or configure via Disk Management. Credentials stored in Windows Credential Manager are remembered between reboots.

5.3 Mounting on Linux

# Install SMB client
sudo apt-get update && sudo apt-get install cifs-utils

# Create mount directory
sudo mkdir -p /mnt/myshare

# Mount the share
sudo mount -t cifs \
  //myaccount.file.core.windows.net/myshare \
  /mnt/myshare \
  -o vers=3.0,username=myaccount,password=<access-key>,dir_mode=0777,file_mode=0777,serverino

# For persistence, add to /etc/fstab:
# //myaccount.file.core.windows.net/myshare /mnt/myshare cifs vers=3.0,username=myaccount,password=<key>,dir_mode=0777,file_mode=0777,serverino 0 0

Non-obvious behavior on Linux: The default SMB version on Linux can be 1.0, which is insecure and may be blocked by the Storage Account if "Secure transfer required" is active. Always specify vers=3.0 or vers=3.1.1.

5.4 Port 445: the main obstacle

TCP port 445 is used by the SMB protocol. Many ISPs and corporate networks block this port for security reasons (it was exploited by ransomware like WannaCry). This is the most common problem when mounting file shares via SMB outside the Azure network.

Solutions when port 445 is blocked:

Solution	How it works
Point-to-Site VPN	SMB traffic travels through VPN (encrypted tunnel)
ExpressRoute	Private connection, bypasses ISP
Azure File Sync	Local cache via HTTPS (port 443), no port 445
Private Endpoint	Access via private IP within VNet
SMB over QUIC	SMB encapsulated in QUIC (UDP 443), available in Premium

5.5 SMB over QUIC

SMB over QUIC is a functionality that encapsulates the SMB protocol inside the QUIC protocol (which uses UDP 443 instead of TCP 445). This solves the blocked port 445 problem without needing VPN.

Requirements:

Premium FileStorage Storage Account
Windows 11 or Windows Server 2022 (or later) clients
Explicitly enabled on Premium account

6. Implementation Methods

6.1 Azure Portal

When to use: Initial creation, configuration exploration, mounting script generation.

In the portal, navigate to Storage Account > Data storage > File shares > + File share. The portal presents protocol, quota and tier options on a single screen.

A valuable portal feature is the "Connect" button on each file share, which automatically generates the correct mounting script for Windows, Linux and macOS, considering the selected authentication method.

Limitation: Not scalable for multiple file shares or accounts.

6.2 Azure CLI

Creating the file share:

# Standard SMB with 100 GiB quota
az storage share-rm create \
  --resource-group myRG \
  --storage-account myaccount \
  --name myfileshare \
  --quota 100 \
  --access-tier Hot

# Premium SMB with 500 GiB provisioned
az storage share-rm create \
  --resource-group myRG \
  --storage-account mypremiumaccount \
  --name premiumshare \
  --quota 500

# NFS 4.1 (requires Premium FileStorage account)
az storage share-rm create \
  --resource-group myRG \
  --storage-account mypremiumaccount \
  --name nfsshare \
  --quota 500 \
  --enabled-protocols NFS \
  --root-squash RootSquash

Listing file shares:

az storage share-rm list \
  --resource-group myRG \
  --storage-account myaccount \
  --output table

Adjusting quota (resizing):

az storage share-rm update \
  --resource-group myRG \
  --storage-account myaccount \
  --name myfileshare \
  --quota 200

6.3 Azure PowerShell

# Create storage context
$ctx = New-AzStorageContext `
  -StorageAccountName "myaccount" `
  -StorageAccountKey "<key>"

# Create Standard file share
New-AzStorageShare `
  -Name "myfileshare" `
  -Context $ctx `
  -QuotaGiB 100

# Create directory within share
New-AzStorageDirectory `
  -ShareName "myfileshare" `
  -Path "department/finance" `
  -Context $ctx

# Upload file to share
Set-AzStorageFileContent `
  -ShareName "myfileshare" `
  -Source "/local/path/report.xlsx" `
  -Path "department/finance/report.xlsx" `
  -Context $ctx

6.4 Bicep

// Standard Storage Account for Azure Files
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'myfilestorageacct'
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
  properties: {
    largeFileSharesState: 'Enabled'
    supportsHttpsTrafficOnly: true
    minimumTlsVersion: 'TLS1_2'
  }
}

// Standard Hot File Share 100 GiB
resource fileShare 'Microsoft.Storage/storageAccounts/fileServices/shares@2023-01-01' = {
  name: '${storageAccount.name}/default/myfileshare'
  properties: {
    shareQuota: 100
    accessTier: 'Hot'
    enabledProtocols: 'SMB'
  }
}

6.5 Creating snapshots

# Create snapshot via CLI
az storage share snapshot \
  --account-name myaccount \
  --name myfileshare \
  --account-key <key>

# List snapshots
az storage share list \
  --account-name myaccount \
  --include-snapshot \
  --output table

# Restore file from snapshot to active share
az storage file copy start \
  --account-name myaccount \
  --source-share myfileshare \
  --source-path "docs/report.docx" \
  --source-snapshot <snapshot-datetime> \
  --destination-share myfileshare \
  --destination-path "docs/report-restored.docx"

7. Control and Security

7.1 Authentication methods for SMB

Azure Files supports four authentication methods for SMB access:

1. Storage Account Key

Equivalent to "root administrator" access
Not integrated with Active Directory
Useful for mounting scripts and troubleshooting
Not recommended for end users

2. Azure Active Directory Domain Services (Azure AD DS)

Integration with Azure AD via managed service
Doesn't require on-premises domain controller
Users authenticate with Azure AD credentials
Permissions via RBAC at share level and ACLs at file/directory level

3. On-premises Active Directory Domain Services (AD DS)

Integration with traditional Active Directory (Windows Server)
Ideal for hybrid environments with existing domain controllers
Users use existing corporate credentials
Requires Storage Account domain join

4. Azure AD Kerberos (for hybrid identities)

Kerberos authentication using Azure AD as KDC
Ideal for hybrid joined and Azure AD joined devices
Doesn't require on-premises AD DS

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

7.2 Permissions: two levels

Azure Files with identity-based authentication uses two permission levels that work together:

Level 1: RBAC at share level

Defines what the user can do on the entire share:

Role	Permission
Storage File Data SMB Share Reader	Read files and list directories
Storage File Data SMB Share Contributor	Read, write and delete
Storage File Data SMB Share Elevated Contributor	Read, write, delete and modify ACLs (NTFS permissions)

Level 2: Windows ACLs (NTFS) at file and directory level After mounting the share, you apply normal NTFS permissions via Windows Explorer or icacls. These ACLs are stored in the file metadata in Azure.

The evaluation logic: The effective permission is the most restrictive between RBAC and NTFS ACL. A user with RBAC Contributor but NTFS ACL "Read Only" on the folder will only be able to read.

7.3 Encryption

At rest: AES-256 automatic, always active.
In transit SMB: Requires SMB 3.x for encryption. If the Storage Account has "Secure transfer required" active, SMB 2.x connections (without encryption) are rejected.
In transit NFS: No native encryption in NFS 4.1 protocol. Security is ensured by private network (VNet, Private Endpoint, IPSec).

7.4 Advanced SMB security settings

For Premium FileStorage accounts, you can configure:

Allowed SMB versions: Restrict to SMB 3.1.1 only, rejecting older versions.
Kerberos authentication types: Limit to AES-256 only (reject RC4-HMAC).
Channel encryption: Require AES-256-GCM or AES-128-GCM.

az storage account update \
  --name mypremiumaccount \
  --resource-group myRG \
  --file-auth-method Kerberos \
  --smb-versions 3.1.1 \
  --smb-channel-encryption AES-256-GCM

8. Decision Making

8.1 Standard vs Premium

Situation	Best choice	Reason
General corporate file sharing	Standard Hot	Controlled cost, adequate performance
Database, ERP, high I/O applications	Premium SMB	Sub-millisecond, guaranteed IOPS
Linux workloads with native NFS	Premium NFS	Only NFS 4.1 support
Backup and archiving	Standard Cool	Lower storage cost
Development and testing	Standard Transaction Optimized	Many small operations
High-performance persistent volume for AKS	Premium NFS	Performance and Linux compatibility

8.2 SMB vs NFS

Situation	Best choice	Reason
Predominantly Windows environment	SMB	Native, no additional installation
Linux servers with POSIX workloads	NFS	Unix file semantics, UID/GID permissions
Mixed Windows and Linux environment	SMB	Greater cross-platform compatibility
Active Directory integration requirement	SMB	NFS doesn't support AD authentication
High performance on Linux without AD	NFS	Lower protocol overhead

8.3 Azure File Sync vs direct access

Situation	Best choice	Reason
Remote users with occasional access	Azure File Sync	Local cache, no constant latency dependency
Azure VMs accessing the share	Direct access (mounting)	Low latency within Azure region
On-premises server replacing fileserver	Azure File Sync	Local cache + cloud backup
Port 445 blocked by ISP	Azure File Sync	Syncs via HTTPS (443)

9. Best Practices

Enable Large File Shares before needing it: in Standard GPv2 accounts, enable largeFileSharesState: Enabled to allow up to 100 TiB per share (default is 5 TiB and cannot be expanded later without enabling this feature).
Use identity-based authentication (Azure AD DS, AD DS, or Azure AD Kerberos) instead of access keys for end users.
Never expose access keys in scripts stored in repositories. Use Azure Key Vault or secure environment variables.
Configure "Secure transfer required" to reject SMB 2.x connections without encryption.
Implement regular snapshots via Azure Backup or via scheduled scripts for protection against accidental deletion.
Separate file shares by function or department within the same Storage Account to apply individual quotas and controls.
For Premium, size with margin: IOPS = 400 + (1 IOPS per provisioned GiB). A 1 TiB share has 1,424 IOPS. Size for peak load.
Use Private Endpoints for file shares in production environments, eliminating public endpoint exposure.
Monitor quota usage to prevent Standard shares from reaching the limit and starting to fail on writes.

10. Common Errors

Error	Why it happens	How to avoid
Mount error "Port 445 blocked"	ISP or corporate firewall blocks TCP 445	Use VPN, File Sync, or SMB over QUIC
"Access denied" when mounting with access key	"Secure transfer required" active and client uses SMB 2.x	Check SMB version on client (use `vers=3.0` on Linux)
Premium share doesn't accept quota reduction	Premium doesn't allow reduction below current usage	Plan initial capacity appropriately
NTFS permissions not applied after mounting	Mounted with access key, not with AD identity	Use identity-based authentication for NTFS ACLs
NFS configured on Standard account	NFS 4.1 only available on Premium FileStorage	Create Premium FileStorage account specifically
Snapshot fails with "MaxSnapshotCount"	200 snapshots limit reached	Implement retention policy and deletion of old snapshots
File share inaccessible after "Secure transfer" enabled	SMB 2.1 clients without encryption are rejected	Update clients or confirm SMB 3.x support
Large file share not activatable after creation	Accounts created without `largeFileSharesState` have 5 TiB limit	Enable at account creation or via account update (possible on GPv2)

11. Operation and Maintenance

11.1 Metrics monitoring

In Azure Monitor, the most relevant metrics for Azure Files:

Metric	What it indicates
FileShareCapacityQuotaUsedPercentage	% of quota used per share
Transactions	Volume of operations (useful for detecting anomalies)
SuccessE2ELatency	End-to-end latency of operations
Availability	File service availability

Configure alerts for FileShareCapacityQuotaUsedPercentage > 80 to be notified before reaching the limit.

11.2 Managing snapshots in Windows

When the share is mounted on Windows with AD authentication, snapshots become accessible via "Previous Versions": right-click on any file or folder > "Properties" > "Previous Versions" tab. Users can restore files without administrator intervention.

11.3 Important limits

Resource	Limit
File shares per Storage Account	250 (Standard), no documented limit (Premium)
Maximum size per Standard share (with Large File Shares)	100 TiB
Maximum size per Premium share	100 TiB
Snapshots per share	200
Maximum individual file size	4 TiB
Maximum directory depth	2,000
Simultaneous SMB connections per share	2,000

12. Integration and Automation

12.1 Azure Backup for file shares

Azure Backup supports native backup of Standard SMB file shares:

az backup protection enable-for-azurefileshare \
  --vault-name myRecoveryVault \
  --resource-group myRG \
  --storage-account myaccount \
  --azure-file-share myfileshare \
  --policy-name DailyBackupPolicy

Backup uses snapshots internally and allows restoration of individual files or the complete share to a point in time.

12.2 Kubernetes (AKS) with Azure Files

For persistent volumes shared between pods:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azurefile-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: azurefile-csi
  resources:
    requests:
      storage: 100Gi

The ReadWriteMany is the differentiator of Azure Files compared to Azure Disk (which is ReadWriteOnce). Multiple pods on different nodes can mount the same file share simultaneously.

12.3 Azure File Sync: basic configuration

# 1. Create Storage Sync Service
az storagesync create \
  --resource-group myRG \
  --name myStorageSyncService \
  --location eastus

# 2. Create Sync Group
az storagesync sync-group create \
  --resource-group myRG \
  --storage-sync-service myStorageSyncService \
  --name mySyncGroup

# 3. Register file share as cloud endpoint
az storagesync sync-group cloud-endpoint create \
  --resource-group myRG \
  --storage-sync-service myStorageSyncService \
  --sync-group-name mySyncGroup \
  --name myCloudEndpoint \
  --storage-account-resource-id <storage-account-id> \
  --azure-file-share-name myfileshare

# 4. The File Sync agent is manually installed on the Windows server
# and the server endpoint is created via portal or PowerShell after agent registration

13. Final Summary

Essential concepts:

Azure Files is a managed file sharing service that exposes shares via SMB and NFS, replacing traditional fileservers.
A file share lives within a Storage Account and is the mounting unit that clients connect as a network drive.
SMB protocol supports Windows, Linux, and macOS. NFS protocol supports only Linux and requires Premium FileStorage account.

Critical differences:

Standard vs Premium: Standard charges per usage with elastic capacity; Premium charges per provisioned capacity with guaranteed performance (IOPS proportional to provisioning).
Access key vs identity authentication: Access key gives full access without AD integration. Identity authentication allows granular NTFS ACLs per user.
SMB vs NFS: SMB has multi-OS support and AD integration. NFS has better POSIX semantics for Linux but no AD authentication and requires private network.
Azure File Sync vs direct access: File Sync creates local cache and syncs via HTTPS (solves port 445 blocking). Direct access is simpler but depends on SMB connectivity.

What needs to be remembered:

TCP port 445 is the main obstacle for SMB mounting outside Azure network. Always check before planning architecture.
Large File Shares (Standard) must be enabled before needing more than 5 TiB per share.
NFS 4.1 requires Premium FileStorage account and doesn't support access via public internet.
Snapshots in Azure Files don't replace complete backup. Use Azure Backup for protection with long retention.
In Kubernetes, Azure Files is the only native Azure storage option with ReadWriteMany (multiple simultaneous pods).
Permissions in Azure Files with AD identity operate at two levels: RBAC (on the share) and NTFS ACLs (on files and directories), and the most restrictive prevails.

1. Initial Intuition​

2. Context​

2.1 Why Azure Files exists​

2.2 Position in the Azure ecosystem​

2.3 Main use cases​

3. Building the Concepts​

3.1 Supported protocols​

3.2 Storage account types for Azure Files​

3.3 Capacity and quotas​

3.4 Access tiers in Standard file shares​

3.5 File share snapshots​

3.6 Azure File Sync​

4. Structural View​

5. Practical Operation​

5.1 Creating a file share: what you define​

5.2 Mounting the file share on Windows​

5.3 Mounting on Linux​

5.4 Port 445: the main obstacle​

5.5 SMB over QUIC​

6. Implementation Methods​

6.1 Azure Portal​

6.2 Azure CLI​

6.3 Azure PowerShell​

6.4 Bicep​

6.5 Creating snapshots​

7. Control and Security​

7.1 Authentication methods for SMB​

7.2 Permissions: two levels​

7.3 Encryption​

7.4 Advanced SMB security settings​

8. Decision Making​

8.1 Standard vs Premium​

8.2 SMB vs NFS​

8.3 Azure File Sync vs direct access​

9. Best Practices​

10. Common Errors​

11. Operation and Maintenance​

11.1 Metrics monitoring​

11.2 Managing snapshots in Windows​

11.3 Important limits​

12. Integration and Automation​

12.1 Azure Backup for file shares​

12.2 Kubernetes (AKS) with Azure Files​

12.3 Azure File Sync: basic configuration​

13. Final Summary​

1. Initial Intuition

2. Context

2.1 Why Azure Files exists

2.2 Position in the Azure ecosystem

2.3 Main use cases

3. Building the Concepts

3.1 Supported protocols

3.2 Storage account types for Azure Files

3.3 Capacity and quotas

3.4 Access tiers in Standard file shares

3.5 File share snapshots

3.6 Azure File Sync

4. Structural View

5. Practical Operation

5.1 Creating a file share: what you define

5.2 Mounting the file share on Windows

5.3 Mounting on Linux

5.4 Port 445: the main obstacle

5.5 SMB over QUIC

6. Implementation Methods

6.1 Azure Portal

6.2 Azure CLI

6.3 Azure PowerShell

6.4 Bicep

6.5 Creating snapshots

7. Control and Security

7.1 Authentication methods for SMB

7.2 Permissions: two levels

7.3 Encryption

7.4 Advanced SMB security settings

8. Decision Making

8.1 Standard vs Premium

8.2 SMB vs NFS

8.3 Azure File Sync vs direct access

9. Best Practices

10. Common Errors

11. Operation and Maintenance

11.1 Metrics monitoring

11.2 Managing snapshots in Windows

11.3 Important limits

12. Integration and Automation

12.1 Azure Backup for file shares

12.2 Kubernetes (AKS) with Azure Files

12.3 Azure File Sync: basic configuration

13. Final Summary