tmutil: No destinations configured, and backupd error 17

Two errors, printed together, describing quite different things:

tmutil destinationinfo

tmutil: No destinations configured.
Failed to mount backup destination, error: Error Domain=com.apple.backupd.ErrorDomain
Code=17 "Failed to mount destination." UserInfo={NSLocalizedDescription=Failed to mount destination.}

The first line carries the information. The second is a false lead, and it is the one people paste into a search box, which is how a configuration state turns into an afternoon of disk diagnostics.

Read the first line first.

0

What each line actually means

No destinations configured is a plain statement of fact. Time Machine has no backup target registered. Not an unreachable target, not a corrupted one. None at all.

Code=17 "Failed to mount destination." reads like an attempt against a specific disk that went wrong. On this machine there was no disk to attempt. backupd emitted the mount failure anyway, because the code path that resolves a destination and mounts it runs regardless, finds nothing to work with, and reports the outcome in the only vocabulary it has.

17

So error 17 alongside zero destinations adds nothing to what the first line already told you. Error 17 with a destination configured is a genuine mount failure and worth chasing.

Which situation you are in

tmutil destinationinfo

With no destination you get the output above. With one configured you get a block per target:

====================================================
Name          : Backup
Kind          : Local
Mount Point   : /Volumes/Backup
ID            : 1B0C4D2E-...

A block means you have a destination and the mount error is real: check the disk is connected, awake, and not formatted as exFAT. No block means stop looking at disks entirely.

Adding a destination

For a directly attached disk:

ls /Volumes
sudo tmutil setdestination /Volumes/YourBackupDisk

The volume has to be APFS or Mac OS Extended (Journaled). Time Machine refuses exFAT and NTFS, and the error at that point is different and considerably clearer than error 17.

For a network target, System Settings, General, Time Machine is the better route. tmutil setdestination does accept an afp:// or smb:// URL, but handling credentials from the command line is more trouble than avoiding the settings pane saves.

Confirm afterwards by running tmutil destinationinfo again and checking a block appears.

What you may already have

No destination does not mean no recovery points. APFS local snapshots are taken on the internal disk on their own schedule:

tmutil listlocalsnapshots /

On the machine under test this printed a header and nothing under it, so there were none. If yours lists entries, each is a point-in-time state of the internal disk that individual files can be restored from, and they exist whether or not a destination is configured.

They are not a backup, and it matters not to treat them as one. They sit on the same disk as the data they describe, so they survive a mistaken deletion and do not survive a drive failure, a theft, or a dropped laptop. Local snapshots are why a deleted file can often be recovered with no backup disk attached, and they are not a substitute for having one.

The general lesson

When a macOS command prints several lines, the first tends to describe the state and the rest tend to be consequences of it. Searching the consequence rather than the state is how you end up reading about failing hardware when your actual problem is an empty configuration.

Here, one command settles it. If tmutil destinationinfo reports none, error 17 is noise.

Checking a destination that does exist

If destinationinfo printed a block, the mount error is worth taking seriously and there are four things to check before assuming the disk is at fault.

Confirm the volume is actually mounted:

ls /Volumes
diskutil list external

A disk that spins up but does not mount usually shows in diskutil list and not in /Volumes, which points at the filesystem rather than at Time Machine. A disk absent from both is a cable, a hub, or a power problem, and no amount of Time Machine configuration will help.

Check the format:

diskutil info /Volumes/YourBackupDisk | grep -iE "file system personality|read-only"

Time Machine writes only to APFS or Mac OS Extended (Journaled). A volume formatted exFAT for compatibility with a Windows machine will be rejected, and a volume mounted read-only, which happens after an unclean eject, will fail in a way that reads like a permissions problem.

Check whether the destination Time Machine remembers is the disk you think it is:

tmutil destinationinfo | grep -A1 "ID"

Destinations are recorded by identifier rather than by name. Reformatting a disk gives it a new identifier while leaving the old one registered, so Time Machine goes looking for a volume that no longer exists and reports a mount failure that is technically accurate. Removing the stale entry and adding the disk again resolves it:

sudo tmutil removedestination <ID>
sudo tmutil setdestination /Volumes/YourBackupDisk

And check whether a backup is simply already running:

tmutil currentphase
tmutil status | head -20

currentphase returns BackupNotRunning when idle. If it returns anything else, the destination is in use and a second startbackup will not do what you expect.

Watching a backup actually work

Once a destination is configured, the useful command is not the one in the menu bar:

tmutil status

This prints a live dictionary including the phase, the number of bytes and files copied, and the total the backup expects to move. During the first backup to a new disk the totals are large and the progress is slow, and Percent is frequently a poor guide because Time Machine revises its estimate as it goes.

To follow it without repeatedly running the command:

while sleep 10; do
  tmutil status | grep -E "BackupPhase|Percent|bytes"
  echo "---"
done

The phase names are undocumented and mostly self-describing: ThinningPreBackup, FindingChanges, Copying, ThinningPostBackup. A backup that sits in FindingChanges for a long time on a large disk is normal rather than stuck.

What happens when the destination is gone

The behaviour worth knowing about in advance: if the backup disk is disconnected for an extended period, macOS does not stop protecting the machine. It continues taking APFS local snapshots on the internal disk, and it retains them until either the disk fills or the destination returns and the snapshots are consolidated into a real backup.

That is why disconnecting a backup drive for a month can quietly consume tens of gigabytes of internal storage, and why the space reappears the moment you plug the drive back in. It looks like a storage bug and it is the system doing exactly what it should.

tmutil listlocalsnapshots /
df -h /System/Volumes/Data

If the second command shows far less free space than your files account for, and the first lists a long series of dated snapshots, connecting the backup disk is the fix rather than deleting anything.

Why tmutil is worth learning at all

Time Machine’s interface hides its state deliberately, and for most people that is the right trade. The command-line tool is worth knowing for the cases where the interface’s summary is not enough: when a backup appears stuck, when the disk is filling faster than it should, or when you want to know what actually exists rather than what the last run reported.

Four commands cover nearly all of it. destinationinfo for what is configured, status for what is happening now, listbackups for what exists on the destination, and listlocalsnapshots for what exists on the internal disk. None of them modifies anything, so all four are safe to run while a backup is in progress.

tmutil listbackups

That prints one path per completed backup on the current destination. A machine with a healthy history shows a dense series, thinning out as older backups are consolidated. A gap of weeks in the middle is a period when the disk was disconnected, and it is worth knowing about before you need to restore from it.