Merge pull request #314720 from khdownie/kendownie041426

Clarify takeown useage

Author: prmerger-automator[bot]

articles/storage/files/storage-files-identity-configure-file-level-permissions.md

@@ -4,7 +4,7 @@ description: Learn how to configure Windows ACLs for directory-level and file-le
 author: khdownie
 ms.service: azure-file-storage
 ms.topic: how-to
-ms.date: 04/07/2026
+ms.date: 04/14/2026
 ms.author: kendownie
 # Customer intent: "As a system administrator, I want to configure directory-level and file-level permissions for SMB Azure file shares by using Windows ACLs, so that I can ensure granular access control and enhance security for users accessing shared files."
 ---
@@ -27,7 +27,7 @@ Before you can configure Windows ACLs, you need to mount the file share with adm
 
 ## How Azure RBAC and Windows ACLs work together
 
-Share-level permissions (RBAC) act as a high-level gatekeeper that determines whether a user can access the share. Windows ACLs (NTFS permissions) operate at a more granular level to control what operations the user can do at the directory or file level. You can set Windows ACLs at the root, directory, or file level.
+Share-level permissions (RBAC roles) act as a high-level gatekeeper that determines whether a user can access the share. Windows ACLs (NTFS permissions) operate at a more granular level to control what operations the user can do at the directory or file level. You can set Windows ACLs at the root, directory, or file level.
 
 When a user tries to access a file or directory, share-level, file-level, and directory-level permissions are enforced. If there are differences among them, only the most restrictive one applies.
 
@@ -45,8 +45,8 @@ The following table shows how share-level permissions and Windows ACLs work toge
    | **NTFS - Modify**       | Access denied | Read                       | Read, Write, Delete      | Read, Write, Delete, Apply permissions to your own folders/files |
    | **NTFS - Full**         | Access denied | Read                       | Read, Write, Delete      | Read, Write, Delete, Apply permissions to anyone's folders/files |
 
-> [!NOTE]
-> Taking ownership of folders or files for ACL configuration requires an additional RBAC permission. By using the [Windows permission model for SMB admin](#use-the-windows-permission-model-for-smb-admin), you can grant this permission by assigning the built-in RBAC role [Storage File Data SMB Admin](/azure/role-based-access-control/built-in-roles/storage#storage-file-data-smb-admin). This role includes the `takeOwnership` permission.
+
+To configure ACLs by using identity-based authentication instead of a storage account key (recommended), you'll need an additional RBAC role: [Storage File Data SMB Admin](/azure/role-based-access-control/built-in-roles/storage#storage-file-data-smb-admin). This role grants share-level access and the `takeOwnership` permission, which allows a user to take ownership of any file or directory by using the Windows `takeown` command, even if there's no existing ACL entry. After taking ownership, the user can modify ACLs. For details, see [Use the Windows permission model for SMB admin](#use-the-windows-permission-model-for-smb-admin).
 
 ## Supported Windows ACLs
 
@@ -76,17 +76,20 @@ For more information on these permissions, see the [command-line reference for i
 
 Before you configure Windows ACLs, mount the file share with admin-level access. You can take two approaches:
 
-- **Use the Windows permission model for SMB admin (recommended)**: Assign the built-in RBAC role [Storage File Data SMB Admin](/azure/role-based-access-control/built-in-roles/storage#storage-file-data-smb-admin). This role includes the required permissions for users who configure ACLs. Then mount the file share by using [identity-based authentication](storage-files-active-directory-overview.md) and configure ACLs. This approach is more secure because it doesn't require your storage account key to mount the file share.
+- **Use the Windows permission model for SMB admin (recommended)**: Assign the built-in RBAC role [Storage File Data SMB Admin](/azure/role-based-access-control/built-in-roles/storage#storage-file-data-smb-admin) to admin users who will configure ACLs. Then mount the file share by using [identity-based authentication](storage-files-active-directory-overview.md) and configure ACLs. If an existing ACL on a file or directory denies the admin access, the admin can use the Windows `takeown` command to take ownership of the file or directory and then modify the ACL. This approach is more secure because it doesn't require your storage account key to mount the file share.
 
-- **Use the storage account key (less secure)**: Use your storage account key to mount the file share and then configure ACLs. The storage account key is a sensitive credential. For security reasons, use this option only if you can't use identity-based authentication.
+- **Use the storage account key (less secure)**: Use your storage account key to mount the file share and then configure ACLs. Mounting with a storage account key gives you immediate full access without needing to take ownership of files or directories. The storage account key is a sensitive credential. For security reasons, use this option only if you can't use identity-based authentication.
 
 If a user has the Full Control ACL and the [Storage File Data SMB Share Elevated Contributor](/azure/role-based-access-control/built-in-roles/storage#storage-file-data-smb-share-elevated-contributor) role (or a custom role with the required permissions), they can configure ACLs without using the Windows permission model for SMB admin or the storage account key.
 
 ### Use the Windows permission model for SMB admin
 
-Use the Windows permission model for SMB admin instead of the storage account key. This feature enables you to assign the built-in RBAC role [Storage File Data SMB Admin](/azure/role-based-access-control/built-in-roles/storage#storage-file-data-smb-admin) to users, so they can take ownership of a file or directory to configure ACLs.
+Use the Windows permission model for SMB admin instead of the storage account key. This feature enables you to assign the built-in RBAC role [Storage File Data SMB Admin](/azure/role-based-access-control/built-in-roles/storage#storage-file-data-smb-admin) to admin users, so they can mount the share using identity-based authentication and configure ACLs.
 
-The Storage File Data SMB Admin RBAC role doesn't grant the identity direct access to a file or directory if the identity isn't granted the proper permission (such as Modify or Full Control) in the target file's or directory's ACL. However, the identity with the Storage File Data SMB Admin RBAC role can take ownership of the target file or directory by using the Windows [`takeown`](/windows-server/administration/windows-commands/takeown) command, and then modify the ACL to grant proper access permissions.
+If an existing ACL on a file or directory grants the admin sufficient permissions (such as Modify or Full Control), the admin can configure ACLs directly. If the existing ACL denies access, the admin can use the Windows [`takeown`](/windows-server/administration/windows-commands/takeown) command to take ownership of the target file or directory, and then modify the ACL to grant the appropriate access permissions.
+
+> [!NOTE]
+> Assigning the Storage File Data SMB Admin RBAC role doesn't work the same way as authenticating with a storage account key. When you mount a share with a storage account key, you get immediate full access to all files and directories without needing to take ownership. With the Storage File Data SMB Admin role, the existing ACLs still apply for normal file access. The role grants the special privilege to take ownership of any file or directory by using the `takeown` command, which is only needed when the existing ACL doesn't grant the admin sufficient permissions to modify ACLs.
 
 The Storage File Data SMB Admin RBAC role includes the following three data actions: