Mac

Repair a Time Machine sparsebundle that won't mount

Fix a Time Machine network backup that says the sparsebundle is in use, couldn't be accessed, or is damaged — attach it with hdiutil, run fsck_apfs / First Aid, clear stale locks, re-claim it with tmutil, and know when to rebuild.

Problem summary

I'm here because Time Machine won't open the backup on my NAS — it says the sparsebundle is already in use, couldn't be accessed or created, or is damaged. A sparsebundle is the single disk-image file Time Machine writes over the network, and an interrupted write or a stale lock can leave it un-mountable. This page repairs it the supported way (mount with hdiutil, run a filesystem check), clears the locks that fake a 'in use' error, and is honest about when a network sparsebundle is better rebuilt than rescued.

Operator snapshotEvidence first

First proof

Run `sudo tmutil disable`, then mount the NAS share.

Screen to open

sudo tmutil disable

Expected signal

Backups are paused and the share is reachable, so you can work on the image.

Stop boundary

Never remove a lock while a Mac is actively backing up.

Layer path

1A network Time Machine backup is one file: a .sparsebundle disk image sitting in an SMB share. To Time Machine it's a mountable volume; to repair it you treat it like any disk — attach it, run a filesystem check, detach. The error messages ('in use', 'couldn't be accessed', 'damaged') map to distinct states: a stale lock, an un-mountable image, or filesystem inconsistency inside it.

2The safe sequence is fixed: pause Time Machine so it isn't fighting you, clear a stale lock if and only if no Mac is backing up, attach with hdiutil without mounting, fsck the inner volume, then detach and re-enable. Skipping the pause or removing a live lock is how people turn a recoverable image into a dead one.

3Network sparsebundles corrupt silently and are the copy most likely to fail, so two judgments frame everything: rebuild beats heroic repair once fsck can't fix it, and no repaired or rebuilt backup is trustworthy until a real test restore succeeds. A single network backup should never be the only copy of irreplaceable data.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

Pause and mount

Check: `the "Pause Time Machine before repair" command below`; mount the NAS share.

Expected result: You can work on the image without Time Machine interfering.

If not: If the share won't mount, fix networking first.

Clear a stale lock

Check: Remove the lock inside the bundle only if nothing is backing up.

Expected result: The false 'in use' error clears.

If not: Never touch a live lock.

Attach and check

Check: `hdiutil attach -nomount`, then `fsck_apfs -y` on the inner volume.

Expected result: A repairable image is fixed and mounts.

If not: Won't attach / can't repair → rebuild.

Re-enable and re-claim

Check: `hdiutil detach`, `sudo tmutil enable`, `tmutil inheritbackup` if moved.

Expected result: Time Machine resumes the existing history.

If not: If inherit errors, re-add the destination.

Prove it restores

Check: After a backup completes, restore one real file.

Expected result: The backup is confirmed trustworthy.

If not: If restore fails, rebuild and add a second independent copy.

Decision tree

If: Error says 'backup already in use' / 'in use by another computer'.

Then: Stale lock from a crashed backup (if nothing is currently writing).

Action: Remove the stale lock inside the .sparsebundle, then retry.

Safe stop: Never remove a lock while a Mac is actively backing up.

If: `hdiutil attach` succeeds and fsck repairs the volume.

Then: Recoverable filesystem inconsistency from an interrupted write.

Action: Detach, `tmutil enable`, `tmutil inheritbackup` if moved; resume history.

If: `hdiutil` can't attach, or fsck can't repair.

Then: Badly damaged image — not worth heroic recovery.

Action: Delete the sparsebundle and let Time Machine rebuild; lose history, gain a working backup.

If: Image moved/renamed on the NAS and Time Machine won't resume it.

Then: Time Machine no longer recognises the image identity.

Action: `sudo tmutil inheritbackup <sparsebundle>` to re-associate it.

If: Even fresh sparsebundles keep corrupting.

Then: Underlying NAS volume health or network path is the real fault.

Action: Fix the NAS volume/network before trusting any network backup.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
'Backup is already in use.'	A stale lock inside the bundle; no Mac is backing up.	Stale lock from a crash.	Remove the lock (only if nothing is writing); retry.
'The backup disk image couldn't be accessed.'	`hdiutil attach` works; `fsck_apfs` finds errors.	Filesystem inconsistency inside the image.	fsck the inner volume, then re-enable and resume.
Image won't attach at all.	`hdiutil attach` errors on the header.	Severe header damage.	Rebuild — delete and let Time Machine recreate.
History lost after a NAS move.	Image present but Time Machine starts a new full backup.	Lost image association.	`tmutil inheritbackup` to resume the existing history.
Repeated corruption across backups.	NAS volume degraded/near-full or flaky network.	Storage/network underneath the image.	Repair the NAS volume/network first.

Reference

Commands and settings paths

Pause Time Machine before repair

sudo tmutil disable

Where: Terminal on the Mac.

Expected: Automatic backups stop, so they don't grab the image mid-repair.

Failure means: If backups keep starting, they'll fight the repair.

Safe next step: Re-enable with `sudo tmutil enable` when finished.

Attach the image without mounting

hdiutil attach -nomount -readwrite -noverify /Volumes/<share>/<Machine>.sparsebundle

Where: Terminal on the Mac, after mounting the NAS share.

Expected: Attaches the backing /dev/diskN for a filesystem check.

Failure means: If it won't attach, the header is badly damaged — rebuild.

Safe next step: Find the inner volume with `diskutil list` and run fsck.

Repair the inner filesystem

sudo fsck_apfs -y /dev/diskNsM

Where: Terminal on the Mac (HFS+ bundles: `sudo fsck_hfs -fy`).

Expected: Repairs the image's volume so it mounts and Time Machine resumes.

Failure means: If it loops or reports unrepairable, stop and rebuild.

Safe next step: Detach with `hdiutil detach` and re-enable Time Machine.

Re-claim an image after a NAS move

sudo tmutil inheritbackup /Volumes/<share>/<Machine>.sparsebundle

Where: Terminal on the Mac.

Expected: Time Machine adopts the existing image and resumes its history.

Failure means: An error means the image identity no longer matches this Mac.

Safe next step: Re-add the destination or accept a fresh first backup.

Hardware boundary

Hardware and platform boundary

Change only when

Add a second, independent backup (external SSD via Time Machine, or a cloud backup) so a corrupt network sparsebundle is never your only copy.
Move the Time Machine share to a NAS with snapshot support so a bad sparsebundle can be rolled back instead of rebuilt from zero.

Evidence that matters

A healthy NAS volume (not failing, not near-full) so the image isn't corrupted as it's written.
A second independent backup target so repair is low-stakes.
Snapshot support on the backup share for rollback.

Evidence that does not matter

Raw NAS throughput — incremental backups are small; it won't prevent corruption.
RAID level as 'backup insurance' — RAID is uptime, not backup integrity.
Repairing in place when a quick rebuild plus a test restore is safer.

Avoid

Removing a lock or editing the image while another Mac might be backing up.
Hand-editing band files / Info.plist to 'fix' the bundle.
Trusting a repaired or rebuilt backup without a real test restore.

Related tool/checklist

Use the linked tool when you need a guided plan from your exact symptoms instead of a static checklist.

Backup plan builder

Last reviewed

2026-06-02 · Reviewed by HomeTechOps. Reviewed against Apple's Time Machine backup and restore guidance; gives the safe repair sequence (disable → clear stale lock → hdiutil attach → fsck_apfs → detach/enable/inheritbackup) for a network sparsebundle, and is explicit that rebuild beats heroic repair once fsck fails and that no backup is trusted until a real test restore succeeds.

Sources/assumptions

Assumes a network Time Machine backup stored as a .sparsebundle on a NAS over SMB (including macOS Tahoe / macOS 26); local-disk Time Machine repair differs slightly.
Commands (`tmutil`, `hdiutil`, `fsck_apfs`, `diskutil`) follow Apple's documented behaviour and need an admin password; device identifiers vary per machine.
A network sparsebundle can corrupt silently, so an untested backup is not a trusted one regardless of repair outcome.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

Apple Support: Back up your Mac with Time MachineUsed for the supported Time Machine setup, choosing a backup disk, and that macOS backs up over SMB to a network disk (the sparsebundle model) on modern macOS.Apple Support: Restore your Mac from a backupUsed for the supported restore path (Migration Assistant / macOS Recovery) when a Time Machine backup must be brought back to a new or erased Mac.Tao of Mac: Fixing Time Machine / SMB after macOS 26 (nsmb.conf)Used for the macOS Tahoe SMB-signing change that breaks NAS Time Machine, and the /etc/nsmb.conf workaround, plus the Samba 4.21–4.22.3-broken / 4.22.6+ / 4.23-fixed version map on the NAS side.

Diagnostic rule

1. Check the simplest signal first.
2. Change one thing at a time.
3. Avoid unsafe electrical or data-loss steps.
4. Stop when the evidence says the risk moved.

FAQ

How do I repair a Time Machine sparsebundle that won't mount?

Pause Time Machine (`sudo tmutil disable`), mount the NAS share, then attach the image without mounting: `hdiutil attach -nomount -readwrite -noverify /Volumes/<share>/<Machine>.sparsebundle`. Find the volume with `diskutil list` and run `sudo fsck_apfs -y /dev/diskNsM` (or First Aid in Disk Utility). Detach, `sudo tmutil enable`, and test-restore a file. If it won't attach or repair, rebuild it.

Why does Time Machine say the backup is 'already in use'?

A crashed backup can leave a stale lock inside the sparsebundle, so Time Machine thinks another Mac is still using it. If you're certain no Mac is currently backing up to that image, remove the stale lock file inside the .sparsebundle and try again. Never remove a lock while a backup is genuinely running — that can corrupt the image.

Should I repair or just delete and rebuild the sparsebundle?

Repair if `hdiutil` attaches it and `fsck_apfs` fixes the volume — you keep your history. Rebuild (delete it and let Time Machine make a new one) if it won't attach, fsck can't repair it, or you'd otherwise be trusting a half-fixed image. Rebuilding loses history but is faster and safer, which is exactly why a single network backup shouldn't be your only copy.

How do I keep my backup history after moving the NAS?

Use `sudo tmutil inheritbackup /Volumes/<share>/<Machine>.sparsebundle` after the move or rename — it re-associates the existing image with this Mac so Time Machine resumes the history instead of starting a fresh full backup. If it errors, the image identity no longer matches and you'll re-add the destination.