Finder error -36, -43 and -50 on Mac: what they mean and how to fix them

By Ting Tze Chuen · Updated October 7, 2026

What do error codes -36, -43 and -50 actually mean?

These numbers are old Mac OS file system result codes that Finder still shows today. Apple's developer documentation lists them as ioErr (-36), fnfErr (-43) and paramErr (-50). The macOS SDK header that defines them, MacErrors.h, describes them as "I/O error", "File not found" and "error in user parameter list".

In plain English:

• Error -36: the Mac asked a drive to read or write data and the operation failed. Finder's message usually says some data "can't be read or written".
• Error -43: Finder went looking for an item it expected to find and it wasn't there. The message usually says "one or more required items can't be found".
• Error -50: the request Finder sent wasn't accepted, for example because the destination doesn't support a name, attribute or option involved. Finder usually calls it "an unexpected error".

None of the three names a single cause. They tell you which kind of thing went wrong, which tells you where to look first.

Quick reference: code, meaning, first thing to try

Why does error -36 happen when copying to an external drive or SD card?

Because error -36 is a raw read or write failure, the cause is usually physical or at the file system level:

• The connection. A worn USB cable, a cheap card reader, an unpowered hub or a long chain of adapters can drop data for a moment. The drive is fine, but that one transfer fails.
• The file system. Drives formatted as exFAT or FAT are easily damaged when they're unplugged without ejecting, which can leave files that can't be read cleanly.
• The media. A failing hard drive, a worn SD card or a counterfeit flash drive can have areas that can't be read or written.
• ._ AppleDouble files. Drives formatted as exFAT or FAT, and some network shares, can't store Mac metadata such as Finder tags and extended attributes directly. macOS saves that metadata in a hidden companion file named ._ plus the original file name. When those files are damaged or left behind without their partner, Finder can fail on them with -36 or -43.

To tell whether the source file itself is unreadable, read it in Terminal:

cat "/Volumes/CARD/DCIM/100CANON/IMG_0412.CR3" > /dev/null

If that prints Input/output error, the problem is on the source, not the destination. Copy everything else off that drive before doing anything else to it.

Why does error -43 say a file can't be found?

Error -43 means the path Finder was working with no longer pointed to anything. When copying, that usually happens because:

• the file was moved, renamed or deleted while the copy was running, often by a sync app, a camera app or another Finder window;
• the drive, card or network share disconnected briefly and came back;
• Finder's view of the folder is out of date, so it tries to copy an item that's already gone;
• an orphaned ._ file refers to a file that no longer exists.

Relaunching Finder and reconnecting the drive fixes most -43 errors. If it keeps happening with the same file, check the name for unusual characters, rename it, and try again.

Why does error -50 appear with a NAS or a drive formatted elsewhere?

Error -50 means the destination refused the request as invalid. It's commonly reported when copying to or from network shares (SMB) and drives formatted on another computer, where the destination doesn't accept something macOS is trying to write, such as a character in the name or a piece of Mac metadata. Drives that go to sleep mid-copy and flaky cables are also commonly reported triggers.

Start by renaming the file to plain letters, numbers and hyphens, reconnecting the share or drive, and running First Aid. If Finder still fails, copying with rsync or cp often works, because neither copies Mac extended attributes unless asked to.

How do I fix Finder copy errors, step by step?

Work through these in order. The early steps are quick and fix most cases; the last one erases the drive.

1. Relaunch Finder. Press Option-Command-Esc, select Finder and click Relaunch. Then eject the drive properly, unplug it and plug it back in.
2. Swap the hardware path. Use a different cable, a different port directly on the Mac (not a hub), and for SD cards a different reader. If the error disappears, you've found the culprit.
3. Clean up ._ files. Run dot_clean on the folder you're copying from (shown below). It merges the metadata back into the real files and removes the ._ files.
4. Run First Aid. Open Disk Utility, choose View > Show All Devices, and run First Aid on each volume, then the container, then the device itself, as described in Apple's guide to repairing a storage device.
5. Copy in smaller batches. Copy one folder at a time. When a batch fails, split it again until you find the file that triggers the error. Then you know exactly which file to deal with, and the rest is already copied.
6. Copy with Terminal instead. rsync, ditto and cp report the exact file and error, keep going past problems, and can skip Mac metadata (see below).
7. Back up and reformat. If First Aid finds errors it can't repair, Apple's advice is to erase the disk. Copy off everything you can, then erase and reformat it in Disk Utility. Use APFS for a drive only Macs will use, or exFAT if it also needs to work with Windows.

How do I use dot_clean to remove ._ files?

dot_clean is built into macOS. To merge and remove the ._ files in a folder and everything inside it:

dot_clean -v /Volumes/CARD/DCIM

To delete only orphaned ._ files, those whose matching file no longer exists, use -n:

dot_clean -n -v /Volumes/CARD

Drag the folder from Finder into the Terminal window to fill in its path. -v lists each file as it goes. Run man dot_clean for the other options.

Which Terminal commands can copy when Finder won't?

All three ship with macOS. Paths with spaces need quotes, and a trailing slash on an rsync source means "the contents of this folder".

rsync copies a folder, shows progress, keeps partly copied files, and here skips Finder metadata files:

rsync -avhP --exclude '._*' --exclude '.DS_Store' \
  /Volumes/CARD/DCIM/ /Volumes/Backup/Card-01/

If it stops partway, run the same command again. Files that already copied completely are skipped. On recent macOS, /usr/bin/rsync is openrsync, which supports all of these options.

ditto copies a folder; --norsrc leaves out resource forks and extended attributes, which avoids creating new ._ files on exFAT or network drives:

ditto -V --norsrc /Volumes/CARD/DCIM /Volumes/Backup/Card-01

cp is the simplest. -R copies folders, -X skips extended attributes, and -v lists each file:

cp -RXv /Volumes/CARD/DCIM /Volumes/Backup/Card-01/

When a file fails, each tool prints its path and an error such as Input/output error, so you know exactly what to retry or recover. You can also check a drive from Terminal with diskutil verifyVolume /Volumes/Backup.

Why can a copy that "succeeded" still be damaged?

Errors -36, -43 and -50 are the failures you can see. A drive that accepts data and stores it wrongly, or a connection that corrupts data in transit, produces no error code at all. Finder, cp, ditto and a normal rsync run all report success once the data has been handed to the drive. None of them read the copy back to compare it with the original.

That matters most when you've just seen errors. A cable or reader that threw -36 on one file may have quietly damaged others in the same batch. Once you've fixed the cause, check the copies: compare checksums with shasum -a 256, or run rsync -rcnv against the original, as described in how to verify a file copy on Mac.

VerifiedCopy does that check as part of every copy. It writes each chunk, flushes it to the drive, reads it back and compares its SHA-256 hash with the source. A chunk that doesn't match is rewritten and checked again (up to 3 attempts by default), so one bad block doesn't mean starting the whole copy over. To check a backup you made earlier, Verify & Repair compares it with the original and rewrites only the damaged chunks.