azcopy to a container in a different resource group does not work?

Frederick Chang 20 Reputation points
2025-05-10T14:52:39.0766667+00:00

I am trying to azcopy data to a container located in a different resource group. This blob/container has the correct whitelisting of the IP from the VM requesting the transfer, and the user associated with azcopy login is credentialed as a storage blob contributor. (see below)

however, the container is in a different resource group as the VM, so I am wondering if there is flag to 

(azureml_py38) azureuser@testkuberay:~/cloudfiles/code$ azcopy logout
INFO: Logout succeeded.
INFO: azcopy 10.28.1: A newer version 10.29.0 is available to download
 
INFO: azcopy 10.28.1: A newer version 10.29.0 is available to download
 
(azureml_py38) azureuser@testkuberay:~/cloudfiles/code$ azcopy login --tenant-id xxxx
INFO: azcopy 10.28.1: A newer version 10.29.0 is available to download
 
INFO: Authentication is required. To sign in, open the webpage 
INFO: Login succeeded.
INFO: azcopy 10.28.1: A newer version 10.29.0 is available to download
 
(azureml_py38) azureuser@testkuberay:~/cloudfiles/code$ azcopy list 
INFO: azcopy 10.28.1: A newer version 10.29.0 is available to download
 
INFO: Autologin not specified.
INFO: Authenticating to source using Azure AD
 
failed to traverse container: cannot list files due to reason GET 
--------------------------------------------------------------------------------
RESPONSE 403: 403 This request is not authorized to perform this operation.
ERROR CODE: AuthorizationFailure
--------------------------------------------------------------------------------
<?xml version="1.0" encoding="utf-8"?><Error><Code>AuthorizationFailure</Code><Message>This request is not authorized to perform this operation.
RequestId:df5381d7-201e-0088-0255-bf3ff8000000
Time:2025-05-07T13:42:29.2534575Z</Message></Error>
 
az storage account show --name aksnfskekulai \ --resource-group test_aks \ --query networkRuleSet { "bypass": "AzureServices", "defaultAction": "Deny", "ipRules": [ { "action": "Allow", "ipAddressOrRange": "57.154.55.229" }, { "action": "Allow", "ipAddressOrRange": "70.95.68.176" } ], "ipv6Rules": [], "resourceAccessRules": [], "virtualNetworkRules": [ { "action": "Allow", "state": "Succeeded", "virtualNetworkResourceId": "/subscriptions/xxx/resourceGroups/MC_test_aks_test_aks_westus3/providers/Microsoft.Network/virtualNetworks/aks-vnet-18627786/subnets/aks-subnet" } ] } (azureml_py38) azureuser@testkuberay:~/cloudfiles/code$ curl ifconfig.me xxx
Azure Blob Storage
Azure Blob Storage

An Azure service that stores unstructured data in the cloud as blobs.

0 comments
Answer accepted by question author
Anonymous
2025-05-12T02:05:17.6833333+00:00

Hello Frederick Chang,

Thank you for your question!

The 403 AuthorizationFailure error indicates that the azcopy operation is being blocked, likely due to insufficient permissions or network restrictions, even though the user is a Storage Blob Data Contributor and the VM's IP is whitelisted. Since the container is in a different resource group from the VM, the issue might stem from cross-resource group access policies, network rules, or azcopy configuration.Ensure the Storage Blob Data Contributor role is assigned at the appropriate scope (e.g., storage account, resource group, or subscription level) for the storage account aksnfskekulai in the test_aks resource group.

The storage account’s network rules show defaultAction: Deny with specific IP whitelisting (57.154.55.229, 70.95.68.176) and a virtual network rule. Confirm the VM’s public IP matches one of the whitelisted IPs. You ran curl ifconfig.me, but the output is not visible in your query. Re-run and verify else

  • Navigate to Virtual Machines.
  • Search for and select the VM (testkuberay).
  • In the Overview pane, note the Public IP address. If no public IP is assigned, ensure the VM is using a public IP or is in the allowed VNet/subnet (aks-subnet).

Verify Storage Blob Data Contributor Role

  • go to Storage Accounts.
  • Search for and select the storage account aksnfskekulai in the test_aks resource group.

Access Control (IAM):

  • In the storage account’s left-hand menu, click Access Control (IAM).
  • Click Role assignments tab.
  • Search for the user or service principal used with azcopy login (e.g., the user tied to azcopy login --tenant-id).
  • Confirm the user has the Storage Blob Data Contributor role assigned at the storage account or resource group level.
  • If not assigned, proceed to add the role.

Firewall and Virtual Networks:

  • In the storage account (aksnfskekulai), go to Networking in the left-hand menu.
  • Select the Firewalls and virtual networks tab. Confirm the Public network access is set to Enabled from selected virtual networks and IP addresses.
  • Under Firewall, check the Address range section for the allowed IPs (57.154.55.229, 70.95.68.176). Under Virtual networks, confirm the VNet (aks-vnet-18627786) and subnet (aks-subnet) are listed.

Add VM’s Public IP (if not whitelisted):

  • If the VM’s public IP (from Step 1) is not listed, scroll to the Firewall section.
  • Click + Add IP address or + Add IP address range.
  • Enter the VM’s public IP (e.g., <vm-public-ip>).
  • Click Save.
  • Wait a few minutes for the network rule to take effect.

Note- Your azcopy version (10.28.1) is outdated. Update to the latest version (10.29.0 or newer) to avoid potential bugs:

wget https://aka.ms/downloadazcopy-v10-linux
tar -xvf downloadazcopy-v10-linux
sudo cp ./azcopy_linux_amd64_*/azcopy /usr/bin/

Hope the above answer helps! Please let us know do you have any further queries.

Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members. 
User's image

Was this answer helpful?

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Abiola Akinbade 30,500 Reputation points Volunteer Moderator
    2025-05-10T23:22:42.78+00:00

    It looks like the issue isn't necessarily related to the container being in a different resource group, but rather an authorization problem.

    Check the role assignments if they are assigned correctly. Your "Storage Blob Data Contributor" role needs to be assigned at the storage account level

    az role assignment list --assignee Upn --output table

    To also maybe confirm and isolate, I will recommend you test with a SAS token as well

    See: https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview

    You can mark it 'Accept Answer' and 'Upvote' if this helped you

    Regards,

    Abiola

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.