## TL;DR
The chunk configurator is part of the storage's initialised state, and failing to load it means duplicacy cannot read how the storage was set up: the storage was never initialised from this client's view, its config in the storage root is missing or unreadable, or the client is pointing at the wrong storage URL. Verify the storage root contains its config, that the backup's credentials can read it, and that the repository's preferences name the same storage the job intends.

```text
Duplicacy backup failed "failed to load the chunk configurator" error
```

## Use this when
- The job or restore fails with this symptom: Duplicacy backup failed with failed to load the chunk configurator.
- You are working on a Duplicacy backup against an existing storage and the failure repeats on the same target or schedule.
- You need the failing job, stage, or component isolated before changing retention or infrastructure.

## Not for this skill when
- A storage whose config was encrypted with a different key than the client supplies, where the fix is the correct storage key.
- The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. List the storage root and confirm the configuration file duplicacy writes at initialisation is present. Verify: storage initialisation state is established
2. Check the job's storage URL and credentials against the storage the repository was initialised with. Verify: the target storage matches the repository's expectation
3. Test reading the config as the backup's user or service context, not an interactive one. Verify: config readability by the acting context is proven
4. Re-point the job at the correct storage or restore the config from the storage's backup copy, then run a small backup. Verify: the backup loads the configurator and proceeds

## Variant phrasings
### duplicacy failed to load the chunk configurator
The verbatim phrasing.
### duplicacy backup failed storage config missing fix
The config phrasing.
### duplicacy chunk configurator unreadable storage url wrong
The wrong-storage phrasing.

Compatibility: Duplicacy backups and storage configuration files

## Why it happens
Duplicacy keeps the storage's chunking and encryption parameters in a config stored on the storage itself, so a job can reach the storage and still be unable to begin if that one artefact is missing, unreadable, or encrypted for another key. The failure happens before any data file is touched.

## Edge cases / pitfalls
- Copying a storage without its root config is the classic way this state is manufactured; include the config in any storage migration checklist.
- A config encrypted under a lost key is unrecoverable by design; the storage must be re-initialised and re-seeded.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_u2QF8q6sm1dmqahWcoHZKQ