Azcopy error "This request is not authorized to perform this operation."

Question

I copied a container to another storage account based on the document linked below. (DataLake Storage Gen2).

When trying, I got the following error:

this request not authorized to perform this operations using this permission

https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-v10

Embodiment

Please edit your question and include the exact azcopy command you're using (obfuscate secret things like account key etc. obviously). – Sickle

Could you please which type of authorization credentials(learn.microsoft.com/en-us/azure/storage/common/…) you use? – Shelli

Answer 1

The SAS token has probably expired.

Henri

Answer 2

If you are using AAD Token, this error is telling you that you need to add a role assignment to the user. Please go to Storage account -> Access Control -> Add -> Add role assignment, then add Storage Blob Data Owner to your login account.

If this problem persists, please provide more details.

Loper

Note that it might take up to 5 minutes to propagate the RBAC rule! Source. – Aharon

@Aharon Thank you sharing your thought. I was getting the same error even after I had added myself to Storage Blob Data Owner role. But after waiting for 5 minutes or so, the AzCopy command successfully uploaded the file to Azure Blob storage. – Everyone

I was convinced having the Owner role gave me enough permissions, thanks for this answer. (Re: Add Role Assignment 'Storage Blob Data Owner') – Innovate

Can anyone explain why the Owner role isn't enough-the Role Definition has the following permissions: Name : Owner Actions : { * } NotActions : {} DataActions : {} NotDataActions : {} AssignableScopes : {/} Storage Blob Data Owner has: Actions : {Microsoft.Storage/storageAccounts/b lobServices/containers/*, ... NotActions : {} DataActions : {Microsoft.Storage/storageAccounts/b lobServices/containers/blobs/*} NotDataActions : {} AssignableScopes : {/} – Innovate

Answer 3

After granting myself with role Storage Blob Data Owner on the container, then AzCopy will now behave itself and succeed in copying a file to the blob storage container.

go to storageaccount -> container -> Access control rules -> add role assignement -> Storage Blob Data Owner

Farro

This also solved it for me. Shouldn't be necessary though as my service principal was already a Contributor to the resource group. – Iluminadailwain

Answer 4

I also faced the same problem. For me to work I just log out and log in again on the azcopy cli after doing the @BowmanZhu solution

azcopy logout
azcopy login --tenant-id xxxx-xxxx-xxxx

If you don't want to login that way there is always the option to add a SAS token at the end of the URL. If you don't want to attach the token always at the end you can try for permanent access by going through any one of these steps you find in the official documentation page.

Scaliger

Answer 5

In my case, my azure storage account vnet address was blocking the azcopy from copying the data over the storage account.

I added my client IP to allow a firewall address.

Laceylach

Thank you, I didn't even know this existed! – Capers

Answer 6

When I had this, I discovered it was because I'd used Azure Storage Explorer to generate a SAS that didn't have read permission, and I think it was trying to read the size/existence of a blob before writing it.

I got a clue from https://github.com/Azure/azure-storage-azcopy/issues/790 but ultimately I just regenerated a new SAS with read permission and it worked out..

I probably could ahve looked to modify the C# code using Azure Data Movement lib, to not perform a length check, but the spec was later changed to "don't overwrite" so the read permissions are probably needed anyway

Centesimal

Answer 7

Give appropriate permissions(read, write, create) while generating SAS tokens as here

Selfidentity

Answer 8

Had a similar issue. That's how was resolved

Command used was .\azcopy.exe copy "C:\Users\kriof\Pictures" "https://test645676535storageaccount.blob.core.windows.net/images?sp=rw&st=2022-02-23T11:03:50Z&se=2022-02-23T19:03:50Z&spr=https&sv=2020-08-04&sr=c&sig=QRN%2SMFtU3zaUdd4adRddNFjM2K4ik7tNPSi2WRL0%3D"

SAS token had default(Read) permission only. Adding Write permission in Azure Portal, resolved the issue.

Orthoclase

Answer 9

I just spent 3 hours on this, everyone, please make sure you select the correct user in the select member step, paste the principal name on the textbox and make sure it is the one your pipeline uses

Contraposition

Answer 10

I spent to much time on this..

Finally what worked for us was using the following.

Make sure the account u use to run the command had the role on the storageaccount: Storage Blob Data Owner.

U can add the Firewall IP if needed we did it just in case. The SAS url does not always auto create the "?" need to add that ur self.

https://stgrobackendlogs.blob.core.windows.net/papercutlogs/" ? " <--

The deletion string --delete-destination=true:changes made to the source are now also edited at the destination.

We run a schedule task if the SAS string contains a " % " u need to add another one other wise it won't work.

Also don't create the SAS token on the blob, but on the storageaccount!

Final: azcopy.exe sync "E:\Program Files\PaperCut MF\server\lib-ext" "https://stgrobackendlogs.blob.core.windows.net/papercutlogs/?sv=2022-11-02&ss=bffdsfresfdsdsddsfgrggr2iFrqvdQ5sdsdsdqQ3mvvvQiylVqvWoo%%3D" --delete-destination=true

I hope this saves some of u guys time ;)

Abranchiate