Symptoms & scope
- Nix reports permission denied connecting to the daemon socket.
- The daemon rejects a username before starting a build.
Relevant environment
Multi-user Nix with nix-daemon.socket and allowed-users admission control.
Recognizable messages (synthetic examples)
error: cannot connect to socket at '/nix/var/nix/daemon-socket/socket': Permission deniedInspect transport permissions separately from daemon trust privileges.
error: user 'example' is not allowed to connect to the Nix daemonThe daemon is reachable but its admission policy rejected the identity.
Possible causes
These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.
- Socket path traversal or socket permissions can prevent transport access.
- allowed-users can reject a connected user; trusted-users grants extra powers and is not the normal build permission switch.
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 socket path metadata; this does not contact or restart the daemon.
namei -l /nix/var/nix/daemon-socket/socketInterpret the result: Check traversal and final socket permissions for the actual user. A missing socket differs from a permission denial.
Check 2
Reads selected global policy lines; inspect included policy files if present.
rg -n 'allowed-users|trusted-users|include' /etc/nix/nix.confInterpret the result: An absent explicit allowed-users value may mean its documented default applies. trusted-users is broader store administration, not merely permission to build.
Check 3
Reads the system socket unit; no restart or connection attempt is requested.
systemctl status nix-daemon.socket --no-pagerInterpret the result: Inactive, absent and inaccessible sockets need different fixes. On non-systemd hosts use the installation's supervisor instead.
Evidence-guided next steps
Restore intended socket access
If socket permissions differ from the installed unit's intended policy, correct the declarative socket configuration or installation ownership and restore that socket through its supervisor. Reconnect after an intended group membership change.
Precautions: Do not make the entire /nix tree writable or modify store ownership recursively. Restarting a daemon during builds needs coordination.
Recovery / rollback: Restore prior socket settings and group membership; recreate the socket through the original manager configuration.
Did this solution help you?
Grant ordinary daemon admission
If the transport works but the intended user is excluded, add that user or appropriate group to the deliberately maintained allowed-users policy. Keep trusted-users limited to identities requiring its administrator-like powers.
Precautions: Trusted Nix users can affect the store in ways comparable to root. A socket refusal is not justification to grant that role.
Recovery / rollback: Restore the previous admission list and daemon configuration; newly created build outputs are not deleted by policy rollback.
Did this solution help you?
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.
- Nix manual — multi-user mode (project or distribution documentation)
- Nix manual — allowed-users and trusted-users (project or distribution documentation)