macOS Error: "The Operation Can't Be Completed" Fixes

That vague "The operation can't be completed" message shows up when Finder tries to move, copy, or delete a file and hits a wall. The cause is usually one of three things: a stuck Finder process, a permissions mismatch, or a corrupted file system index. Which one you've got determines how deep you need to dig.

Here's the troubleshooting flow. Start with the 30-second fix. If that doesn't work, move to the 5-minute one. Only drop to the 15-minute fix if you're still stuck. Most people never get past the first two.

Fix 1: Force-Quit Finder (30 seconds)

This sounds too simple, but it clears a huge percentage of these errors. Finder is just an app, and like any app, it can hang on a file operation. When it does, it throws that generic error at you instead of doing what you asked.

Here's what's actually happening: Finder's internal file-operation queue gets jammed, usually by a network share that hasn't timed out or a disk that's spinning down. Quitting Finder empties that queue and resets the UI. Your files aren't touched.

1. Click the Apple menu (top-left) and choose Force Quit.
2. Select Finder from the list.
3. Click Relaunch.

Finder will disappear for a second and come back. Now try the file operation again. If it works, you're done. If not, read on.

If you're the type who likes the keyboard, press Option + Command + Esc instead of clicking through the menu. Same result.

Fix 2: Repair Permissions and Reset File Flags (5 minutes)

When relaunching Finder doesn't cut it, the problem is likely permissions. macOS uses POSIX permissions and Access Control Lists (ACLs) to decide who can read, write, or execute a file. If those are wrong — say, a file got created by a different user or a sync app messed up the ACLs — Finder will refuse to touch it and give you that error.

The quickest way to see if that's your issue is to open Terminal and inspect the file. This step requires a little terminal comfort, but it's not rocket science.

1. Open Terminal (Finder → Applications → Utilities → Terminal).
2. Type ls -leO followed by a space.
3. Drag the problematic file or folder into the Terminal window, then press Return.

You'll see output like this:

-rw-r--r--@ 1 you  staff  1234 Jan 1 12:00 file.txt

The @ after the permissions means there are extended attributes. The flags column (after the date) will show things like uchg (user immutable) or schg (system immutable). If you see uchg, that's your culprit. Someone (maybe you, maybe a script) locked the file so it can't be moved or deleted.

Unlock it with:

chflags nouchg file.txt

Then clear any extended attributes that might be interfering:

xattr -c file.txt

Now try the file operation again. If the file is on an external drive and you're still getting the error, you might also need to repair the disk's permissions using Disk Utility.

Disk Utility permission repair (for older macOS versions):

1. Open Disk Utility (Applications → Utilities).
2. Select the drive that holds the file.
3. Click First Aid and let it run.

On macOS Catalina and later, First Aid doesn't do a classic permission repair on the system volume, but it still checks the file system structure, which can fix the underlying issue. If the file is on an external drive, First Aid definitely checks its permissions.

Fix 3: Run fsck in Recovery Mode (15+ minutes)

If neither of the above fixed it, the file system itself might be corrupted. This is rarer but it happens — especially after a crash, a power loss, or a flaky external drive. The error you're seeing is Finder's way of saying "the file system isn't responding the way it should."

The fix here is to run fsck (file system consistency check) from Recovery Mode. This works on macOS Catalina through Sonoma. Here's the deal:

1. Shut down your Mac.
2. Turn it on and immediately hold Command + R until you see the Apple logo or a spinning globe.
3. When you get to the Recovery window, choose Disk Utility first — try First Aid on your startup disk. It's friendlier than raw fsck.
4. If First Aid reports errors it can't fix, close Disk Utility and go to Utilities → Terminal from the menu bar.

In the Terminal that opens, you need to find your disk identifier. Run:

diskutil list

Look for the disk that has your Macintosh HD. It'll be something like disk3. Then run:

fsck -fy /dev/disk3s1

Replace disk3s1 with your actual system volume identifier. The -f forces the check, -y answers "yes" to any repair prompts automatically. Let it run. It can take 10-20 minutes on a large drive.

When it finishes, you'll see a message like ** The volume /dev/disk3s1 was repaired successfully. Then type reboot and hit Return — or just pick Restart from the Apple menu.

Here's the thing about fsck: it's the last resort because it's slow and it can sometimes do more harm if you run it on a disk that's already borderline failing. Back up your important files before you go this route if you possibly can.

When None of This Works

If you've made it this far and the error persists, the file itself might be on a dying hard drive. Check the SMART status in Disk Utility (click the drive, look for SMART Status). If it says "Failing," that's not something any software fix will cure. Copy what you can and replace the drive.

Also, if the error only happens on a network drive, it's likely a server-side permissions issue. Try mounting the share with a different user or ask whoever administers the server.

One more quirk: some apps create files with names that are too long or contain characters Finder can't handle (like a colon on Windows-formatted drives). Renaming the file via Terminal with mv can get around that. If you see the error only on files with odd names, that's your lead.

No matter which fix worked for you, that error message is almost never about the file itself being broken. It's about the layers around it — Finder, permissions, or the file system — tripping over themselves. Now you know which layer was lying to you.