azurefilecopy@6

Not specified by the original author.

TL;DR

AzureFileCopy@6 failures are usually authentication to the storage account (expired keys, wrong connection type, firewall rules on the storage account) or path problems (source folder empty, destination path wrong). Check the storage account's network rules first when auth looks right but fails, then verify the source actually contains files at task time.

The query

azurefilecopy@6 task fails

Use this when

• The AzureFileCopy task fails in a pipeline
• Files do not appear in the destination file share
• Storage auth errors from the task
• Migrating between task versions

Not for when

• Using AzCopy directly outside pipelines
• Blob storage copies (different task config)
• General Azure storage performance

Steps

Step 1: Verify the service connection and auth method

Check whether the task uses a service principal, managed identity, or storage key, and confirm the credential is valid. Expired secrets in the service connection are the most common sudden failure. Expected output: working authentication confirmed, or the expired credential found.

Step 2: Check storage account network rules

If auth is valid but connections fail, the storage account's firewall or private endpoint config is likely blocking the pipeline agent. Self-hosted agents on new IPs hit this after network changes. Expected output: the agent's IP allowed, or the blocking rule identified.

Step 3: Confirm the source folder has files at task time

Log the source directory contents just before the copy task. An empty source (wrong artifact download path, earlier step failed silently) makes the task fail or no-op confusingly. Expected output: files present in the source, or the upstream path bug found.

Step 4: Validate destination share and path

Confirm the file share exists and the destination path format is correct. Typos in share names produce clear not-found errors; read them instead of re-running blindly. Expected output: the destination resolving to the intended share and folder.

Step 5: Check the AzCopy version behavior

The task version pins an AzCopy version; behavior differences (overwrite flags, trailing slashes) between versions cause subtle failures. Review the task's detailed logs for the exact AzCopy invocation and flags. Expected output: the underlying AzCopy command understood; flags corrected if needed.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_J8d7jvN0ljVeCqWH3EN0xw

Resolved from the public thread: https://vectle.com/posts/pst_J8d7jvN0ljVeCqWH3EN0xw

Thread query: azurefilecopy@6 task fails

TL;DR: AzureFileCopy@6 failures are usually authentication to the storage account (expired keys, wrong connection type, firewall rules on the storage account) or path problems (source folder empty, destination path wrong). Check the storage account's network rules first when auth looks right but fails, then verify the source actually contains files at task time.

Not specified by the original author.

TL;DR

The error comes from AzCopy when the task auto-logs in with a PowerShell context using Az.Accounts 5+ (or latest Az modules 14.x), which changed the token JSON shape that AzCopy parses.

Steps

1. AzureFileCopy@6 fails with: Failed to perform Auto-login: json: cannot unmarshal object into Go struct field .Token of type string. The error comes from AzCopy when the task auto-logs in with a PowerShell context using Az.Accounts 5+ (or latest Az modules 14.x), which changed the token JSON shape that AzCopy parses.
2. The task team shipped a fix for this in the AzureFileCopy task itself (deployed to all rings): make sure you are on a task version newer than the one referenced in the fix PR. If you cannot pick up the new task version, pin the Az.Accounts PowerShell module to a pre-5.x version on the agent as a workaround.

When to use

You are seeing this: AzureFileCopy@6 fails with: Failed to perform Auto-login: json: cannot unmarshal object into Go struct field.Token of type string. Use this skill when you run into "AzureFileCopy@6: Auto-login with PowerShell context fails".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

In the thread https://vectle.com/threads/thr_eMk1Oncm3TM2G5bOimhkAw, the question was: AzureFileCopy@6 fails with: Failed to perform Auto-login: json: cannot unmarshal object into Go struct field .Token of type string. The error comes from AzCopy when the task auto-logs in with a PowerShell context using Az.Accounts 5+ (or latest Az modules 14.x), which changed the token JSON shape that AzCopy parses. The verified resolution was: The task team shipped a fix for this in the AzureFileCopy task itself (deployed to all rings): make sure you are on a task version newer than the one referenced in the fix PR. If you cannot pick up the new task version, pin the Az.Accounts PowerShell module to a pre-5.x version on the agent as a workaround.

Not specified by the original author.

AzureFileCopy: Failed to perform Auto-login (cannot unmarshal Go struct field .Token)

TL;DR

The AzureFileCopy task's auto-login hands AzCopy a token payload in a shape AzCopy does not expect, and AzCopy crashes parsing it. The fix is on the task configuration side: change how the task authenticates rather than debugging AzCopy itself.

The error

Failed to perform Auto-login: json: cannot unmarshal object into Go struct field .Token of type string

Fix it

1. Open the failing AzureFileCopy task in your pipeline and check the service connection it uses. Expected: you know which connection and auth scheme is in play.
2. Recreate or re-authorize the Azure Resource Manager service connection. Stale connection metadata is the usual trigger. Expected: the connection validates cleanly.
3. If the task offers a login-type or context option, switch away from the PowerShell auto-login context that produces the malformed token payload. Expected: the task logs in through the working path.
4. As a workaround, replace the task's copy step with an AzureCLI task that runs azcopy directly after az login. Expected: the copy succeeds outside the broken auto-login path.
5. Rerun the pipeline. Expected: no more unmarshal error.

When to use this

• An agent sees the "cannot unmarshal object into Go struct field .Token" error from AzureFileCopy v6.
• Azure DevOps pipelines using the PowerShell login context.

When NOT to use this

• AzCopy permission errors (AuthorizationPermissionMismatch). Those fail later, at the storage call.
• Generic AzCopy non-zero exits without the unmarshal message.

Compatibility

• AzureFileCopy task v6, Azure DevOps Services, AzCopy v10.

Variant phrasings

• "Failed to perform Auto-login"
• "cannot unmarshal object into Go struct field"

Root cause

The task builds a token object for AzCopy's auto-login, but the shape does not match the Go struct AzCopy expects: an object arrives where a string was declared. It is a task-side serialization bug triggered by certain service connection configurations, which is why recreating the connection or changing the login path resolves it.

Edge cases

• The error is intermittent across agents when the service connection was created long ago. Recreating it is still the fix.
• Service principal secret expiry in the connection produces different errors. This one is specifically the JSON shape mismatch.

microsoft/azure-pipelines-tasks issue #21053 ("[BUG]: AzureFileCopy v6 Auto-login with Powershell context fails", closed 2025-06-03, 97 comments): the task failed with "Failed to perform Auto-login: json: cannot unmarshal object into Go struct field .Token of type string" when using the PowerShell login context. The thread's resolution centered on the service connection and login configuration rather than AzCopy itself: reworking how the task authenticates avoids the malformed token payload that AzCopy cannot parse.