Nix errors have a bad reputation, and it is half deserved. They can be long, quote files you have never opened, and put the useful sentence somewhere near the end.

Treat the trace as a route. It says where evaluation started, which code it travelled through, and where it finally gave up. You are looking for two things: what broke, and the nearest line of your code.

The short version can be mercifully direct. Click the line that names what went wrong, not the punctuation pointing at it.

Do not begin by decoding every frame. Begin with the cause, then find the place that belongs to you.

A NixOS error travels through the module system before returning to your file. Store paths are usually the road. /etc/nixos and paths under your project are usually where you can act.

A flake source can also be copied under /nix/store/...-source, so do not throw away every store path blindly. Read the source name and look for the last frame you can map back to code you own.

NixOS often prints Definition values after the cause. The message sits above the list. The file you need sits inside it.

services.opensh should have been services.openssh. Precise option checking turns a typo into a loud failure instead of a silent, insecure surprise.

--show-trace removes the trace filter. It gives you more route, not a smarter diagnosis.

If the cause and your file are already visible, the filtered trace has done its job.

Once you have the sentence and the line, stop scrolling. Copy the failing shape into a tiny expression, replace unrelated values, and keep deleting while the same kind of failure remains.

A failure this size is one you can reason about, search for, or report. Your whole machine configuration is not a useful minimal example.

When Nix says an attribute is missing, inspect the set immediately to the left of the final dot.

For a.b.c, a failure at c means a.b exists but does not have the shape you assumed.

A type error is the most honest message Nix produces. It names the kind of value a function or option wanted, and the kind it got instead.

Find where the wrong value entered the function or option and fix it there. Do not patch some later expression merely because it makes the message move.

• Start with the cause after error:, then find the nearest source line you own.
• Dependency frames show the route. Project and /etc/nixos paths are destinations.
• Option errors put the message above Definition values and the file inside it.
• Use --show-trace only when the filtered trace never returns to your code.
• A missing attribute is a failed lookup. A type error means a value did not fit.
• Shrink the failure before you try to solve it.

Nix errors stay long. They stop being frightening once you know that most of the route was never asking you to edit it.