Dennis HilkLinux Fix LabDE

NixOS & Configuration

Nix rejects a store path's cache signature

A substitute or copied store path lacks a trusted signature. Verify the cache identity, public key and daemon configuration before changing trust rules.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • A path cannot be added because it lacks a signature by a trusted key.
  • A custom cache works on one machine but is rejected on another.

Relevant environment

Multi-user Nix, binary substituters and store transfers; signature policy depends on path addressing and trust settings.

Recognizable messages (synthetic examples)
error: cannot add path '/nix/store/00000000000000000000000000000000-example' because it lacks a signature by a trusted key

This is an integrity/trust rejection, not proof of cache compromise.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • A cache may be missing its intended public key or return a path signed by a different key.
  • Client settings can differ from the daemon's effective configuration; a store transfer has the same relevant trust boundary.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Read your declarative configuration tree; do not publish credential-bearing configuration files.

rg -n 'substituters|trusted-public-keys|require-sigs|trusted-users' /etc/nixos

Interpret the result: Match each intended cache to its independently verified signing key. trusted-users is broader privilege than a cache-key declaration.

Check 2

Reads selected global configuration lines; included files and daemon restart timing can matter.

rg -n 'substituters|trusted-public-keys|require-sigs|trusted-users|include' /etc/nix/nix.conf

Interpret the result: If declarative intent is absent here, the change may not be activated. The caller's settings are not proof of daemon acceptance.

Evidence-guided next steps

Declare the verified cache public key

If the cache is intended and its signing key is verified from the cache operator's official documentation, add that exact key to nix.settings.trusted-public-keys alongside the intended substituter. Apply the daemon configuration through NixOS.

Precautions: A trusted cache can supply executable system content. Do not disable require-sigs or mark every user trusted to bypass one rejection.

Recovery / rollback: Remove the added cache/key and restore the prior generation and daemon settings. Already installed paths are not removed by reversing trust.

Did this solution help you?

Share this solution#

Use a verified alternative source

If the cache identity or signature cannot be established, disable only that substituter and use a known intended cache or build from the pinned source. For owned store transfers, arrange signing using the administrator's documented key policy.

Precautions: Source builds can consume significant time and memory. Content-addressed objects have different verification semantics; inspect the exact path type.

Recovery / rollback: Restore the old substituter only after its key and signing issue is resolved; preserve the previous cache configuration.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.