Azure File Share ACL permission inheritance not working for new Entra ID users/groups

Question

Azure File Share ACL permission inheritance not working for new Entra ID users/groups

Leo Pearce 5

The Azure file share is accessed by AVD users on multi-user session hosts. This was setup and working fine when the environment was a hybrid on-prem AD to Entra sync setup, Azure files was configured using kerberos authentication and all was good.

However now we have transitioned to Entra ID only and the on prem AD servers are shutdown, any new users or groups created in Entra are experiencing permissions issues to the share. When setting the ACL in the "manage access" settings of the file share in Azure, if I give a new user or group full control permissions and set with the "Applies to this folder, subfolders and subfiles" setting, the user/group can access that particular folder in the share, but not given access to any subfolders or files in that folder.

This issue is not happening currently to any users or groups that existed before the migration to Entra ID only users and groups.

Not having much luck with AI, any ideas?

Ravi Varma Mudduluru 12,370 Reputation points Microsoft External Staff Moderator

2026-06-18T03:15:24.6933333+00:00

Hello @Leo Pearce

Thank you for contacting us about the File share issue. We have begun looking into it and will share our suggestions with you as soon as possible
Ravi Varma Mudduluru 12,370 Reputation points Microsoft External Staff Moderator

2026-06-18T03:31:14.9633333+00:00
Hello @Leo Pearce

Thanks for reaching out and providing such a clear description of the issue this is a common situation after moving from a hybrid AD setup to a full Microsoft Entra ID-only environment with Azure Files.

Recommended:

Double-check Share-Level Permissions (RBAC) first:

Go to your File Share → Access control (IAM).

Assign the Storage File Data SMB Share Contributor role (or Elevated Contributor) to the new Entra users or, preferably, a security group containing them.

Fix the NTFS Permissions:

In the File Share, browse to the root folder → Manage access.

Ensure NT AUTHORITY\Authenticated Users has at least Read & Execute (This folder only) for basic traversal.

Add your Entra user/group with Modify or Full Control, set to This folder, subfolders and files.

For existing subfolders that are causing trouble: Select the subfolder → Manage access → Disable inheritance if needed → Re-apply the desired permissions explicitly → Save.

Give it 30–60 minutes (sometimes longer) for changes to fully propagate, then test from an AVD session.

For bulk or more precise control (especially with many folders), you can use the RestSetAcls PowerShell module, which works well with cloud-only identities.

Reference Documents:

Configure directory and file-level permissions for Azure file shares

Enable Microsoft Entra Kerberos authentication for hybrid and cloud-only identities

Assign share-level permissions

If the answer is helpful, please click "upvote" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Leo Pearce 5 Reputation points

2026-06-18T04:58:01.3266667+00:00

Hi Ravi, thanks for your help. I have tried the suggestions and still no luck. I've created a new test group and test user within that group which am using to troubleshoot. I've already added that test group to the Storage File Data SMB Share Contributor role previously at the storage account and share level, I also have now performed all the actions in the Fix the NTFS permissions bit, but no change, same result.

One thing I forgot to mention is that this file share was synced over from a shared directory originally hosted on the AD server ("on prem") VM, when it was synced it brought over all file and folder permissions with it, which were then visible within the share's ACLs, and were working after the sync. Also Microsoft Entra Domain Services had been previosuly configured in this environment and left on, but not really used. Wondering if this has any relevance to Azure file shares / NTFS permissions and has potentially thrown a spanner in the works?
Ravi Varma Mudduluru 12,370 Reputation points Microsoft External Staff Moderator

2026-06-18T07:21:06.76+00:00

Hello @Leo Pearce

Thank you for the confirmation

I will check and share our suggestions with you as soon as possible
Sridevi Machavarapu 33,305 Reputation points Microsoft External Staff Moderator

2026-06-19T09:31:11.51+00:00

Hello Leo Pearce,

Thanks for the additional context.

The fact that the file share was migrated from an on-premises file server and retained its existing NTFS ACLs could be relevant. Since the issue appears to affect only newly created Entra users and groups, while users and groups that existed before the migration continue to work, it would be helpful to determine whether the behavior is related to the migrated permissions or the current identity configuration.

Could you confirm whether the issue is reproducible on a completely new folder structure created directly in the Azure file share after the migration? If newly created Entra users and groups can access newly created folders and files as expected, that would help narrow the scope to the migrated content and its existing ACLs.

Also, was Microsoft Entra Domain Services ever used as the identity source for Azure Files, or has the storage account always been configured for Microsoft Entra Kerberos authentication? Knowing whether the authentication configuration changed during the migration may help identify any additional factors that could be contributing to the behavior.

1 answer

Your answer

Ravi Varma Mudduluru 12,370 Reputation points Microsoft External Staff Moderator

2026-06-18T03:15:24.6933333+00:00

Hello @Leo Pearce

Thank you for contacting us about the File share issue. We have begun looking into it and will share our suggestions with you as soon as possible
Ravi Varma Mudduluru 12,370 Reputation points Microsoft External Staff Moderator

2026-06-18T03:31:14.9633333+00:00

Hello @Leo Pearce

Thanks for reaching out and providing such a clear description of the issue this is a common situation after moving from a hybrid AD setup to a full Microsoft Entra ID-only environment with Azure Files.

Recommended:

Double-check Share-Level Permissions (RBAC) first:

Go to your File Share → Access control (IAM).

Assign the Storage File Data SMB Share Contributor role (or Elevated Contributor) to the new Entra users or, preferably, a security group containing them.

Fix the NTFS Permissions:

In the File Share, browse to the root folder → Manage access.

Ensure NT AUTHORITY\Authenticated Users has at least Read & Execute (This folder only) for basic traversal.

Add your Entra user/group with Modify or Full Control, set to This folder, subfolders and files.

For existing subfolders that are causing trouble: Select the subfolder → Manage access → Disable inheritance if needed → Re-apply the desired permissions explicitly → Save.

Give it 30–60 minutes (sometimes longer) for changes to fully propagate, then test from an AVD session.

For bulk or more precise control (especially with many folders), you can use the RestSetAcls PowerShell module, which works well with cloud-only identities.

Reference Documents:

Configure directory and file-level permissions for Azure file shares

Enable Microsoft Entra Kerberos authentication for hybrid and cloud-only identities

Assign share-level permissions

If the answer is helpful, please click "upvote" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Leo Pearce 5 Reputation points

2026-06-18T04:58:01.3266667+00:00

Hi Ravi, thanks for your help. I have tried the suggestions and still no luck. I've created a new test group and test user within that group which am using to troubleshoot. I've already added that test group to the Storage File Data SMB Share Contributor role previously at the storage account and share level, I also have now performed all the actions in the Fix the NTFS permissions bit, but no change, same result.

One thing I forgot to mention is that this file share was synced over from a shared directory originally hosted on the AD server ("on prem") VM, when it was synced it brought over all file and folder permissions with it, which were then visible within the share's ACLs, and were working after the sync. Also Microsoft Entra Domain Services had been previosuly configured in this environment and left on, but not really used. Wondering if this has any relevance to Azure file shares / NTFS permissions and has potentially thrown a spanner in the works?
Ravi Varma Mudduluru 12,370 Reputation points Microsoft External Staff Moderator

2026-06-18T07:21:06.76+00:00

Hello @Leo Pearce

Thank you for the confirmation

I will check and share our suggestions with you as soon as possible
Sridevi Machavarapu 33,305 Reputation points Microsoft External Staff Moderator

2026-06-19T09:31:11.51+00:00

Hello Leo Pearce,

Thanks for the additional context.

The fact that the file share was migrated from an on-premises file server and retained its existing NTFS ACLs could be relevant. Since the issue appears to affect only newly created Entra users and groups, while users and groups that existed before the migration continue to work, it would be helpful to determine whether the behavior is related to the migrated permissions or the current identity configuration.

Could you confirm whether the issue is reproducible on a completely new folder structure created directly in the Azure file share after the migration? If newly created Entra users and groups can access newly created folders and files as expected, that would help narrow the scope to the migrated content and its existing ACLs.

Also, was Microsoft Entra Domain Services ever used as the identity source for Azure Files, or has the storage account always been configured for Microsoft Entra Kerberos authentication? Knowing whether the authentication configuration changed during the migration may help identify any additional factors that could be contributing to the behavior.

Answer 1

New Entra-only users and groups accessing Azure Files over SMB with Microsoft Entra Kerberos must have both:

Correct share-level permissions (Azure RBAC on the file share), and
Correct Windows ACLs (NTFS-style permissions) on folders and files.

In an Entra-only setup with Microsoft Entra Kerberos as the identity source, ACL behavior and tools differ from the previous hybrid AD DS setup:

Verify the identity source and supported ACL tools
When the storage account uses Microsoft Entra Kerberos as the identity source:
- For cloud-only identities, Windows ACLs must be configured via Azure portal or PowerShell (RestSetAcls). Windows File Explorer and icacls are not supported for cloud-only identities.
- For hybrid identities, File Explorer or icacls can be used only if there is unimpeded connectivity to AD DS. In an Entra-only environment without AD DS, use the Azure portal or RestSetAcls instead.
“For cloud-only identities, you must use the Azure portal or PowerShell. Windows File Explorer and icacls aren't currently supported for cloud-only identities.”
“If you configure Microsoft Entra Kerberos as the identity source for your storage account, you can configure Windows ACLs for each Entra user or group by using the Azure portal. This method works for both hybrid and cloud-only identities only when Microsoft Entra Kerberos is the identity source.”
Confirm share-level permissions for new Entra users/groups
Even if ACLs are set in Manage access on folders, access will fail or appear inconsistent if the user/group does not have share-level permissions:
- Assign the appropriate Azure Files data role (for SMB access) at the file share or storage account scope to the new Entra users/groups.
- The documentation notes that when identity-based access is enabled, share-level permissions must be assigned per share before NTFS ACLs apply:
“When you enable identity-based access, for each share you must assign which users and groups have access to that particular share. Once a user or group is allowed access to a share, Windows ACLs (also called NTFS permissions) on individual files and directories take over.”
Set ACLs from the correct place and verify inheritance
In the Azure portal for the file share:
- Use Browse → select the folder → Manage access.
- Add the new Entra user/group, then edit permissions.
- Ensure the Applies to setting is correctly set (for example, This folder, subfolders and files).
- Save the ACL.
The portal-based ACL editor supports both hybrid and cloud-only identities when Microsoft Entra Kerberos is the identity source:

“To set an ACL for a file or directory, right-click the file or directory, and then select Manage access… Edit the permissions… Deny always takes precedence over Allow when both are set. When neither is set, default permissions are inherited.”

If inheritance is not taking effect for new identities but works for older ones, check for:
- Any explicit Deny entries on subfolders/files for those new users/groups (or for groups they belong to). Deny overrides Allow and will block access even when inheritance is configured.
- Existing ACLs on subfolders that were set before migration and may not include the new identities. Inheritance might have been broken on those subfolders, so new ACEs at the parent are not flowing down.
Use RestSetAcls for bulk or corrective ACL application
If many folders/files are affected or inheritance is inconsistent, use the RestSetAcls PowerShell module to:
- Apply a consistent root ACL that includes the new Entra groups/users with the desired rights.
- Ensure the ACL is applied recursively to all subfolders and files.
“If you need to assign ACLs in bulk to cloud-only users, use the RestSetAcls PowerShell module to automate the process by using the Azure Files REST API. This module doesn't require network connectivity to Active Directory.”
Ensure all identities are Entra-synced when using Entra Kerberos
For Microsoft Entra Kerberos, ACL enforcement depends on identities being present in Entra:

“If you're using Microsoft Entra Kerberos to authenticate hybrid identities, the hybrid identities must be synced to Microsoft Entra ID for ACLs to be enforced.”

Old users/groups that were present before migration may have ACLs that still work because they are recognized identities. New Entra-only users/groups must be referenced correctly in ACLs via the portal or RestSetAcls so that their SIDs are included in the Kerberos ticket and evaluated correctly.
Check for MFA/Conditional Access blocking access
If Microsoft Entra Kerberos is used and Conditional Access MFA policies apply to the storage account app, access to Azure Files can fail in ways that look like permission issues. Ensure the storage account’s service principal is excluded from MFA policies:

“Microsoft Entra Kerberos doesn't support using MFA to access Azure file shares configured with Microsoft Entra Kerberos. You must exclude the Microsoft Entra app representing your storage account from your MFA conditional access policies… If you don't exclude MFA policies from the storage account app, you can't access the file share.”

Summary of practical steps:

Confirm the storage account uses Microsoft Entra Kerberos as the identity source.
Ensure each new Entra user/group has the correct share-level role on the file share.
In the Azure portal, on the target folder, use Manage access to add the new user/group and set Applies to: This folder, subfolders and files, then save.
Inspect subfolders/files for broken inheritance or explicit Deny ACEs; correct them via the portal or RestSetAcls with recursive application.
For large trees, use RestSetAcls to re-apply ACLs consistently.
Verify Conditional Access/MFA is not blocking access to the storage account app.

References:

Share via

Azure File Share ACL permission inheritance not working for new Entra ID users/groups

1 answer

Your answer