Unable to copy files from One storage account to another using Az Copy

Question

Unable to copy files from One storage account to another using Az Copy

Shwetha J 15

We encountered the error CannotVerifyCopySource when using AzCopy with SAS tokens to copy data between two Azure File Shares.

We are attempting to copy data between two Azure Storage accounts using AzCopy with SAS tokens.

Both source and destination accounts are configured with private endpoints only.

Public network access is disabled on both accounts.

The operation fails with error: CannotVerifyCopySource.

When we temporarily enable public network access, the copy works as expected.

Question: Can you confirm if this is a known product limitation — that AzCopy with SAS tokens requires public endpoint access for validation and cannot work when both accounts are restricted to private endpoints? If so, is the only supported workaround to either enable public access or perform a two-step copy (download + upload)?

2 answers

Your answer

Answer 1

Yes, the issue you are encountering with AzCopy and the error CannotVerifyCopySource when both source and destination Azure Storage accounts are configured with private endpoints is a known limitation. AzCopy requires public endpoint access for validation when using SAS tokens, which is why the operation fails with private endpoint configurations.

The only supported workarounds in this scenario are to either enable public network access temporarily or to perform a two-step copy process, where you first download the data to a local machine and then upload it to the destination account.

References:

Answer 2

Hello @Shwetha,

Welcome to Microsoft Q&A Platform & thank you for reaching out.

I understand your question regarding the issue with copying files between Azure Storage accounts using AzCopy and encountering the error "CannotVerifyCopySource." This seems related to the configuration of your private endpoints.

Here's what you need to know:

Error Details: The error you're seeing typically occurs because AzCopy is unable to verify the source when both source and destination storage accounts are configured with private endpoints and public network access is disabled.
Product Limitation: Yes, this behavior can indeed be considered a known limitation with AzCopy when used with SAS tokens for accounts that have been set up with only private endpoints. For AzCopy to verify the source for the copy operation, it may need access to the public internet.
Workarounds:
- The quickest way to bypass this error is to temporarily enable public network access as you already found out, which allows the copy operation to succeed.
- Alternatively, you can adopt the two-step approach of first downloading the content from the source account and then uploading it to the destination account, though this may be less efficient.

For your next steps, if you'd like more optimized solutions, consider checking if your network environment allows certain configurations to manage the transfer process better while maintaining security.

Relevant Documentation:

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

https://learn.microsoft.com/en-us/troubleshoot/azure/azure-storage/blobs/connectivity/copy-blobs-between-storage-accounts-network-restriction#scenario-2-the-clients-vnet-has-private-links-configured-and-it-uses-a-private-endpoint-to-access-storage-accounts

Kindly let us know if the above helps or you need further assistance on this issue.

Shwetha J 15 Reputation points

2025-12-03T07:02:41.3433333+00:00

let me check, please allow me some time.
Shwetha J 15 Reputation points

2025-12-03T09:52:41.37+00:00

Hi @Jeevan,

Thank you for the response.

If I understand correctly, copying/syncing with SAS tokens are not supported with Private Endpoints.

So my questions is, if we use EntraID authentication (like a managed identity or a user account with the appropriate RBACS), can we circumvent this limitation?
Jeevan Shanigarapu 3,275 Reputation points Microsoft External Staff Moderator

2025-12-03T21:51:49.12+00:00

Hello @Shwetha,

Thanks for following up. This behavior is expected and it’s about network connectivity, not the type of authentication.

Switching to Microsoft Entra ID (managed identity or user account) won’t solve the issue. AzCopy uses a server-to-server copy, where the destination storage account pulls data directly from the source. For that to work, both accounts need to be able to talk to each other over the configured endpoints. Changing from SAS to Entra ID doesn’t change that path or bypass private endpoint restrictions.

If public access stays disabled, here are your options:

Private networking: Put both storage accounts’ private endpoints in the same VNet, or set up direct VNet peering between the two VNets and make sure private DNS (privatelink.blob.core.windows.net / privatelink.file.core.windows.net) resolves correctly across them.

Workaround: Use a two-step copy (download locally, then upload).

For more details, check Microsoft Docs: Use AzCopy to copy blobs between storage accounts with network restrictions.

Share via

Unable to copy files from One storage account to another using Az Copy

2 answers

Your answer