Azure Storage built-in role
Storage File Data SMB MI Admin
Provides a managed identity with administrative access to Azure Files over SMB, including read, write, delete, ACL modification, backup semantics, take ownership, and the built-in file-administrator mount privilege. It is a managed-identity service role, not an ordinary share-user role.
Role-definition permissions are imported from Microsoft Learn. Practical scope, use cases, prerequisites, best practices, security considerations, assignment guidance, and relationships have been reviewed against the official sources below.
Role definition ID: a235d3ee-5935-4cfb-8cc5-a3303ad5995e
Control-plane actions (0)
None — this role grants no control-plane management actions.
Data-plane actions (8)
Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/actionMicrosoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/actionMicrosoft.Storage/storageAccounts/fileServices/takeOwnership/actionMicrosoft.Storage/storageAccounts/fileServices/runAsBuiltInFileAdministrator/actionMicrosoft.Storage/storageAccounts/fileServices/fileshares/files/readMicrosoft.Storage/storageAccounts/fileServices/fileshares/files/writeMicrosoft.Storage/storageAccounts/fileServices/fileshares/files/deleteMicrosoft.Storage/storageAccounts/fileServices/fileshares/files/modifypermissions/action
Excluded actions (0)
None
Assignable scopes (1)
/
Practical scope
This is a data-plane role with no management-plane Actions. Microsoft's supported managed-identity workflow assigns it to the managed identity or application identity on the storage account that contains the share, giving the identity administrative file access across the account's file shares.
Common use cases (2)
- Allow a supported Windows or Linux Azure VM to mount an SMB Azure file share by using its system-assigned or user-assigned managed identity instead of a storage account key.
- Authorize an application identity for admin-level access to files and directories in an SMB Azure file share.
Prerequisites (3)
- Enable the SMBOAuth property on the storage account and create the SMB file share.
- Use a supported Windows or Linux client that is not joined to a domain, and configure a system-assigned or user-assigned managed identity or supported application identity.
- The assigning administrator needs Microsoft.Authorization/roleAssignments/write at the storage-account scope.
Best practices (3)
- Use managed-identity SMB authentication instead of exposing storage account keys.
- When a VM has both system-assigned and user-assigned identities, select one identity type for the workflow as Microsoft recommends.
- Configure automatic credential refresh after the first mount so access does not stop when the OAuth-backed credential expires.
Security considerations (3)
- The managed identity can read, modify, delete, take ownership of, and change ACLs on file data in scope and can mount with built-in administrator privilege.
- Workload compromise becomes file-administrator compromise for every share covered by the assignment.
- The role does not manage the storage account, but its data-plane authority is equivalent to an administrative file identity.
Assignment guidance
Follow the Azure Files managed-identity workflow: enable SMBOAuth, configure the VM managed identity or application identity, assign Storage File Data SMB MI Admin on the storage account, prepare the Windows or Linux client to obtain and refresh its OAuth-backed SMB credential, and then mount the share without a storage account key.
Common questions
When should I assign the Storage File Data SMB MI Admin Azure role?
Assign Storage File Data SMB MI Admin when you need to: Allow a supported Windows or Linux Azure VM to mount an SMB Azure file share by using its system-assigned or user-assigned managed identity instead of a storage account key.; and Authorize an application identity for admin-level access to files and directories in an SMB Azure file share.. Practical scope: This is a data-plane role with no management-plane Actions. Microsoft's supported managed-identity workflow assigns it to the managed identity or application identity on the storage account that contains the share, giving the identity administrative file access across the account's file shares.
What permissions does the Storage File Data SMB MI Admin Azure role grant?
The role definition grants 8 combined control-plane and data-plane actions. Representative operations include: Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action; Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action; Microsoft.Storage/storageAccounts/fileServices/takeOwnership/action; Microsoft.Storage/storageAccounts/fileServices/runAsBuiltInFileAdministrator/action; Microsoft.Storage/storageAccounts/fileServices/fileshares/files/read; and Microsoft.Storage/storageAccounts/fileServices/fileshares/files/write. Review the permission sections above for the complete definition and exclusions.
What are the security risks of the Storage File Data SMB MI Admin Azure role?
Key considerations when assigning Storage File Data SMB MI Admin: The managed identity can read, modify, delete, take ownership of, and change ACLs on file data in scope and can mount with built-in administrator privilege.; Workload compromise becomes file-administrator compromise for every share covered by the assignment.; and The role does not manage the storage account, but its data-plane authority is equivalent to an administrative file identity.. Follow the assignment guidance above and use the narrowest practical scope.
Editorial sources (4)
- Azure built-in roles for Storage →
Supports: Description, Practical scope, Security considerations. Retrieved 2026-07-16.
- Steps to assign an Azure role →
Supports: Prerequisites. Retrieved 2026-07-16.
- Understand scope for Azure RBAC →
Supports: Practical scope. Retrieved 2026-07-16.
- Use managed identities with Azure Files →
Supports: Description, Practical scope, Common use cases, Prerequisites, Best practices, Security considerations, Assignment guidance. Retrieved 2026-07-16.