Configure Directory and File Level Permissions for Azure Files

Here’s a concise summary of the article “Configure directory and file-level permissions for Azure file shares.”

Purpose

• After assigning share-level permissions (Azure RBAC) you can configure Windows ACLs (NTFS permissions) at the root, directory, or file level for SMB Azure file shares.

Prerequisites / Important

• Assign share-level permissions first (see the linked “assign share-level permissions to an identity”).

• For hybrid identities, the client machine that configures ACLs must have unimpeded network connectivity to the domain controllers for the AD source (on-prem AD/Entra Kerberos or Microsoft Entra Domain Services).

• If using Microsoft Entra Kerberos, hybrid identities must be synced to Microsoft Entra ID for ACL enforcement.

How Azure RBAC and Windows ACLs work together

• RBAC (share-level) acts as a coarse gatekeeper; Windows ACLs are granular for files/directories.

• Both RBAC and ACLs are enforced; the most restrictive permission applies if they differ.

• The article provides a matrix showing effective access for combinations of RBAC roles (None, SMB Share Reader, SMB Share Contributor, SMB Share Elevated Contributor) and NTFS permission levels.

• Taking ownership requires extra RBAC permission — assign the Storage File Data SMB Admin role to allow takeOwnership.

Supported Windows ACLs

• Azure Files supports the full set of basic and advanced Windows ACLs and common built-in principals (e.g., BUILTIN\Administrators, BUILTIN\Users, NT AUTHORITY\SYSTEM, NT AUTHORITY\Authenticated Users, CREATOR OWNER).

• The article lists the default ACLs present on the root directory and links to icacls documentation for details.

Mount the file share (admin-level access)

• Two recommended approaches to mount with admin-level access:

1

Mount using the Windows permission model for SMB admin (recommended)

• Assign the built-in RBAC role Storage File Data SMB Admin to users who configure ACLs.

• Users mount the share using identity-based authentication (domain identity). This avoids using the storage account key and is more secure.

• Use net use (not PowerShell) to mount, e.g.: net use Z: \.file.core.chinacloudapi.cn<FileShareName>

2

Mount using the storage account key (not recommended)

• Use only if identity-based auth is unavailable. This uses a sensitive storage account key.

• Use net use (not PowerShell), e.g.: net use Z: \.file.core.chinacloudapi.cn<FileShareName> /user:localhost<YourStorageAccountName>

Note: If a user has Full Control ACL plus the Storage File Data SMB Share Elevated Contributor role (or an equivalent custom role), they can configure ACLs without SMB Admin or the storage account key.

Configure Windows ACLs

• Methods:

  • Azure portal: If Microsoft Entra Kerberos is configured, you can set ACLs per Entra user/group via Browse → Manage access, edit permissions, Save.

  • icacls: From a domain-connected machine with connectivity to the AD domain controller, you can run commands such as: icacls : /grant :(f) (Links to icacls documentation included.)

  • Windows File Explorer: On a domain-joined client, use Properties → Security → Edit/Add to set permissions. Do not use Explorer if the client is not domain-joined or if you have multiple AD forests—use icacls instead.

• You can preserve ACLs when copying from on-premises file servers using Robocopy or AzCopy, and Azure File Sync preserves ACLs.

Important enforcement note

• ACLs set for identities not synced to Microsoft Entra ID won’t be enforced when using Microsoft Entra Kerberos because the Kerberos ticket won’t include those identities. With on-prem AD DS as the source, non-synced SIDs can be enforced because AD DS places them in the Kerberos ticket.

Next steps

• After configuring ACLs, you can mount the SMB file share on Windows or Linux (links provided).

References & extras

• Links in the article cover role assignment, RBAC roles, icacls reference, mounting and authentication overviews, and related how-to guides.

Last updated: 12/23/2025

If you want, I can:

• Produce a one-paragraph TL;DR,

• Extract just the mounting commands and RBAC roles into a quick checklist,

• Or convert the Azure portal or icacls instructions into a step-by-step checklist for copy/paste. Which would you prefer?