Taking ownership of folders in domain joined Azure File Share fails with access denied

Question

Taking ownership of folders in domain joined Azure File Share fails with access denied

Ukkaapie 31

Hi,

I have an issue where I have joined Azure Storage Account to our domain which has been successful. I can create folders in a file share and I can set permissions on the share.

We have a hybrid environment with AD Connect for the synchronisation. My admin account has Storage File Data SMB Share Elevated Contributor role assigned.

When I try to set the ownership on a folder/file, I get access denied. Even if I have created it and try to set it to my admin account it fails.

What I have tried:

Mapping a network drive using my admin account
Mapping a network drive using the storage account key
Setting the share level permission on the configure AD DS of the storage account (tried all 3 roles)

This happens on brand new storage accounts with no other information. We use private endpoints with VNets linked to DNS Resolver and Private DNS.

When I run "takeown.exe /F \<storage account>.file.core.windows.net<share>\Test", I get "The current logged on user does not have the ownership privileges on the fil (or folder) \<storage account>.file.core.windows.net<share>\Test"

Any help would be greatly appreciated as we have tried everything short of logging a ticket with Microsoft

Kind regards

1 answer

Your answer

Answer 1

Suwarna S Kale 3,951

Hello Ukkaapie,

Thank you for posting your question in the Microsoft Q&A forum.

The inability to set ownership on Azure Files despite having the Storage File Data SMB Share Elevated Contributor role typically stems from Active Directory permission gaps or authentication misconfigurations. While Azure RBAC grants share-level access, actual file/folder ownership requires explicit AD permissions, including Take Ownership rights at both the domain policy and AD computer object levels.

Hybrid environments often face synchronization delays via Azure AD Connect, preventing permission propagation, while Kerberos ticket or SPN issues can silently block ownership changes. DNS misresolution of private endpoints may force fallback to storage key authentication, which doesn’t support ownership operations. To resolve, verify AD permissions, force a delta sync, and validate Kerberos SPNs, while ensuring private endpoint DNS records correctly resolve. Tools like icacls can manually assign ownership if policies are correctly configured. For persistent issues, temporary Domain Admin rights or Azure Files REST API scripts may serve as workarounds. Always cross-check Event Viewer and Azure Storage metrics for underlying authentication failures.

If the above answer helped, please do not forget to "Accept Answer" as this may help other community members to refer the info if facing a similar issue. Your contribution to the Microsoft Q&A community is highly appreciated.

Ukkaapie 31 Reputation points

2025-07-25T10:11:00.0166667+00:00

Hi,

Network access to the storage is fine as the whole company has their relevant access dependant on the NTFS permissioning.

I forgot to mention that I am a Domain Admin and I can add/remove accounts from the NTFS permissions successfully. The only thing I cannot do is take ownership.

I have checked the SPN and the record is there on the storage domain account
Nandamuri Pranay Teja 4,445 Reputation points Microsoft External Staff Moderator

2025-07-25T12:23:10.18+00:00
Hello Ukkaapie,

Make sure that your admin account is assigned the Storage File Data SMB Share Elevated Contributor role at the file share level, not just at the storage account level. Since you are using Azure AD Connect for synchronization, ensure that the user account you are using is properly synchronized and that there are no issues with the synchronization process. You can check the Azure AD portal to confirm that your account is listed and that the attributes are correct.

Since you are using private endpoints, ensure that the configuration is correct:

Verify that the DNS settings are correctly resolving the private endpoint for the storage account. You can use tools like nslookup to check if the private DNS is resolving correctly. Ensure that there are no NSGs blocking access to the storage account from your virtual network.

Let me know if you have any Questions or concerns, I'm here to help.
Ukkaapie 31 Reputation points

2025-07-25T17:48:15.17+00:00

Hi,

My admin account is in a group that has the role "Storage File Data SMB Share Elevated Contributor" assigned to it. The file share has that role assigned too as it is inherited.

AD Sync is working fine as the attributes are syncing correctly across from Onprem AD to Azure AD. There are no errors relating to my admin account in the O365 Admin portal.

DNS resolution and network connectivity to the storage account is fine as I can browse to the files no problem and I can set the NTFS permissions on the folder using an onprem server.

Only thing I cannot do is set the owner
Nandamuri Pranay Teja 4,445 Reputation points Microsoft External Staff Moderator

2025-07-28T13:25:13.94+00:00

Hello Ukkaapie

The inability to set the owner of an Azure file share (especially the root) or easily transfer ownership is a design limitation when using AD DS/Azure AD DS authentication with Azure Files. Your "Storage File Data SMB Share Elevated Contributor" role is working as intended by allowing granular ACL management. You should manage access primarily through granular NTFS permissions rather than relying on changing ownership.

Let me know if you have any Questions or concerns, I'm here to help.
Ukkaapie 31 Reputation points

2025-07-29T06:39:03.4933333+00:00

My problem is that someone has removed all our access further down a tree and as non owner we cannot obtain access to fix the permissions.

Would you have any ideas how we could fix this?
Nandamuri Pranay Teja 4,445 Reputation points Microsoft External Staff Moderator

2025-07-29T11:09:05.1766667+00:00

Hello Ukkaapie

If you know who the current owner of the file share or directory is, reach out to them to request access or ask them to restore the necessary permissions. They can modify the ACLs to grant you the required access. else If you have the ability to assign roles, consider assigning yourself or your group a role that provides broader access, such as "Storage File Data SMB Share Contributor" or "Storage File Data SMB Share Elevated Contributor," at the storage account level. This may allow you to manage permissions on the file share.

You can check the Azure Activity Log to see if there are any entries related to permission changes. This may help you identify who made the changes and when, which can be useful information when contacting support or the current owner.

Let me know if you have any questions or concerns.
Richard Minichiello 0 Reputation points

2025-07-29T19:58:51.4233333+00:00

I'm having this same issue, but I'm not trying to change the ownership of the root of the share. I have a share with user folders in it. I'm trying to create new folders for users to move some data around and I want to create a new user folder in a share, then set the user as the owner using icacls. I get the access denied with my account, which has elevated contributor access. I also get the same access denied if I try though file explorer.
Ukkaapie 31 Reputation points

2025-07-30T06:36:33.24+00:00

I too am trying further down the tree and not at the root.

I did a query on Grok and it came back saying this is not supported right now but can be done using the Access Key. Tried that and everything else to take ownership. Even tried brand new storage accounts to no avail.

It does seem that it may not be supported on Azure Domain Joined File Shares
Ukkaapie 31 Reputation points

2025-07-30T12:12:00.16+00:00

Funny thing has happened. Suddenly I can set the owner on the files/folders.

Weirdest thing is someone with the same permissions ie Domain Admins cannot set the ownership even when logged in on the same machine I am working from
Nandamuri Pranay Teja 4,445 Reputation points Microsoft External Staff Moderator

2025-08-05T09:56:05.33+00:00

Hello Ukkaapie

The behavior you experienced highlights the complexities of managing permissions in a hybrid environment with Azure Files and Azure AD Domain Services. It's essential to remain vigilant and proactive in monitoring permissions and addressing any inconsistencies as they arise.

Sometimes, permissions changes or session tokens may not propagate immediately. If you had recently logged in or refreshed your session, it might have allowed your permissions to take effect, while others may not have experienced the same refresh.

If you encounter further issues, don't hesitate to reach out.
Richard Minichiello 0 Reputation points

2025-08-05T14:02:38.2466667+00:00

@Ukkaapie - What RBAC permissions do you have on the Storage Account and the file share that were created? I have validated that my account has the SMB Elevated Contributor role for both the SA and the share, and I still cannot change ownership of folders further down the tree (not the root). The account I have is a domain admin on the local domain as well.
Nandamuri Pranay Teja 4,445 Reputation points Microsoft External Staff Moderator

2025-08-07T03:57:14.7166667+00:00

Hello Ukkaapie

I wanted to follow-up to see if you had the chance to check the above-mentioned comment And, if you have any further queries do let us know.

Share via

Taking ownership of folders in domain joined Azure File Share fails with access denied

1 answer

Your answer