Azure Files access — SMB identity sources, share-level roles, managed identities over SMB, NFS, and mount errors
How clients authenticate to Azure file shares and why mounts fail — the three SMB identity sources (AD DS, Entra Domain Services, Entra Kerberos), share-level RBAC roles and the default share-level permission, managed identities over SMB (SMBOAuth), NFS requirements (premium, network rules only, AZNFS for encryption in transit, the new Microsoft.FileShares provider), and the verbatim errors System error 5, 53, 67, 87, 1816, NFS access and encryption failures, with cause, check and fix.
markdownreferencev1K356-W7M0stage: operatetrust: officialservice: storageinterface: anyAzure Files SMB authenticationAD DS Azure FilesMicrosoft Entra Domain Services Azure FilesMicrosoft Entra Kerberos Azure FilesStorage File Data SMB Share ReaderStorage File Data SMB Share ContributorStorage File Data SMB Share Elevated ContributorStorage File Data SMB MI Admindefault share-level permission--default-share-permission--enable-files-aadkerb--enable-files-adds--enable-smb-oauthSMBOAuth managed identity file shareSystem error 5 has occurred. Access is denied.System error 53 has occurred. The network path was not found.System error 67 has occurred. The network name cannot be found.System error 87 has occurred. The parameter is incorrect.port 445 blockedNTLMv1 LmCompatibilityLevelError 1816 Not enough quotaopen handlesNFS Azure Files premium FileStorageNFS port 2049AZNFS mount helperRequire encryption in transit for NFSMicrosoft.FileSharesprovisioned v2Owner Contributor key access file share
Azure Files access and mount errors
Azure Files speaks SMB (identity-based or account key), NFS (network rules only, no user authentication) and REST over 443 (Entra ID with the File Data Privileged roles, or keys and SAS: reference/storage/access-models.md).
SMB identity sources (pick one per account)
| Source | Fits | Clients |
|---|---|---|
| On-premises AD DS | Domain-joined clients with line of sight to a domain controller; identities synced to Entra for RBAC | Windows (and Linux with extra setup) |
| Microsoft Entra Domain Services | A managed domain in Azure | Domain-joined to it; cloud-only or hybrid identities |
| Microsoft Entra Kerberos | Entra-joined or hybrid-joined clients, FSLogix, macOS, no domain controller connectivity; hybrid identities (needs AD DS synced through Entra Connect) or cloud-only | Windows, macOS |
Then two layers authorize: a share-level Azure role, and file/directory NTFS ACLs.
| Share-level role | Access |
|---|---|
| Storage File Data SMB Share Reader | Read |
| Storage File Data SMB Share Contributor | Read, write, delete |
| Storage File Data SMB Share Elevated Contributor | Also change NTFS permissions |
A default share-level permission (--default-share-permission StorageFileDataSmbShareReader and so on) applies to every authenticated identity that has no role: the way to give access to computer accounts, service accounts and identities not synced to Entra.
Managed identities over SMB (VMs and apps, no domain join): enable SMBOAuth on the account (--enable-smb-oauth true), keep Kerberos allowed in the account's SMB security settings, and grant Storage File Data SMB MI Admin. The client must not be domain-joined; it mounts with an OAuth token for the identity.
Owner and Contributor can list the account keys, and a key mounts any share as super-user. Removing someone's role doesn't revoke a key they already have: rotate the keys (and the account's Kerberos keys for AD DS).
SMB mount errors
| Message | Cause → fix | Check |
|---|---|---|
System error 5 has occurred. Access is denied. | (1) The client doesn't encrypt SMB (pre-SMB 3 client) while secure transfer or SMB encryption is required, and it isn't in the same datacenter; (2) the storage firewall doesn't allow the client; (3) share-level role missing for identity-based access | Client OS; az storage account show -n <acct> --query networkRuleSet.defaultAction; role assignments on the share |
System error 53 has occurred. The network path was not found. / System error 67 has occurred. The network name cannot be found. | Outbound TCP 445 blocked by the ISP or corporate firewall (common from on-premises); or NTLMv1 enabled on the client | Test-NetConnection -ComputerName <acct>.file.core.windows.net -Port 445; registry HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel must be ≥ 3 |
System error 87 has occurred. The parameter is incorrect. | NTLMv1 on the client: Azure Files accepts NTLMv2 only | Same registry value |
| Port 445 can't be opened | Use a VPN or ExpressRoute with a private endpoint for file, Azure File Sync, or REST tools (Storage Explorer, AzCopy) over 443 | — |
Error 1816 - Not enough quota is available to process this command / ERROR_UNEXP_NET_ERR (59) / Linux [permission denied] Disk quota exceeded | Too many open handles on a file or share: close them | az storage share list-handle / close-handle (with --auth-mode login where supported) |
| Can't modify, move or delete a file | An open handle or lease from another client | Same |
The user name or password is incorrect after a customer-initiated failover | Failover doesn't keep file handles or leases: unmount and remount the share | — |
Portal No access Error code: 403 on a share | The storage firewall doesn't allow the portal client's network | Network rules; test briefly with all networks allowed |
| Entra Kerberos mount fails | Entra Kerberos always encrypts service tickets with AES-256, so the client's supported encryption types must include it (Group Policy); the client also needs cloud Kerberos ticket retrieval enabled (CloudKerberosTicketRetrievalEnabled); hybrid identities must be synced | klist get cifs/<acct>.file.core.windows.net |
NFS
- Classic shares: premium (SSD)
FileStorageaccounts only, LRS or ZRS. Otherwise share creation fails. - Microsoft.FileShares (new, recommended for new NFS): file shares as top-level resources without a storage account, provisioned v2 billing only, NFS only; no AzCopy, Storage Explorer or Azure Backup.
- No user authentication: access is decided by network rules, so clients must come through a private endpoint or a service endpoint with VNet rules. A client from an untrusted network gets access denied at mount.
- Port 2049 must be open; install
nfs-utils/nfs-common. - Encryption in transit: with Secure transfer required or Require encryption in transit for NFS on, a plain NFS mount fails: mount with the AZNFS mount helper, or (for classic shares) turn both settings off. Microsoft.FileShares requires encryption in transit by default.
chgrp "filename" failed: Invalid argument (22): Azure Files rejects alphanumeric UIDs/GIDs, so idmapping must be disabled on the client, and stay disabled (a bad file name, such as one with a colon, can make the NFS 4.1 client re-enable it): unmount, disable idmapping, remount.- Each user is limited to 16 group IDs per connection (an NFS protocol constraint).