Fix STATUS_OFFLOAD_READ_FILE_NOT_SUPPORTED (0XC000A2A3)

When does this error show up?

You're copying a big file—maybe a 20GB database backup or a video project—from a network drive (like a Synology NAS, a Windows file server, or a SAN) to your local SSD. Halfway through, Windows throws up the error: STATUS_OFFLOAD_READ_FILE_NOT_SUPPORTED (0XC000A2A3). The copy stops. You try again, same spot.

What's actually happening here?

Windows 10 and 11 have a feature called Offloaded Data Transfer (ODX). It's meant to speed up file copies by letting the storage hardware handle the copy directly, without bouncing all the data through your computer's CPU and RAM. Think of it like a fast lane for file transfers.

The problem: many network storage devices—especially older NAS boxes, some iSCSI targets, and consumer-grade routers with USB drives—don't support this offload feature properly. They claim they do, but when Windows tries to use it, they choke. The error code 0XC000A2A3 is Windows saying, "Hey, I tried the fast lane, but the storage device told me to take a hike."

The fix: disable offload support on the source drive

You need to turn off the offload read feature for the specific drive or volume where the file lives. Don't worry, this doesn't break anything else—it just makes Windows copy the normal way, which is slower but reliable.

What you'll need:

Administrator access on your Windows machine
The drive letter of the network share or volume (example: Z:)

Step-by-step

Open Command Prompt as admin. Press the Windows key, type cmd, right-click "Command Prompt" in the results, and choose "Run as administrator." Click Yes if UAC asks.
Identify the volume. Type fsutil volume list and press Enter. You'll see a list of volumes. Find the one that matches your failing drive (e.g., \\Volume{abc123}). Write down the drive letter (like Z:) or the volume GUID.
Check if offload is currently enabled. Run this command (replace Z: with your drive letter):
```
fsutil behavior query disableoffload
```
If it returns DisableOffload = 0, offload is on. That's the default.
Disable offload temporarily for this session. This is the quick test—it turns off offload for all drives until you reboot:
```
fsutil behavior set disableoffload 1
```
You'll see a message like "Set DisableOffload = 1."
Try the copy again. Go back to File Explorer, copy the file that failed. If it works now, you've confirmed the fix.
Make the change permanent (optional). If you want offload disabled permanently—because maybe you only have this one NAS that has the issue—run the same command as in step 4. It writes to the registry. If you ever need to re-enable it later, set it back to 0.

What to expect after applying the fix

After you run the command, Windows won't try to use ODX anymore. Copies will go at normal network speeds—maybe 50-100 MB/s instead of the faster offload speeds. But they won't fail with 0XC000A2A3. You should see the file transfer progress bar moving steadily.

What if the error still shows up?

Three things to check:

Did you run Command Prompt as admin? If you didn't, the fsutil command won't actually change anything. Re-run it with admin rights.
Is the source drive actually a network drive? Some local drives also trigger this error. If the drive is internal (like D:), check if it's an SSD with a firmware bug. Update the firmware from the manufacturer's site.
Is the file on a ReFS volume? Some ReFS implementations have their own offload quirks. In that case, you might need to copy the file to a NTFS volume first, then transfer to the network.

A quick note: If you're on a corporate network, your IT team might have disabled offload at the server level already. Check with them before making registry changes—they might have a better fix.

That's it. You should be copying files again without the 0XC000A2A3 error. If you run into trouble, reply below with your setup details (what NAS, what Windows version, drive format) and I'll help you narrow it down.