## 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
```text
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