Skip to content

Time Machine "Unknown Error": Case-Sensitive APFS Destination (and Encrypting It Correctly)

Overview

Time Machine will refuse a backup destination whose volume is formatted Case-sensitive APFS, but it reports only the generic dialog "Time Machine couldn't complete the backup to '\<disk>' — An unknown error occurred." Nothing in the UI names the filesystem format, so this is easy to misdiagnose (and re-diagnose) for months.

The only fix is to reformat the destination as Case-insensitive APFS (or HFS+), which erases it. If your Mac's startup disk is FileVault-encrypted, you'll then be prompted to encrypt the backup too — and the obvious GUI path to do that silently reformats the volume back to case-sensitive, undoing the fix. This article covers the whole correct sequence, plus the ownership/mount gotcha that blocks re-registering an encrypted destination.

[!warning] The disk gets erased Reformatting the destination destroys whatever is on it. If Time Machine was failing, the existing contents were never a valid backup chain anyway — but confirm you have no other data on that drive first.

Symptoms

  • "Time Machine couldn't complete the backup to '\<disk>' — An unknown error occurred."
  • Backups never complete; tmutil status may reach Copying briefly but the job never finishes, or fails immediately.
  • The destination is mounted, writable, and has plenty of free space (not full, not disconnected).
  • Orphaned local snapshots pile up on the source disk (tmutil listlocalsnapshots /) because they can never transfer.

Diagnosis — check the volume's case sensitivity first

This is the fast disqualifier. Run it before anything else:

diskutil info "<VolumeName>" | grep -i "Personality"

File System Personality:   Case-sensitive APFS      # ← unsupported by Time Machine

A healthy destination reads File System Personality: APFS (case-insensitive) or an HFS+ personality. If you see Case-sensitive APFS, that is the root cause — no amount of snapshot cleanup or "remove and re-add destination" will help until it's reformatted.

Fix Part 1 — reformat case-insensitive

Identify the physical disk, not the synthesized APFS container. diskutil list shows the container as (synthesized) with a Physical Store pointer — erase the physical device so you get a clean container:

diskutil list                       # find the physical (external, physical) disk, e.g. /dev/diskN

[!note] Device numbers move After every force-unmount or erase, macOS re-synthesizes the APFS container and the diskN numbers change. Re-run diskutil list between steps rather than trusting a number you saw earlier.

Remove the old destination, force-unmount (this evicts Spotlight, which otherwise blocks the erase), then erase the physical disk as plain APFS (which is case-insensitive):

sudo tmutil removedestination <old-destination-id>     # id from: tmutil destinationinfo
sudo diskutil unmountDisk force /dev/diskN             # physical disk
diskutil eraseDisk APFS "TimeMachine" /dev/diskN       # "APFS" = case-INsensitive

[!tip] Two harmless-looking errors - eraseDisk failing with -69877 … in use by mds_stores means Spotlight has the volume open — the forced unmountDisk above prevents it. (Alternatively: sudo mdutil -i off "/Volumes/<VolumeName>".) - -69842 "Couldn't mount disk … after erase" is usually cosmetic on external USB drives — the volume mounts anyway. Verify with diskutil info before assuming failure.

If you don't need encryption, register the destination and start:

sudo tmutil setdestination -a "/Volumes/TimeMachine"
tmutil startbackup --auto

Fix Part 2 — encrypt the destination (source is FileVault-on)

If your startup disk is FileVault-encrypted, macOS warns you're "backing up encrypted data to a non-encrypted drive." A portable backup drive absolutely should be encrypted — but do it in the right order.

[!danger] Do NOT use System Settings → Time Machine → "Encrypt Backups" to encrypt the disk That flow erases and recreates the volume as Case-sensitive APFS — straight back to the original root cause (you end up encrypted and broken). The GUI gives you no control over case sensitivity.

Instead, format case-insensitive first (Part 1), then encrypt in place via CLI on the empty volume (near-instant):

diskutil apfs encryptVolume "/Volumes/TimeMachine" -user disk
# prompts for a passphrase — set a strong one and store it in your password manager

The 49229 gotcha after CLI encryption

After encryptVolume, the volume typically ends up unmounted with Owners: Disabled. Time Machine requires ownership enabled and a valid mount path, so tmutil setdestination fails with:

OSStatus error 49229   /   POSIXError Code=22 "Invalid argument"

That is not a bad-disk error — it means the destination was rejected. Unlock/mount the encrypted volume, enable ownership, then register it:

diskutil apfs unlockVolume diskNsM                    # unlock + mount (prompts passphrase)
sudo diskutil enableOwnership "/Volumes/TimeMachine"  # TM requires ownership enabled
sudo tmutil setdestination -a "/Volumes/TimeMachine"
tmutil startbackup --auto

Verify

diskutil info "TimeMachine" | grep -iE "Personality|FileVault|Owners|Mounted"
tmutil destinationinfo
tmutil status | grep -iE "BackupPhase|Running"

You want: Personality: APFS (case-insensitive), FileVault: Yes, Owners: Enabled, a single registered destination, and Running = 1. A first full backup reports BackupPhase = Starting (with Percent = -1) while it enumerates files, then flips to Copying.

Notes

  • Escrow the passphrase yourself. macOS keeps a copy in the system keychain so the drive auto-unlocks for unattended backups, but keep your own copy in a password manager — it's the only way to read the backup if the keychain is ever lost.
  • Across a reboot an encrypted external may need one manual unlock before backups resume; check "Remember password in my keychain" when prompted to make it automatic thereafter.
  • This is distinct from the orphaned .previous folder failure, which produces the same generic dialog but is fixed with First Aid (fsck_apfs) rather than a reformat. If diskutil info shows the destination is already case-insensitive, check that article next.