Error code -36 when copying a file on a Mac: what it means

Q: Why does the same file copy fine on Windows?

Because Windows does not create or care about . companion files, and it handles some file system quirks differently. A file copying successfully elsewhere is good news: it means the bytes are readable and the fault is in how macOS is reaching them.

23 August 2026 · 7 min read

A copy runs for a while, then the Finder stops and says: The Finder can’t complete the operation because some data in “filename” can’t be read or written. (Error code -36.) The copy is abandoned, and whatever arrived at the destination is incomplete.

Error -36 is ioErr, a read/write error inherited from very old versions of the Mac operating system. It means the Finder asked the disk for some bytes and did not get them. That is all it means. It does not tell you whether the fault is the source disk, the destination disk, the cable, the file system, or a stray hidden file, and those five have very different remedies.

Here is how to narrow it down quickly.

Rule out the easy cause first: dot-underscore files

If the copy involves a drive formatted FAT32 or exFAT, or a network share, this is the most likely cause and the quickest to fix.

macOS stores extended attributes for a file in a companion hidden file whose name is the original prefixed with ._. On a native Mac volume this is invisible plumbing. On FAT32, exFAT and many network shares, those companion files become real, separate files, and if one of them is malformed the Finder throws -36 while trying to copy the pair.

macOS ships a command specifically for this:

dot_clean /Volumes/YourDriveName

Run it against the folder or volume you are copying from, then try the copy again. It merges the ._ files back into the parent files where it can and removes the stragglers. There is no output when it succeeds, which is normal.

This one fix resolves a large share of -36 reports, and it is entirely safe to run.

Establish whether it is one file or the whole disk

If dot_clean did not help, the next question is scope, because it separates a damaged file from a failing disk.

Copy a different, unrelated file from the same source. If that succeeds, the problem is specific to one file. If several unrelated files also fail, suspect the disk or the connection.

To narrow further, ask the disk to read the problem file end to end without writing anything:

cp /path/to/problem.file /dev/null

/dev/null discards everything, so this is purely a read test. If it completes silently, the source can be read fine and the fault is at the destination. If it fails, the source is where the trouble is.

If the source is at fault

A file that cannot be read completely is either damaged in place or sitting on media that is failing.

Check the disk first, because there is no point recovering a file onto a drive that is dying. Open Disk Utility, select the volume, and run First Aid. Then look at the underlying drive health from Terminal:

diskutil info disk0 | grep -i smart

Substitute the right disk identifier, which diskutil list will show you. A SMART status of Verified means the drive is not reporting hardware failure. Failing means stop copying and get everything off it now, starting with whatever is irreplaceable.

If the disk is healthy but the file will not read, you have a damaged file. ditto is more informative than the Finder here, because it reports which byte range failed rather than a numeric code:

ditto --rsrc /path/to/source /path/to/destination

You can also ask rsync to keep going past errors and salvage what is readable, which is often the right call for a large video or archive:

rsync -avP --ignore-errors /path/to/source /path/to/destination

The result is a partial file. Whether a partial file is useful depends entirely on its type. A text file or a photo may be largely intact. A video usually is not, because the index that tells a player where each frame lives is written at the end of the recording, and a truncated file has lost it. Salvaging a half-copied video covers what can be done with the fragment.

If the destination is at fault

If the read test passed, the problem is where the file is going.

Check the destination format. Get Info on the drive and read the Format line. If it is NTFS, macOS mounts it read-only by default, and writes will fail in confusing ways. If it is FAT32, there is a hard four gigabyte limit per file, and a copy of anything larger will fail partway through no matter how healthy the disk is. That single fact explains a great many -36 reports involving video.

Check free space honestly, too. The Finder’s figure can lag, and a copy that runs out of room mid-flight reports a read/write error rather than a clear “disk full” message. When a Mac says the disk is full and Finder disagrees goes into why those two numbers differ.

If it is a network share

Network shares add their own failure modes. An SMB connection that drops for a second in the middle of a large copy produces -36, and the drive still looks mounted afterwards.

Copy to the local disk first, then to the share, rather than moving a large file across the network in one operation. If you must copy across the network, rsync is far more resilient than the Finder because it can resume:

rsync -avP --partial source /Volumes/Share/destination/

--partial keeps what has already transferred, so an interrupted copy resumes instead of starting over.

When the file itself is damaged

If you have established that the disk is healthy, the destination is fine, and one particular file still will not copy, you are dealing with a damaged file rather than a transfer problem. At that point the question changes from “how do I copy this” to “how much of this is recoverable”.

For video, audio, PDFs and Office documents, Manatee reads whatever structure survives in the file and writes a clean copy, always working from a duplicate so the original is untouched. It is honest about the outcome: if a video has lost its index it will rebuild one where the frame data is intact, and it will tell you how much it recovered rather than reporting success on a file that still will not play. What it cannot do is read bytes the disk will not return, which is why the disk health check above comes first. What can actually be recovered from a corrupted file sets realistic expectations before you start.

The order to work through

dot_clean /Volumes/Drive if FAT32, exFAT or a network share is involved.
Copy a different file to establish whether it is one file or many.
cp file /dev/null to test the source read in isolation.
Disk Utility First Aid, and check SMART status.
Check destination format for NTFS or the FAT32 four gigabyte limit.
rsync -avP --partial instead of the Finder for anything large or remote.
Treat it as file damage only once the first six are clear.

Questions

Does error -36 mean my drive is dying? Not by itself. It means one read or write failed. A dying drive usually produces repeated errors across many files, along with slow response and possibly audible noise. One file failing once, on an exFAT drive, is far more likely to be a dot-underscore file.

Why does the same file copy fine on Windows? Because Windows does not create or care about ._ companion files, and it handles some file system quirks differently. A file copying successfully elsewhere is good news: it means the bytes are readable and the fault is in how macOS is reaching them.

Is dot_clean safe to run on my main drive? It is safe, but it is pointless there. On a native APFS or HFS+ volume the extended attributes are stored properly and there are no stray ._ files to clean. Run it against external and network volumes only.

The copy fails at exactly the same percentage every time. That points to a specific unreadable region of the source, so a damaged file or a bad sector rather than a transient glitch. Run the cp file /dev/null test to confirm, then salvage with rsync --ignore-errors and accept a partial result.