Unable to create folders and assign permissions using CSE on Mounted Azure Fileshare

Question

I wanted to highlight an issue we encountered while automating the folder creation process on our Azure File Share during VM provisioning.

During the deployment, when our Custom Script Extension (CSE) attempts to create folders directly on the Azure File Share, it fails with the following error:

Test-Path : Access is denied

UnauthorizedAccessException

This happens because the script is executed under the LocalSystem context on the VM, and that identity does not have the necessary access rights to create directories or apply NTFS permissions. This is an architectural limitation: the CSE runs before any domain authentication is fully established for the machine identity.

What are the other ways to do it?
Thanks

Answer 1

HIi @ Monit Sharma,

Welcome to Microsoft Q&A Platform.

The Custom Script Extension (CSE) runs under the LocalSystem account before any domain or Azure AD authentication is in place, so it can’t authenticate to your Azure Files share to create folders or set NTFS ACLs. Here are a few alternate approaches you can try:

Post-domain-join script execution

• Join the VM to Azure AD DS, Microsoft Entra DS or your on-prem AD first.
  • Use the Run Command extension or a Task Scheduler job (running as a domain account) to invoke your folder-creation PowerShell after the VM completes domain join.
    • Mount the Azure Files share with your domain credentials and call Set-Acl in that context to create folders and set ACL inheritance.

Use an Azure AD–based identity (managed identity + RBAC)

• Enable identity-based auth on your file share and assign your VM’s system-assigned (or user-assigned) managed identity the “Storage File Data SMB Share Contributor” (to create directories) and “Storage File Data SMB Admin” (to manage ACLs) roles.
• Mount the share using Azure AD credentials (-o anon,username=<>) so Windows uses the VM’s managed identity under the hood.
  • Run your Custom Script Extension or Run Command PowerShell commands under that context to create folders and call Set-Acl.

You can also use the Azure Automation runbooks with a managed identity to perform post-provisioning steps.
Note: Please make sure to assign the Virtual Machine Administrator Login role to the VM identity or user if you are running it from CSE. Alternatively, you can use an Automation Runbook and assign the same role to the Automation Identity. This role has local administrator permissions.

Ref: Use the Azure portal to manage ACLs in Azure Data Lake Storage

If the above steps did not help resolve your issue, please feel free to share the details in a private message so we can proceed with further troubleshooting over a Teams call. I am happy to connect with you on Teams to investigate and resolve the issue.

Pleaseand “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

The Custom Script Extension (CSE) runs under the LocalSystem account, which cannot be granted Azure Files NTFS permissions. Because CSE always runs as LocalSystem and only once during provisioning, it cannot reliably perform identity-based operations (like creating folders and setting NTFS ACLs) on an Azure file share.

To implement this scenario, use one of these patterns instead of doing it directly in CSE:

1. Use CSE only to create a Scheduled Task that runs under a domain/Entra identity
   • Let CSE run a small script that:
     • Creates a Windows Scheduled Task.
     • Configures the task to run under a domain user, gMSA, or managed identity that has:
       • Share-level permissions on the Azure file share.
       • NTFS permissions to create folders and set ACLs.
     • Schedules the task to run at startup or once after domain join.
   • The actual folder creation and ACL logic runs inside that Scheduled Task, not in the CSE itself.
   • This aligns with the guidance that CSE is good for one-time setup and for creating Scheduled Tasks when recurring or delayed execution is needed.
2. Run the folder/ACL script later in the provisioning pipeline (outside CSE)
   • After the VM is domain-joined and the appropriate identity is available, run the script via:
     • Configuration tools (DSC, Chef, Puppet) triggered after domain join.
     • A separate automation step (for example, Azure Automation, pipeline agent, or management tool) that logs on with a privileged identity and configures the share.
   • Ensure the script mounts the Azure file share using an identity that has the required permissions, then creates folders and sets NTFS ACLs.
3. Pre-provision folders and ACLs from an admin workstation or management VM
   • Mount the Azure file share with admin-level access from a domain-joined machine using net use as documented:

          net use Z: \\\<YourStorageAccountName>.file.core.windows.net\\<FileShareName> /user:localhost\\<YourStorageAccountName> <YourStorageAccountKey>
     

   • Create the folder structure and set NTFS permissions in advance.
   • VMs then only consume the existing structure; no folder/ACL creation is required during CSE.
4. If using Azure File Sync with managed identity
   • Ensure the managed identities involved have the required roles on the storage account and file share (for example, Storage File Data Privileged Contributor) so that server endpoints can create and manage items on the share.
   • Use the File Sync agent/server to project the folder structure and permissions rather than CSE doing it directly.

Key points:

• CSE always runs as LocalSystem and is not suitable for identity-based Azure Files operations.
• Use CSE to bootstrap a Scheduled Task or configuration tool that runs under a proper identity after domain/Entra authentication is available.
• Alternatively, pre-stage the folder structure and ACLs from a machine where an admin identity can mount the share with sufficient privileges.

---

References:

• Custom Script Extension for Windows
• Configure directory and file-level permissions for Azure file shares
• Mount SMB Azure file share on Windows
• Troubleshoot Azure File Sync managed identity issues