Yeah, error -36 is a pain. You're dragging files to an external drive or network share, and halfway through, Finder throws that ugly "The operation can't be completed because an unexpected error occurred (code -36)." Don't panic — it's almost always fixable in a couple of minutes.
The Quick Fix: Strip Metadata and Retry
The culprit here is almost always macOS metadata — those invisible ._ files and extended attributes that Finder insists on writing. When the destination filesystem chokes on them (usually FAT32, exFAT, or an older SMB server), you get -36.
- Open Terminal (it's in Applications → Utilities).
- Copy the file using
rsyncinstead of Finder. This is the real fix. Run this:
rsync -av --no-perms --no-owner --no-group /path/to/source/ /Volumes/YourDrive/
That command strips the metadata that Finder can't handle. If you only need a few files, you can also do this:
cp -R /path/to/file /Volumes/YourDrive/
But cp sometimes keeps the metadata. rsync is your friend here.
If the error happens on a specific file, clear its flags first:
chflags nouchg /path/to/file
xattr -c /path/to/file
The first command removes the uchg (user immutable) flag. The second clears all extended attributes. Either one could be the trigger.
Why This Works
Error -36 is an I/O error, but it's not about bad sectors or a dying drive. It's about permission and metadata — specifically, the com.apple.quarantine attribute or Spotlight metadata that Finder adds. When the destination filesystem doesn't support those attributes (exFAT is the usual suspect), it returns an error. The copy fails, but the source is fine.
rsync with those flags bypasses the metadata layer entirely. It just copies the raw data, which is all you actually need.
Another angle: if the file has the immutable flag set (you'll see uchg when you run ls -lO), Finder can read it but can't copy it because the system treats it as locked. The chflags command removes that lock.
Less Common Variations
Sometimes -36 shows up in specific situations. Here's how to handle those:
External Drive with Existing Files
If rsync works but Finder still fails on the same drive, the drive's directory structure might be corrupted. Run First Aid in Disk Utility. That repairs the catalog and often clears the error.
Network Shares (SMB)
When copying to a Windows share or NAS, error -36 often comes from the SMB protocol version mismatch. Connect using smb:// instead of afp:// (Apple deprecated AFP anyway). In Finder, press Cmd+K and type smb://server/share. If it still fails, check the server's SMB settings — disable SMB1 if it's on, and enable SMB2 or SMB3.
Files from a Mac with Different Unicode Normalization
Rare, but if the file name has special characters (like é or ü) and the destination drive can't handle them, you'll see -36. Rename the file to something simple — no accents, no emoji — and try again. This happened to me with a file that had a Japanese character in the name, and it took me an hour to figure out.
External Drive with Spotlight Metadata
If the drive is formatted as HFS+ or APFS but still errors, Spotlight might be writing metadata that conflicts. Turn off Spotlight indexing for that drive:
mdutil -i off /Volumes/YourDrive
Then try the copy again. This is a temporary fix — you can turn indexing back on later with mdutil -i on.
Prevention
Best way to avoid error -36 is to stop using Finder for large transfers. Seriously. Finder is fine for moving a few files, but for anything big or when you're dealing with external drives, use rsync or ditto.
If you're copying to exFAT or FAT32 regularly, reformat the drive to APFS or exFAT with GUID partition map — but note that Windows won't read APFS unless you install a driver. exFAT is fine, but you'll always have this metadata issue. The real long-term fix is to use rsync with the --no-perms flags every time.
Also, keep your macOS updated. Error -36 was more common on older versions like Mojave and Catalina. Apple still hasn't fully fixed the metadata handling, but it's less frequent on Ventura and Sonoma.
Last tip: if you're in a hurry and just need that one file, copy it to a different destination first (like your Desktop), then move it. That bypasses the metadata issue because the Desktop is on the same filesystem. It's a hack, but it works when you're stuck in the office and the client is waiting.
Bottom line: error -36 is a metadata and permissions problem, not a hardware failure. Use rsync, clear attributes, and you'll be back to work in five minutes.
That's the long and short of it. If you're still stuck, check the console logs (log show --last 5m | grep -i error) for the specific I/O error — it'll point to the exact file or device. But in my experience, the fixes above solve 95% of -36 cases.