Azure Files Robocopy Error Access Denied when copying NTFS Permissions

Question

I've setup a storage account and Azure file share following online instructions. I have added the storage account to AD as a computer account. I can map the drive create, delete, and modify files and NTFS permissions in that share via the GUI (Explorer.exe). However when I try to use robocopy it errors out when trying to copy the NTFS permissions over. I used the DATSO switch and always get the error "Destination May Not be NTFS" & "ERROR 5 (0x00000005) Copying NTFS to Destination Directory Access is Denied".

The account being used is a domain admin and has SMB Elevated contributor rights on the share. I don't understand why I can do everything through Explore (GUI) but robocopy fails when telling it to copy NTFS permissions over.

Answer 1

@Greenfield, Brian
It is a common scenario to robocopy files between file servers. Unfortunately, this scenario is currently broken using AD Authentication for Azure Files. Whenever a request to add a file comes in to Azure Files, if the request is over a Kerberos (authenticated via AD) session, an access check happens to see if the caller has permissions to add a file under the parent directory of the file.

For example, if a user is using robocopy with “/sec”, when robocopy transfers a file to the destination, the following access checks occur.

• Does the AD user executing robocopy have the permission to add a file or directory under the file’s parent? This checks if FILE_ADD_FILE permission is granted to the user in the file’s parent directory.
• Does the AD user executing robocopy have the permission to set an ACL on the file? This checks if the user has WRITE_DAC permission to the file.
• Does the AD user executing robocopy have the permission to set the owner on the file? This checks if the user has WRITE_OWNER permission to the file.

Unfortunately, with check #3, there is currently no AD user that has “Take Ownership” permission on the file share and can set the owner. So if robocopy requires setting the owner, it will fail with access denied.

We understand that this is a hole in our functionality and are working to address it. We are working on a feature that will add a “Take Ownership” RBAC permission for AD users to be authorized for.

In the meantime, the recommended solution for those affected by this missing functionality is to execute any robocopy after mounting the file share using storage account and key. When a user mounts via storage account and key, they mount as “super-users” and all access checks are skipped.

Hope this helps! Let us know if you have further questions or issues.

-------------------------------

Please don’t forget to "Accept the answer" and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

This answer assumes you already have your Azure File Share AD-joined.

Connect to the Azure FileShare using the Storage Key rather than Azure AD/On-Prem AD Credentials.

https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-ad-ds-assign-permissions

Important
Full administrative control of a file share, including the ability to take ownership of a file, requires using the storage account key. Administrative control is not supported with Azure AD credentials.

Assign it a drive using powershell, then you can robocopy. Enter Storage Key when prompted.

$DRIVELETTER=""  
$PATHTOAZFILESHARE=""  
$STORAGEACCOUNTNAME=""  
New-PSDrive -Name $DRIVELETTER -PSProvider FileSystem -Root $PATHTOAZFILESHARE -Persist -Credential Azure\$STORAGEACCOUNTNAME  

https://learn.microsoft.com/en-us/azure/storage/files/storage-files-migration-robocopy#phase-4-robocopy
I removed the /B flag

robocopy /MT:128 /R:1 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /UNILOG:<FilePathAndName> <SourcePath> <Dest.Path>

Answer 3

I used the /zb and it worked