How to Mount Azure File Share on an Azure Linux VM (SMB/CIFS) — Step-by-Step

Azure Files provides fully managed cloud file shares that you can mount on Linux just like a normal network filesystem. This is super handy for shared application configs, logs, backups, and cross-VM shared storage without managing an NFS/SMB server yourself.

In this guide, we’ll mount an Azure File Share from the storage account mystorageacc01 to an Azure Linux VM using SMB 3.0 (CIFS), then make it persistent across reboots.

What you need before you start

✅ Prerequisites

An Azure Storage account: mystorageacc01
At least one Azure File Share created (example share name: docs)
A Linux VM with:
- Network access to the storage account’s file endpoint
- Outbound access to TCP 445 (SMB)

Important note on networking (Public vs Private)

Azure Storage can be configured in two ways:

Public network access enabled
Your VM can mount Azure Files over the internet (secure, but public exposure exists).
Public network access disabled (Private Endpoint required)
Your VM must resolve the storage endpoint to a private IP and route traffic via your VNet.

If your organization hardens storage accounts (recommended), you’ll likely be using Private Endpoints for the file sub-resource.

Step 1 — Confirm connectivity from the Linux VM

1A) Check DNS resolution

Run this from your VM:

nslookup mystorageacc01.file.core.windows.net

If you use a private endpoint, this should return a private IP (10.x / 172.16–31 / 192.168.x).
If it returns a public IP while public access is disabled, your VM likely isn’t using the private DNS zone.

1B) Check SMB port access (TCP 445)

nc -vz mystorageacc01.file.core.windows.net 445

If this fails, your mount will fail too — fix routing/NSG/firewall rules first.

Step 2 — Install CIFS utilities on Linux

Ubuntu / Debian

sudo apt update
sudo apt install -y cifs-utils

RHEL / CentOS / Rocky / Alma

sudo dnf install -y cifs-utils

Step 3 — Get your Azure Files credentials

Option A (most common): Storage Account Key

In Azure Portal:
Storage account → Access keys → Key1/Key2

You’ll use:

username = storage account name (mystorageacc01)
password = access key value

This is the quickest method, but not always preferred for strict security policies.

Step 4 — Create a secure credentials file on the VM

Create a credential directory and file:

sudo mkdir -p /etc/smbcredentials
sudo bash -c 'cat > /etc/smbcredentials/mystorageacc01.cred <<EOF
username=mystorageacc01
password=PASTE_YOUR_STORAGE_ACCOUNT_KEY_HERE
EOF'
sudo chmod 600 /etc/smbcredentials/mystorageacc01.cred

✅ This prevents exposing the key in command history.

Step 5 — Create the mount point directory

Example: we want to mount the share docs to /data/azurefiles/docs

sudo mkdir -p /data/azurefiles/docs

Step 6 — Mount the Azure File Share (SMB 3.0)

Use this mount command:

sudo mount -t cifs //mystorageacc01.file.core.windows.net/docs /data/azurefiles/docs \
  -o credentials=/etc/smbcredentials/mystorageacc01.cred,vers=3.0,sec=ntlmssp,serverino,dir_mode=0770,file_mode=0660,nosharesock,_netdev

Verify it mounted successfully

df -h | grep azurefiles
mount | grep mystorageacc01
ls -la /data/azurefiles/docs

Step 7 — Make it persistent after reboot (/etc/fstab)

Edit fstab:

sudo nano /etc/fstab

Add this line:

//mystorageacc01.file.core.windows.net/docs  /data/azurefiles/docs  cifs  credentials=/etc/smbcredentials/mystorageacc01.cred,vers=3.0,sec=ntlmssp,serverino,dir_mode=0770,file_mode=0660,nosharesock,_netdev  0  0

Test it safely:

sudo umount /data/azurefiles/docs
sudo mount -a
df -h | grep azurefiles

Step 8 — Mount multiple shares (optional)

If you have multiple shares like cdrs, logs, shared-apps etc.:

for s in cdrs docs logs shared-apps shared-utils; do
  sudo mkdir -p /data/azurefiles/$s
  sudo mount -t cifs //mystorageacc01.file.core.windows.net/$s /data/azurefiles/$s \
    -o credentials=/etc/smbcredentials/mystorageacc01.cred,vers=3.0,sec=ntlmssp,serverino,dir_mode=0770,file_mode=0660,nosharesock,_netdev
done

Then add each to /etc/fstab in the same format.

Troubleshooting common errors

❌ mount error(13): Permission denied

Usually means:

wrong key / wrong username format
storage account has “Allow storage account key access” disabled
share name is incorrect

Quick checks:

dmesg | tail -n 50

❌ Cannot connect / timeout

Usually:

port 445 blocked
private endpoint/DNS not configured properly

Check:

nc -vz mystorageacc01.file.core.windows.net 445
nslookup mystorageacc01.file.core.windows.net

❌ Share not found

Usually a typo:

share names are case-sensitive in the path

Security best practices (recommended for production)

If you’re mounting Azure Files for production workloads:

Prefer Private Endpoint for file sub-resource
Use Least privilege (avoid distributing account keys broadly)
Consider identity-based authentication for Azure Files (Entra ID / AD DS / Azure AD DS / Entra Kerberos) instead of access keys
Lock down your storage account with:
- Public access disabled (Private Endpoints)
- Secure transfer required
- Minimum TLS 1.2
- Defender for Storage (where applicable)

Mounting Azure File Shares on Linux is simple and powerful — especially for shared storage needs across VMs and services. Once mounted and added to /etc/fstab, the share behaves like a standard filesystem and survives reboots automatically.

How to Mount Azure File Share on an Azure Linux VM (SMB/CIFS) — Step-by-Step