macOS 'The operation can’t be completed' error fix
This pops up when deleting, copying, or moving files. Usually a permissions or metadata lockup. Here's how to force through it.
You're trying to delete a file or folder, or maybe copy it to another drive, and Finder throws up a dialog: "The operation can’t be completed because an unexpected error occurred (error code -36)" or just a generic "The operation can’t be completed." No further explanation. I've seen this most often on Big Sur and Monterey, but it pops up on any recent macOS version. The usual trigger: a file with a special character in the name (like a colon or slash), a corrupted .DS_Store, or a permissions mismatch after restoring from a Time Machine backup.
Why this happens
Under the hood, macOS's file system (APFS or HFS+) keeps metadata and permissions separate from the file's content. When something goes corrupt—like a folder's ACL list gets out of sync, or a file's extended attributes are borked—Finder can't perform the operation. The error code usually points to a ioctl failure or a permissions check that bombs out. Terminal bypasses Finder's metadata layer, which is why the command-line fixes work.
The fix (in order, don't skip)
1. Check if the file is locked in Finder
Right-click the file → Get Info. Look at the General section. If Locked is checked, uncheck it. Also check Sharing & Permissions at the bottom—your user must have Read & Write access. Change it if not, then try again.
2. Use Terminal to force-delete
Open Terminal (Applications → Utilities). Drag the problematic file or folder into the Terminal window. This inserts the full path. Then run:
sudo rm -rf /path/to/the/fileType your admin password when prompted. Warning: this deletes permanently, no Trash. Be absolutely sure you don't need the file. If that fails with "Operation not permitted", you've got a deeper permissions problem—skip to step 4.
3. Remove extended attributes
Sometimes a file's extended attributes (like com.apple.quarantine or com.apple.metadata:kMDItemWhereFroms) cause Finder to choke. In Terminal:
xattr -c /path/to/the/fileThen try the delete again. If the file is in a folder with many items, clear attributes on the whole folder:
xattr -cr /path/to/the/folder4. Reset permissions and ACLs
This is my go-to when the above fails. Use Disk Utility → select your boot drive → First Aid → Run. That repairs the volume's structure. After it finishes, reboot. Then in Terminal, reset ACLs on the parent folder:
chmod -RN /path/to/parent/folderThat removes all ACLs (Access Control Lists) from that folder and its contents. Then give your user ownership:
sudo chown -R $(whoami) /path/to/parent/folderNow you should be able to delete the file normally in Finder.
5. Last resort: Safe Mode and kill Finder
Boot into Safe Mode (hold Shift during startup on Intel Macs; on Apple Silicon, shut down, hold power button until options appear, then hold Shift on the boot volume). Safe Mode forces a directory check and clears some caches. Once in Safe Mode, open Terminal and run:
killall FinderThen try deleting the file. Works roughly half the time for stubborn cases.
What to check if it still fails
If none of these work, the file's inode is probably corrupted. You'll need to boot from macOS Recovery (Cmd+R on Intel, or hold power button for Apple Silicon). Open Disk Utility from the recovery menu and run First Aid on your drive. If that passes, mount the drive and use Terminal from Recovery to delete the file:
cd /Volumes/YourDriveName
sudo rm -rf path/to/fileIf even that fails, the drive itself may be failing. Run smartctl (via Homebrew on a working macOS) to check SMART status, or use Disk Utility's Info on the drive to see if it reports any errors. In 14 years, I've seen this exact error be the first sign of a dying hard drive maybe twice. Don't panic, but do a backup if you haven't recently.
Was this solution helpful?