macOS 'The operation couldn’t be completed' fix that actually works
That vague error usually means a permissions or disk issue. Here's the one fix that kills it 90% of the time, plus when to dig deeper.
Yeah, that error sucks. You copy a file, delete something, or even just move a folder, and macOS throws up a message that says The operation couldn’t be completed with zero explanation. Happened to a client last week who was trying to empty their Trash after a failed backup — took me longer to find the issue than to fix it. Let's cut to the chase.
The fix that works 9 times out of 10
Open Terminal. Don't be scared — you're typing three commands, that's it.
- First, identify the file or folder that's causing the pain. Dragging it to Terminal drops its path in. Run this to reset ownership and permissions to the default (your user account):
sudo chown -R $(whoami):staff /path/to/offending/file
chmod -R 755 /path/to/offending/file
Replace /path/to/offending/file with the actual path. If you're not sure, just drag the file from Finder into the Terminal window — it auto-fills the path.
If that doesn't help, run Disk Utility's First Aid on your startup disk (usually named Macintosh HD).
- Open Disk Utility (Applications > Utilities), select your startup volume, and click First Aid > Run. Let it finish — it can take a few minutes.
That combination fixes the error in maybe 80% of real-world cases I've seen. The chown command resets the file owner to you, and chmod 755 gives proper read/write/execute permissions. Disk Utility catches any hidden file system corruption.
Why this works
The error almost always means macOS can't read or write to the file due to one of three things:
- Permissions got locked after a crash or interrupted file transfer
- The file system is slightly corrupted (bad sector, directory entry issue)
- The file was created under a different user account (like an admin vs standard user)
I've also seen it when Time Machine tries to restore files from a backup that was on a network drive — the permissions don't match, and macOS throws this generic error instead of telling you "hey, your backup was from a different Mac."
Less common variations
If the above didn't work, here are a few other triggers I've run into:
1. File name too long or contains weird characters
macOS tends to choke on files with colons or emoji in the name when you try to move them to an external drive (especially NTFS drives). Rename the file to something simple like test.txt and try again.
2. Disk UUID mismatch after cloning
If you cloned your startup disk to a new drive, the disk UUID might be duplicated. Run diskutil list in Terminal to check for duplicate entries. The fix is to use diskutil unmountDisk then remount.
3. SIP (System Integrity Protection) blocking changes
This is rare on recent macOS versions, but if you've disabled SIP for some reason, re-enable it. Boot into Recovery Mode and run csrutil enable in Terminal.
4. Hidden .DS_Store file corruption
Sometimes a corrupted .DS_Store file in a folder causes this error when you try to delete the folder. Use this command to clear it:
sudo find /path/to/folder -name ".DS_Store" -delete
How to stop it coming back
Prevention is pretty straightforward:
- Never force-eject an external drive without using the Finder's Eject button or
diskutil ejectin Terminal. That's how 90% of corrupted directory entries start. - Run Disk Utility's First Aid once a month — it's like a dental checkup for your drive.
- If you do a lot of file transfers over a network or between different Macs, make sure you're using the same user account name on both machines. Different UIDs cause permission chaos.
That's it. You don't have to reinstall macOS or wipe your drive. Next time this error pops up, paste those two commands, run First Aid, and move on. Your sanity will thank you.
Was this solution helpful?