## TL;DR
Do not initialise anything and do not run repair first: prove you are pointing at the real repository, read its config with restic itself, and test the backend with the same identity the backup uses. Unable to open means restic could not read the repository config through that backend, usually a wrong path, a changed backend credential, or the wrong repository password. Opening the repository read only with snapshots is the success test.

```text
restic "Fatal: unable to open repository" backup failed
```

## Use this when
- Every restic backup, snapshots or check command fails immediately at repository open.
- The failure started after a move, a backend change, or a password file change.
- The same repository opens from another host or an older script.

## Not for this skill when
- restic opens the repository and check then reports pack errors. Use the restic check skill for that damage instead.
- A single snapshot is missing files but the repository opens normally. That is a snapshot problem, not an open failure.

## Steps
1. Confirm the repository location exactly as the job passes it, including the backend prefix for S3, SFTP or rclone repositories and any sub path inside a bucket. A missing sub path opens an empty location that has no config, which restic reports the same way. Verify: the stated location matches the working script or documentation character for character
2. Ask restic to read the repository with the least destructive command, snapshots, and capture the full error under it, because the wrapped backend error beneath the Fatal line names the real cause such as access denied, no such host, or wrong password. Verify: you have the underlying backend error, not only the Fatal summary
3. Test the backend outside restic with the same identity: list the repository folder or bucket prefix with the native tool for that storage, as the same operating system user or service account the backup runs as. Interactive success as an administrator does not prove the service identity works. Verify: the backup identity can list the config and keys folders or objects
4. Check the repository password source without printing it: confirm the password file path the job uses exists, is readable only by the backup identity, and is the file created for this repository rather than a rotated copy for another one. A single trailing change from an editor can make the key fail to decrypt. Verify: the password file timestamp and origin match this repository
5. Read the repository version from its config through restic cat config on a host that can open it, and confirm the restic version in the failing job supports that repository version. An older scheduled binary against a newer repository format refuses to open a healthy repository. Verify: the job binary version supports the repository version shown in config
6. Once open works, run snapshots and a check without the data reading option first, then schedule the deeper read. Do not run init against the existing location and do not copy a config from another repository over this one. Verify: snapshots lists restore points and the first check completes with no open errors

## Why it happens
A restic repository is identified by its config file and the keys that a password can decrypt. Opening means fetching that config through a backend, authenticating to the storage, and decrypting a key. A failure at any of those three steps collapses into the same Fatal message even though the stored backups may be untouched. Path drift after migrations, backend credential rotation, and password file mix ups between repositories are the usual causes, in that order. Compatibility: restic 0.14 to 0.17, local, SFTP, S3, Azure, GCS and rclone backends, repository versions 1 and 2.

## Variants and edge cases
### unable to open repository at S3 backend
For S3, check bucket region and the exact prefix, and test with the same profile the job uses. A bucket that answers in the wrong region or a prefix that was renamed produces the same Fatal line as a password problem.
### restic repository opens on one host only
Compare the binary version, the password file and the backend configuration between hosts without copying secret values into tickets. The difference is almost always one of those three.
### Fatal unable to open config file
That narrower variant points at the config object itself: permissions, an interrupted repository copy, or storage that returned an empty read. Restore the config from the storage side copy, not from another repository.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SCWAuWn3xamf0cUbKD-XVQ