Talk:Nix

Alternative installation methods removed

User:grawlinson did a "major refactor" with [1] and part of the information hasn't been added back to the article. Specifically archlinux-nix^AUR, which uses upstream binaries, is no longer mentioned.

The manual installation was removed in a previous edit with [2]; however, pages like Rust still mention installation through curl (albeit with a notice to actually check what has been retrieved before executing it).

This already caused complaints on IRC because nix was reported as non-working, and other methods are now undocumented. -- Alad (talk) 12:20, 1 July 2021 (UTC)

Acknowledged. I'll revert my changes. Grawlinson (talk) 23:43, 1 July 2021 (UTC)

If the native way works, it should be the only one given on top. As with other packages, I would expect that in typical usage there is no reason not to use the native package. I assume I don't need to care about the alternative ways unless I have some specific, exceptional use case or I'm troubleshooting. Those alternative ways create a bunch of clutter, especially with the banners. Can't we put them under some other page, like Nix/Alternate_installation? Ujones (talk) 23:33, 27 July 2024 (UTC)

I think moving the external scripts to their own section/page is a good idea, though I think making it a little easier to tell what extra steps need to be done when using the native package would be a good idea too, such as expanding the Configuration section with info about flakes and mentioning nix-daemon.socket. Liassica (talk) 00:15, 28 July 2024 (UTC)

Some steps are missing from the "Configuration" section

I've installed the "nix" package and configured a channel, as described.

The absolute first thing the official tutorial has you do to confirm Nix works is to run "nix-shell -p hello", which explodes:

➜ nix-shell -p hello
error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)

       at «string»:1:25:

            1| {...}@args: with import <nixpkgs> args; (pkgs.runCommandCC or pkgs.runCommand) "shell" { buildInputs = [ (hello) ]; } ""
             |                         ^
(use '--show-trace' to show detailed location information)

I assume the official install script does some additional configuration that the Arch package doesn't, which should probably be described under the Configuration section.

I still haven't figured out *what* I'm missing (after hours of fumbling in extreme frustration) so I can't suggest an edit.

—This unsigned comment is by Hubro (talk) 15:24, 31 December 2022. Please sign your posts with ~~~~!

That is pretty easy to solve and must be on of those three things: - there is no channel named nixpkgs - nix-channel --update need to be run - NIX_PATH is missing an entry for nixpkgs or a default entry. It should look like ``nixpkgs=/nix/var/nix/profiles/per-user/$USER/channels/nixpkgs:/nix/var/nix/profiles/per-user/$USER/channels``

Sandro (talk) 22:19, 31 December 2022 (UTC)

I had the same issue, and found a possible solution while not changing too much the `nix` arch package. Opened an Arch issue, but not sure if that's the proper way though. --Gileri (talk) 21:03, 18 June 2023 (UTC)

nix-users

I'm missing something here about the group membership that is described: "Add required users to the nix-users group in order to access the daemon socket." In practice that doesn't seem to matter, the socket is only owned by root:

   srw-rw-rw- 1 root root 0 Jul 19 11:50 /nix/var/nix/daemon-socket/socket=

Can the article clarify as to whether the user should be able to run nix? -blee (talk) 18:58, 19 July 2023 (UTC)

Having just run through the process myself, I can say yes. The user should be able to run nix. However, installation isn't complete just because the package is installed. I'm often guilty of skipping ahead and troubleshooting my way backwards (I learn more that way, it seems). So I'll dump some notes here for others like me.

For the user to use nix, the daemon has to be running and the user has to be a member of `nix-users` (and obviously that change doesn't take effect until the next time the user logs in). The root user doesn't seem to depend on the daemon, but I haven't fully tested that.

Here's what I did: After a fresh install, I added myself to `nix-users` and opened a new terminal, immediately trying `nix-shell -p hello`, which failed with `error: creating directory '/nix/store': Permission denied`. Without realizing the daemon wasn't running (or even that it should have been), I ran `sudo nix-shell -p hello` to eliminate permission issues (I know, that could be sloppy). It failed differently with `error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)`. As a side-effect, it created the missing `/nix/store`, so I re-ran `nix-shell -p hello`, which resulted in a different `error: opening lock file '/nix/var/nix/db/big-lock': Permission denied`. This clued me off the the fact that a daemon probably needed to be running, the Configuration section says right at the start. After enabling and starting it, I re-ran `nix-shell -p hello`, which gave me the same error I got when running it as root. No worries, I just added the `nixpkgs-unstable` channel and updated it using the commands in the Configuration section of the wiki, then ran `nix-shell -p hello` successfully. The command downloaded several paths and opened a new shell where I could run `hello`.

I hope someone else finds my notes useful, but perhaps the installation steps for the official package could get its own section at the top of the page that describes all the steps most people would need to take? The troubleshooting section could also include each error that occurs as a result of skipping steps, and point to the exact step that might have been skipped. Section 6.4, for example, should suggest installing a `nixpkgs` channel and/or point to the skipped step rather than pointing people to a bug report and non-standard installation methods when the problem is probably as simple as the fact that there aren't any channels installed by default. Musselwhite.dev (talk) 15:15, 20 March 2025 (UTC)

On Debian, there is a package called nix-setup-systemd that provide some basic, yet not out-of-box configs of nix. This package provides a file /usr/lib/tmpfiles.d/nix-daemon.conf. It seems that it is this file that make the group of the nix daemon socket nix-users instead of root.

Type Path Mode User Group Age Argument

d /nix/var/nix/daemon-socket 770 root nix-users

e! /nix/var/nix/daemon-socket - - - 0

d /nix/var/nix/gcroots/per-user 1777

d /nix/var/nix/profiles/per-user 1777

Foobat (talk) Foobat (talk) 15:19, 8 April 2025 (UTC)

I'll admit, I'm a bit confused as to how you faced this issue on 20th March?

The group nix-users has not been created by the arch package since version 2.26.3-2 (change committed on 11th March). Maybe the package was updated in the repos later?

Either way, just installed nix on a new machine using the arch package, and it didn't seem to require the group and nix-env -iA nixpkgs.hello just worked?

Also, is there an advantage to enabling the nix-daemon systemd service so that it starts at boot rather than just enabling its systemd socket? AulonSal (talk) 03:14, 22 August 2025 (UTC)

nix-daemon for single user

Do you need to enable nix-daemon if you have a single user setup? Seems like it's for handling problem that come from multiple users, so if you're the only user it seems unnecessary. But I can't tell if the other instructions, like the nix-users group, wouldn't make sense without it. Ujones (talk) 23:38, 27 July 2024 (UTC)

Root doesn't seem to need the daemon running when it was installed from the arch package, which suggests that maybe a single user could use nix as long as the permissions on the `/nix` directory allow them to, but I haven't fully tested it. There is a single-user installation method on the NixOS website, so it is possible, I just don't know what all has to be done differently or what the best practices are. Musselwhite.dev (talk) 15:21, 20 March 2025 (UTC)

Somebody has got to know how this thing works. Single user with one regular and root user is probably the most common setup. You would think that would be the one documented first... Ujones (talk) 17:39, 8 September 2025 (UTC)