The backup disk image could not be created

Short answer: on a network destination Time Machine does not copy files to the share. It creates one large disk image on the share and copies into that. Every error in this family is about the image: it cannot be made, cannot be opened, or something still holds it open.

None of them means your existing backups are gone. Erasing the drive is almost never the fix, and it is the advice you will find most often.

Why there is a disk image at all

Time Machine needs filesystem features that a network share does not offer: hard links, ownership it controls, and the ability to lock a file while it works on it. A NAS speaking SMB cannot promise those.

So on any network destination Time Machine makes a sparse bundle, a folder ending in .sparsebundle that behaves as a disk image. It mounts that image, and the backup lives inside it on a filesystem Time Machine controls completely. The share only has to hold a folder of numbered chunks called bands.

This is why a network backup has a whole category of failure that a plugged-in drive does not have. Two things can go wrong where a plugged-in drive has one, and the message you get is usually about the image.

The messages, and what each one means

“The backup disk image could not be created”

Time Machine tried to make the sparse bundle and the share refused. Work through these in order.

The share is not advertised for Time Machine. A NAS has a setting for this, usually a checkbox on the shared folder. On a Linux box running Samba it is fruit:time machine = yes in the share definition. Without it, macOS may connect happily and still refuse to create the image.
There is not enough room. The image is created at a declared maximum size. A share with a quota smaller than that maximum fails at creation. Check the quota on the share, and not the free space on the whole pool, which is a different number.
Permissions. The account you connected as needs write access to the share root itself. A folder inside it is not enough.
The name. The image is named after your Mac. A Mac name with a slash, a colon or an emoji in it has produced this exact failure. Rename it in System Settings, General, About, and try again.

“The backup disk image could not be accessed (error 45)”

The image exists and macOS could not attach it. Error 45 is a file lock error, so the usual cause is that something already holds the image open.

Unmount and remount the share. Eject it in Finder, wait, connect again. This clears the majority of them.
Check whether another Mac has it open. Two Macs backing up to the same share each get their own image, and a second Mac that mounted yours by accident holds the lock. Most NAS admin pages have a list of open files or connected sessions.
Restart the NAS. Crude, and it clears a lock held by a crashed process on the server side, which nothing on the Mac can release.
Clear the stale lock inside the bundle. A sparse bundle is a folder. Right-click it, Show Package Contents, and look for token or a .lock file at the top level. Deleting those is safe when nothing has the image mounted, and they are recreated on the next mount. Make sure the image is not mounted first, or you will corrupt it.

“is already in use” or “in use by another device”

Same cause, stated more plainly, and the same four steps clear it. Check for a mounted volume named after your Mac in Finder's sidebar before anything else, because the most common answer is that it is mounted right now on the machine you are sitting at.

“Time Machine could not complete the backup. The backup disk image is not accessible”

Usually the share went away mid-backup, from sleep, wifi, or the NAS rebooting for an update. Check whether the share reconnects, then check the image with the verify step below before trusting what is in it.

Check the image before you trust it

An interrupted network backup can leave the image internally inconsistent while every message on screen looks fine. Mount it and ask the system:

hdiutil attach -readonly /Volumes/<share>/<YourMac>.sparsebundle

diskutil verifyVolume /Volumes/<the volume it mounted>

Read-only, so nothing is changed by looking. If verification reports errors, run diskutil repairVolume on the same volume. If repair fails, that image is finished, and the honest move is to start a new backup chain on it and stop relying on what is in the old one.

What this costs you, said plainly

Every one of these errors is a property of the disk image, and the disk image exists because the destination is on the network. A backup that writes ordinary files into an ordinary folder has none of this: no image to fail to create, no lock to go stale, no single large object whose corruption takes every backup inside it at once.

That last point is the one worth sitting with. All of your Time Machine history on a NAS lives inside one sparse bundle. It is one object. Damage in the wrong place takes the lot.

How Copy Shelter treats a NAS

It writes a folder of ordinary files to the share, so there is no disk image, no locking, and no single object holding every version you have. A share that goes offline mid-backup is reported as a destination that is unreachable, with the date it was last seen, and the next backup carries on from where the last one stopped.

Every piece is stored under the hash of its own contents and read back against that hash on a schedule, so damage anywhere in the chain is named and located on an ordinary Tuesday. Backing a Mac up to a NAS covers the setup, including the timeout behavior that decides whether a sleeping share is an error or an absence.

Common questions

Can I delete the sparsebundle and start again?

You can, and it throws away every backup inside it, because they all live in that one image. Try the four steps above first. Deleting is the answer only when diskutil repairVolume has already failed on it.

Why does my USB drive never do this?

Because there is no disk image. A directly attached drive gets a real filesystem that Time Machine formats and controls, so it needs no image and has no lock to go stale. It is the single strongest argument for keeping one local copy.

The NAS says it supports Time Machine. Why does it still fail?

Supporting it and having it enabled on the specific share are different settings on most NAS software. Check the share, not the product page. Quotas are the other frequent one: the image declares a maximum size at creation and a smaller quota refuses it.

Is error 45 dangerous?

On its own, no. It means macOS could not get a lock on the image, so nothing was written. What is dangerous is a long run of them going unnoticed, because the last good backup keeps getting older while everything looks normal.

Does Copy Shelter use a disk image on a network share?

No. It writes ordinary files into a folder on the share, which is why none of the errors on this page exist for it. The trade is that the share has to be reachable to be counted, and the app says so when it is not.