ERROR_EAS_NOT_SUPPORTED 0x11A fix: Extended attributes on old drives

When this error shows up

You're trying to copy a folder full of files to an external USB drive, a network share, or maybe an old NAS device. Halfway through, Windows throws ERROR_EAS_NOT_SUPPORTED (0X0000011A). The copy fails. It's not corrupt data—it's the file system on the target drive that refuses to play nice.

I've seen this most often on USB drives formatted as FAT32 or exFAT, and on older network shares running Samba on a Linux box that hasn't been updated since 2015. One client had a Buffalo LinkStation from 2012 that threw this every time they tried to back up their QuickBooks files. The extended attributes Windows wants to store—like encryption flags, indexing info, or file classification—aren't supported on those volumes.

Root cause in plain English

Extended attributes (EAs) are metadata tags Windows attaches to files. Things like "this file is encrypted" or "this file is part of a backup set". NTFS supports them. FAT32 does not. exFAT does not. And some older Samba shares don't support them either. When Windows tries to write a file with those attributes to a volume that can't store them, you get 0x11A.

It's not a disk failure. It's a format mismatch. The file itself usually copies fine, but the attributes get rejected.

Fix: Step by step

You have three options. Pick the one that fits your situation.

Option 1: Reformat the target drive to NTFS (best for USB drives)

1. Back up everything off the target drive first. Reformatting erases data.
2. Open Disk Management (right-click Start > Disk Management).
3. Right-click the target partition, choose Format.
4. Set File system to NTFS, Allocation unit size to Default.
5. Uncheck Quick Format if you want to scan for bad sectors, but Quick is fine for a known-good drive.
6. Click OK. Wait for it to finish.
7. Copy your files again. The error should be gone.

Option 2: Copy without extended attributes (for network shares or drives you can't reformat)

1. Open Command Prompt as Administrator.
2. Use robocopy with the /COPY:DATSO flag to skip EA copy. Run:
   

   robocopy C:\source D:\dest /E /COPY:DATSO /R:2 /W:5

   This copies Data, Attributes, Timestamps, Security (ACL), and Ownership—but skips extended attributes.
3. If the error persists, add /XA:SH to skip system and hidden files if those have EAs attached.
4. If you're using File Explorer, try copying files individually or in smaller batches. Sometimes the EA is tied to a specific file type (like .docx or .pdf with custom properties).

Option 3: Use fsutil to check and strip EAs on the source

1. Open Command Prompt as Administrator.
2. Run fsutil file queryEA C:\path\to\file to see if the file has EAs. Replace with your actual file path.
3. If you find a file with EAs, you can remove them with PowerShell:
   

   Remove-Item -LiteralPath "C:\path\to\file" -Force -Stream *

   But be careful—this strips all alternate data streams, which might corrupt some files. Test first.
4. Better approach: copy the whole folder to an NTFS drive first, then copy to the target. That way Windows handles the EA translation automatically.

What if it still fails?

If none of that works, the issue might be the target device itself. Old NAS units or network shares running outdated Samba versions (pre-4.0) often don't support EAs at all, even on NTFS-formatted volumes. Check the device's admin panel for a setting like "Enable Extended Attributes" or "NTFS Streams Support".

Also, run chkdsk D: /f on the target drive. Corrupted file system structures can trigger false EA errors. I had a client last month whose 4TB Seagate external drive threw 0x11A on every copy—turned out the partition table was slightly off. Quick format didn't help; a full chkdsk cleaned it up.

Last resort: use a different file copy tool like TeraCopy or FastCopy. They sometimes handle EA errors more gracefully, skipping the attribute and copying the file anyway. But that's a band-aid—reformatting to NTFS is the real fix.