36

macOS Error Code 36: Fix the Finder ._ File Copy Failure

Error 36 hits when Finder copies files to NTFS or exFAT drives. Here's what causes it and how to fix each scenario.

The Real Culprit: ._ Files and Foreign Filesystems

What's actually happening here is Finder is failing to write metadata sidecar files. macOS stores extended attributes and resource forks in hidden files prefixed with ._. When you copy to a drive formatted as NTFS, exFAT, or FAT32, the filesystem can't hold that metadata natively, so macOS tries to create these companion files. If the drive is read-only, or the target directory won't allow the creation, you get error 36.

This most often appears when you drag a folder from a Mac-formatted drive (APFS or HFS+) to a USB stick or SD card that's exFAT. You'll see the error pop up partway through the copy, always on a file that has an extended attribute, like one downloaded from the internet or edited in Preview.

First Fix: Strip Extended Attributes Before Copying

The quickest workaround isn't to fight Finder — it's to remove the extra metadata before the copy. Open Terminal and run:

xattr -cr /path/to/source/folder

The -c flag clears all extended attributes, and -r recurses into subfolders. After that, Finder will copy without trying to create ._ files. This is safe for most files, but note that it strips things like quarantine flags and custom icons. If you're copying to a drive to share with Windows users, you don't want those anyway.

I've used this fix hundreds of times on macOS Big Sur and Monterey. It's the first thing I try because it's instant and requires no external tools.

Second Most Common: Destination Drive Is Read-Only

Sometimes the error isn't about ._ files at all. If the destination is NTFS-formatted, macOS can only read it by default. You can open files, but writing fails — and Finder reports that as error 36 because it can't create the sidecar or even the file itself.

The reason step 1 doesn't always work is the drive itself rejects any write. To verify, run in Terminal:

diskutil info /Volumes/DriveName | grep "Read-Only"

If it says Read-Only Medium: Yes, that's your problem. You have a few options:

  • Reformat the drive to exFAT (if you don't need the data on it). Use Disk Utility, choose Erase, format exFAT. That wipes everything, so back up first.
  • Install a third-party NTFS driver like Paragon or macOSFUSE with ntfs-3g. I've had good luck with Paragon on Monterey, but it costs money. ntfs-3g is free but requires disabling SIP on Apple Silicon Macs — a pain but doable.
  • Copy to a drive formatted as FAT32 or exFAT instead. If the drive is shared with Windows, exFAT is the sane choice because it handles files over 4GB, unlike FAT32.

What you shouldn't do is mess with mount -uw or try to force write to NTFS via the terminal — that's a recipe for filesystem corruption. I've seen it brick more than one USB stick.

Third Cause: Permissions on a Subfolder Inside the Destination

This one sneaks up on people because the root of the drive looks writable, but a specific subfolder has odd permissions — often because a previous Windows session marked it as read-only or the folder got created with no execute bit.

Finder sees the folder but can't create files inside it, so it throws error 36. The fix is to check permissions on the destination folder:

ls -lO /Volumes/DriveName/SomeFolder

Look for -rwxr-xr-x or similar. If the owner is wrong or the group has no write, you can fix it with:

chmod -R u+rwX /Volumes/DriveName/SomeFolder

The capital X only adds execute permission to directories, not files — that's what you want. This is a rare cause but happens more often than you'd think on exFAT drives that have been plugged into a Windows machine and back.

One More Thing: Check the Source File Itself

If the error only happens with a single file, not a folder, the source file might be corrupt or have an attribute that can't be transferred. Try copying it as a zip (right-click, Compress) and then moving the zip. If that works, the file is fine but has some metadata quirk. The zip bypasses Finder's metadata handling because it's just one file.

Quick-Reference Summary Table

CauseSymptomFix
._ file creation failsCopy fails on files with extended attributesxattr -cr on source
NTFS read-only destinationEvery copy fails to that driveUse exFAT or install NTFS driver
Subfolder permissionsOne specific folder failschmod -R u+rwX on that folder

If none of these help, the drive might be failing. Run First Aid in Disk Utility on the destination drive. A dying drive often returns error 36 because it can't reliably write any data. That's the last thing to check, but it's a real scenario — I've had a cheap USB hub cause this too, so try plugging directly into your Mac's port if you're using a hub.

Related Errors in macOS Errors
macOS Sonoma Wi-Fi drops after wake — real fix macOS 'Application Not Responding' Fix That Actually Works macOS Errors Showing in Google Search – Quick Fix Error -36 macOS Error -36 Fix: I/O Error When Copying Files

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.