Fix macOS Error -36: Operation Couldn't Be Completed

You're copying a folder from an SD card, a Time Machine backup, or a network share to your Mac. Finder chugs along, gets to 80%, then throws "The operation can't be completed because an unexpected error occurred (error code -36)." Or you're dragging a 2 GB video off an aging external drive and it dies at the same spot every time. It's a Finder error, and it almost always shows up on removable media, transfers over SMB/AFP, or when you're merging folders that came from an old Windows machine.

What's actually happening here is that Finder hit a low-level I/O failure while reading or writing one specific file — not the whole volume. Error -36 is the classic Mac OS equivalent of "ioErr," which means the input/output call itself failed. macOS wraps a lot of different under-the-hood problems in that one code: a bad block on a dying drive, a corrupt extended attribute, a resource fork pointing at data that doesn't exist, or a file with a name Finder can't handle. The reason Finder gives up on the whole operation instead of skipping the bad file is that Finder is a GUI wrapper around copyfile() and it bails the moment that call returns a non-zero status.

Skip Disk Utility First Aid as your first move. On most -36 errors, the filesystem is fine. The file is the problem. Diagnose the file, then decide whether the drive is also suspect.

Find the actual culprit file

Finder won't name it. Terminal will. Open Terminal and run a copy with rsync or cp pointed at the same source. rsync prints each file it fails on, and you'll get a filename in seconds instead of guessing.

rsync -avh --progress /Volumes/SDCARD/Photos /Users/you/Desktop/PhotosCopy 2>&1 | tee ~/rsync-errors.log

That tee writes everything to a log so you don't have to scroll. When rsync hits the bad file it prints the path and an error. That's your target.

Fix it — numbered steps

Strip the extended attributes and resource forks. This is the fix that works most often when the source came from Windows, an old drive, or a network share. Those ._filename companion files (AppleDouble) and stray xattrs are what Finder chokes on.
```
xattr -rc "/Volumes/SDCARD/Photos"
```
-r recurses, -c clears all extended attributes. Now retry the Finder copy.
Delete the AppleDouble files. On a FAT/exFAT volume these ._* files are everywhere. They're metadata stubs and Finder trips over them during merges.
```
dot_clean -m /Volumes/SDCARD/Photos
```
Run it on the destination too, not just the source. Both sides matter.
Check the filename. A colon :, a leading ., a non-breaking space copied from a web page, or a name over 255 bytes will trigger -36 on some filesystems. Rename anything suspicious to plain ASCII and try again.
Try a real copy tool instead of Finder. Finder is not a good file copier. It stops on the first error. rsync keeps going and tells you what broke.
```
rsync -avh --ignore-errors /Volumes/SDCARD/Photos /Users/you/Desktop/PhotosCopy
```
If rsync gets through everything, you never needed Finder to begin with. If rsync fails on one file, you know exactly which one to delete or skip.
Check the drive's health. If multiple different files throw -36, the drive is likely failing. Run:
```
diskutil verifyVolume /Volumes/SDCARD
```
and if you have smartmontools installed, smartctl -a disk4 (replace with your disk number from diskutil list). Reallocated sector counts above zero on a USB stick or SD card mean stop using it.
Mount the source read-only. Weird as it sounds, this bypasses some write-side metadata operations that trigger -36 on flaky media:
```
sudo mkdir /Volumes/readonly
sudo mount -t msdos -o ro /dev/disk4s1 /Volumes/readonly
```
Then copy from /Volumes/readonly. Works more often than it should.

If it still fails

Reboot into Safe Mode (hold Shift during boot on Intel, hold the power button on Apple Silicon). Third-party kernel extensions and file sync agents like Dropbox or Google Drive can hold file handles that cause -36 mid-copy.
Test from another Mac or a PC. If the same file fails everywhere, the file is toast. If it only fails on your Mac, you have a filesystem or extension problem on your end, not a bad source.
Run First Aid on the destination volume. Not the source. A destination with a bad B-tree will reject writes and report -36 as if the source were the problem.
Look at the console. Open Console.app, filter for kernel and disk, and retry the copy. Kernel-level I/O errors surface there with the actual sector number — that's the definitive answer on whether the hardware is dying.
Last resort for a single file: copy it with dd using a block size that skips the bad sector. Ugly, but it salvages the rest of a file that's mostly readable: dd if=bad.mp4 of=good.mp4 bs=4096 conv=noerror,sync.

One thing worth knowing: error -36 isn't a filesystem error code the way -50 (paramErr) or -43 (file not found) are. It's a catch-all. Treat it as a symptom, not a diagnosis. The file is bad, the drive is bad, or the metadata on the file is bad. Those are the only three options, and the steps above narrow it down.