Share via

AzCopy Copy from File Share to Blob Fails in Container with 400 Error – Missing Required Header

Sree Venkatesh Yelamolu 0 Reputation points
2025-09-11T05:06:00.98+00:00

Hi Team,

I’m encountering a problem using AzCopy to copy files from an Azure File Share to a Blob container within the same storage account, using a containerized Azure Durable Functions app authenticated via a user-assigned managed identity (UAMI).

Here are the details:

  • AzCopy Version: 10.30.0
  • Environment: Container running in Azure Functions (Durable), using managed identity for auth
  • Environment variables set in the container:
    • AZCOPY_AUTO_LOGIN_TYPE=MSI
    • AZCOPY_MSI_CLIENT_ID=<client-id-of-uami>
  • Command used (sanitized): 
      azcopy copy "https://<storageaccount>.file.core.windows.net/<share>/<path>" "https://<storageaccount>.blob.core.windows.net/<container>/<path>"
  • Permissions: 
    •     "permissions": [
                {
                    "actions": [
                        "Microsoft.Storage/storageAccounts/blobServices/containers/read",
                        "Microsoft.Storage/storageAccounts/fileServices/shares/read",
                        "Microsoft.Storage/storageAccounts/listkeys/action",
                        "Microsoft.Storage/storageAccounts/listAccountSas/action"
                    ],
                    "notActions": [],
                    "dataActions": [
                        "Microsoft.Storage/storageAccounts/fileServices/fileshares/files/read",
                        "Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action",
                        "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete",
                        "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read",
                        "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write"
                    ],
                    "notDataActions": []
                }
            ]
        }
    • Verified that the same custom role assigned to my user id works when running the same command locally in PowerShell.
  • Error: 
      COPYFAILED: <source-path> 400 : 400 An HTTP header that's mandatory for this request is not specified.

When Committing block list. Response Details: <Code>CannotVerifyCopySource</Code> <Message>An HTTP header that's mandatory for this request is not specified.</Message> <CopySourceStatusCode>400</CopySourceStatusCode> <CopySourceErrorCode>MissingRequiredHeader</CopySourceErrorCode> <CopySourceErrorMessage>An HTTP header that's mandatory for this request is not specified.</CopySourceErrorMessage> X-Ms-Request-Id: b7fd2b00-501e-009f-71cb-22f397000000

  
---
**Question:**

Why does this error occur only in the containerized environment using managed identity? Is there a missing configuration or environment setting required for AzCopy to copy from file share to blob in a managed identity context?

Thanks in advance!
Azure Storage
Azure Storage

Globally unique resources that provide access to data management services and serve as the parent namespace for the services.

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Anonymous
    2025-09-11T07:56:53.9133333+00:00

    Hi Sree Venkatesh Yelamolu,

    I understand that you trying to copy files from an Azure File Share to a Blob container within the same storage account, using a containerized Azure Durable Functions app authenticated via a user-assigned managed identity (UAMI) by using azcopy command however getting error as <CannotVerifyCopySource>

    This indicates that the Azure Storage service at the destination is unable to authenticate or authorize access to the source blob. Even with public access on the source blob, the copy operation itself still requires proper authorization from the destination's perspective.

    It may works locally because AzCopy uses your interactive login context, which has full access and can generate the necessary headers but while running inside a containerized Azure Function using UAMI, AzCopy relies on MSI-based token acquisition & the source file share that may not be accessible due to network restrictions or missing role assignments

    Solution:

    Grant the managed identity "Storage Blob Data Contributor" role to the UAMI at both the source and destination storage account levels. "The Data Reader" role may not be sufficient for copy operations.

    In the Azure portal, go to the source storage account and check the "Firewalls and virtual networks" settings. Ensure that the "Allow Azure services on the services list to access this storage account" option is enabled. This allows services within Azure (like the destination storage account's copy operation) to access the source. If there are specific network restrictions, you might need to add the virtual network or IP address of the service performing the copy to the allowed list, since you're using a managed identity, allowing Azure services is usually the better option.

    If Private Link is enabled, you might need to allow public access to the source storage account in addition to use the managed identity. This is because the copy operation might be initiated from a service that doesn't use the private endpoint.

    Ensure both services are in the same virtual network.

    Try a very simple copy operation (e.g., copying a small text file) to isolate the issue. This can help determine the problem specifically.

    If you find this comment helpful, please “up-vote” for the information provided , this can be beneficial to community members.

    Kindly let us know if you have any additional questions.

    Thanks

    Was this answer helpful?

    0 comments
  2. Alex Burlachenko 20,825 Reputation points MVP Volunteer Moderator
    2025-09-11T07:22:09.0233333+00:00

    hi,

    the core issue is likely how azcopy authenticates when using managed identity versus how u do it locally. when u run it locally with your user, it probably uses a key or your user token. but inside the container with msi, the authentication context is different.

    the error points to a problem when the blob service tries to verify the source file during the copy. it's missing a specific header it expects from the source. this often boils down to the 'x-ms-version' header for the file storage request. different azure storage api versions can require different headers.

    first, try explicitly setting the api version for the source file share in your azcopy command. u can do this with the --recursive flag and by specifying the log level for more details, but the real trick is to force the source protocol.

    add this to your command: --check-length=false

    sometimes this helps because it skips a length verification step that can cause issues with the file share source.

    also, make sure your managed identity has the classic storage account contributor role on the storage account itself, just as a test. even though your custom role looks right, sometimes the built in roles have hidden permissions that are needed for these internal operations. this might help in other tools too, when moving data between storage services.

    another thing worth looking into is the azcopy environment variable for the log level. set AZCOPY_LOG_LEVEL=DEBUG and run the command again. the debug logs might show the exact headers being sent and which one is missing. its a bit verbose but can pinpoint the problem.

    finally, check the version of azcopy in your container. you said 10.30.0, but maybe try updating to the very latest version. sometimes these bugs get fixed in newer releases.

    hope one of these ideas gets your copy moving! let us know what the debug logs show ))

    Best regards,

    Alex

    and "yes" if you would follow me at Q&A - personaly thx.
P.S. If my answer help to you, please Accept my answer

    https://ctrlaltdel.blog/

    Was this answer helpful?

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.