'Time Machine Couldn't Complete the Backup' Error? Here's What It Means

The notification slides in at the worst time: “Time Machine couldn’t complete the backup to ‘Backups’.” No code, no detail, just a problem you now have to debug. The exact error text matters because Time Machine actually has half a dozen different failure modes hiding behind that one message.

Here’s what each variant means and how to fix the real cause.

”An error occurred while creating the backup folder”

This is the most common variant. It almost always means a permissions or ownership issue on the backup destination.

Mount the drive (or network share) and check ownership:

ls -la /Volumes/Backups/

You’re looking for the Backups.backupdb folder or a .sparsebundle file. Both should be owned by your user account, not root or unknown.

If ownership is wrong:

sudo chown -R $(whoami):staff /Volumes/Backups/Backups.backupdb

For network backups, the fix is different. Mount the share with the right user, then re-add the destination in System Settings → General → Time Machine. The credentials Time Machine has cached may have rotated.

”The backup disk could not be found”

Two scenarios. If you’re using a USB drive, this is hardware: failed cable, dead port, or the drive itself is gone. Try a different cable, then a different port, then a different Mac. If the drive doesn’t show up in Disk Utility on any Mac, replace it.

For network backups, the share went offline or moved. Open Finder, hit Cmd+K, and try to mount the share manually using the same path Time Machine expects. If it mounts cleanly but Time Machine still can’t find it, the saved bookmark is stale:

1. System Settings → General → Time Machine
2. Click (i) next to the missing destination, then Forget Destination
3. Click + and re-add it

Your existing backup history transfers automatically as long as the underlying sparsebundle is intact.

”The backup volume is read only”

This one’s specific. Time Machine wrote a file to the destination and got a permission denied response. Three things cause it:

1. The drive’s locked. Some external SSDs ship with a hardware switch. Check the physical drive.
2. The volume mounted read-only. Run mount in Terminal and look for the backup volume. If it shows read-only, eject and remount. If it consistently mounts read-only, the file system has errors — run First Aid in Disk Utility.
3. APFS read-only snapshot. This happens after a botched volume conversion. Erase the volume (it’s a backup, you can recreate it) and start fresh.

There’s a faster waySweep does the cruft hunt in seconds. Free for macOS →

“The backup is too large for the backup volume”

Math is the problem. Time Machine wants 1.5–2× the size of your source data on the destination — that’s the long-standing rule. If your Mac has 800 GB of data and your backup drive is 1 TB, you’re at the edge.

Two paths:

1. Free up space on the backup. Time Machine thins old backups automatically when space runs out, but if the message is firing, the thinning isn’t keeping up. Force it via the menu bar: hold Option, click the Time Machine icon, and choose Verify Backups. Or thin manually with tmutil thinlocalsnapshots.
2. Reduce the source. Add exclusions for things you don’t need backed up. Caches, simulators, virtual machine files, downloads. Every excluded GB on the source means less needed on the destination.

To see what’s eating your source disk, open System Settings → General → Storage and check the breakdown. Anything over 50 GB labeled “Other” or “System Data” is worth investigating before it gets backed up.

”The backup disk image could not be created”

This message is exclusive to network backups. Time Machine couldn’t write the initial sparsebundle to the share. Causes:

• The share doesn’t have enough free space for the initial image (Time Machine reserves up to 80% of the destination on first creation).
• Permissions on the share root prevent file creation.
• The share doesn’t support extended attributes Time Machine needs.

Test by manually creating a file on the share from Finder. If you can’t, fix the share permissions first. If you can, create the sparsebundle yourself with hdiutil:

hdiutil create -size 1t -type SPARSEBUNDLE -fs HFS+J -volname "Time Machine" -nospotlight YourMac.sparsebundle

Then drop it on the share and point Time Machine at the share. It’ll find the existing bundle and use it.

”The backup was not performed because an error occurred while copying files”

This is Time Machine giving up partway through a copy. The failed file is logged. Find it:

log show --predicate 'subsystem == "com.apple.TimeMachine"' --last 2h --info | grep -i "copy.*fail\|cannot copy\|error.*copy"

You’ll usually see a path. Common offenders:

• A file with extended attributes that won’t sync (often macOS Mail attachments or old downloads)
• A file open and locked by another process
• A symlink pointing to a missing target
• A file with corrupted metadata (use xattr -c filename to clear extended attributes)

If the failing file is junk, exclude it or delete it. If it’s important, copy it elsewhere first, delete the original, restore it from the new location, then run the backup.

The “this backup is too large” math problem

Time Machine plans the size of every backup before starting. If your Mac has 600 GB of changes since the last backup (which happens after a major macOS upgrade or a Photos library rebuild), it’ll refuse to start until enough space is free.

The output of tmutil compare -s shows you exactly what changed. Pipe to head and you’ll see the biggest deltas first:

tmutil compare -s | head -50

If the answer is “the entire Photos library got rewritten,” that’s a known issue after Photos rebuilds its database. Just let the next backup run with enough free space — it’s a one-time cost.

Recurring failures: when to nuke and pave

If you fix one error and a different one shows up the next day, the underlying drive or share is dying. Time Machine will keep failing in different creative ways until you replace it.

Symptoms of a dying backup destination:

• First Aid passes one week, fails the next
• Sparsebundle verification times out
• Backups complete sometimes and fail sometimes with no pattern
• The drive disconnects mid-backup without you touching it

When you see two of those in a month, replace the drive. Keep the old one as cold storage until the new backup has 30 days of history.

Reclaim local snapshot spaceSweep finds APFS local snapshots Time Machine left behind. Get Sweep free →

Why a clean source matters

Most “backup failed” troubleshooting articles ignore this: a leaner source disk produces fewer backup errors, period. Less data means less time exposed to network drops, fewer files to permission-check, fewer extended attributes to copy.

The cleanup categories Time Machine never touches:

• System caches that regenerate constantly. They get backed up, then re-backed up the next hour after macOS rebuilds them.
• Old installers in Downloads. A 4 GB Xcode .xip from 2024 is just sitting there.
• App leftovers. Removing an app via drag-to-Trash leaves preferences, caches, and support files that Time Machine archives forever.
• Localizations. If you only use your Mac in English, you have hundreds of MB of French, German, Japanese, and Chinese language files in every app bundle.
• Browser data. Chrome caches alone can hit 5 GB. They’re regenerated on demand.

This is the gap Sweep fills. Time Machine is the time-versioned safety net. Sweep clears the noise so the safety net isn’t preserving 60 GB of cruft you don’t need restored.

When the error is just transient

Some errors fix themselves. If you see “Time Machine couldn’t complete the backup” once and the next backup runs cleanly, don’t go on a debugging crusade. Network blips, transient permission issues during macOS updates, and brief drive disconnects are normal.

The rule of thumb: one failure is a hiccup, two in a row is a pattern, three is a problem you need to fix. Open tmutil status and check Result — anything other than 0 means the last backup didn’t complete cleanly. If you see non-zero results in three consecutive checks, start working through this list.

A working baseline

A healthy Time Machine setup runs hourly without you noticing. Backups complete in 1–10 minutes for incremental changes. The destination drive shows up in Finder, Disk Utility reports it healthy, and tmutil status returns Result = 0.

If yours doesn’t match that picture, work backward through the symptoms here until you find the actual cause. Most of the time, it’s something boring — a permissions reset, a corrupt sparsebundle, or a drive that needs to be replaced. The error message is just the smoke; the fire is usually obvious once you know where to look.