In a standard multi-user setup, Guix and its daemon—the
guix-daemon program—are installed by the system
administrator; /gnu/store is owned by
guix-daemon runs as
root. Unprivileged users may use
Guix tools to build packages or otherwise access the store, and the
daemon will do it on their behalf, ensuring that the store is kept in a
consistent state, and allowing built packages to be shared among users.
guix-daemon runs as
root, you may not want package
build processes themselves to run as
root too, for obvious
security reasons. To avoid that, a special pool of build users
should be created for use by build processes started by the daemon.
These build users need not have a shell and a home directory: they will
just be used when the daemon drops
root privileges in build
processes. Having several such users allows the daemon to launch
distinct build processes under separate UIDs, which guarantees that they
do not interfere with each other—an essential feature since builds are
regarded as pure functions (see Introduction).
On a GNU/Linux system, a build user pool may be created like this (using
Bash syntax and the
# groupadd --system guixbuild # for i in $(seq -w 1 10); do useradd -g guixbuild -G guixbuild \ -d /var/empty -s $(which nologin) \ -c "Guix build user $i" --system \ guixbuilder$i; done
The number of build users determines how many build jobs may run in
parallel, as specified by the --max-jobs option
(see --max-jobs). To use
guix system vm and related commands, you may need to add the
build users to the
kvm group so they can access /dev/kvm,
-G guixbuild,kvm instead of
guix-daemon program may then be run as
root with the
# guix-daemon --build-users-group=guixbuild
This way, the daemon starts build processes in a chroot, under one of
guixbuilder users. On GNU/Linux, by default, the chroot
environment contains nothing but:
/dev directory, created mostly independently from the
/proc directory; it only shows the processes of the container
since a separate PID name space is used;
The chroot does not contain a /home directory, and the
environment variable is set to the non-existent
/homeless-shelter. This helps to highlight inappropriate uses of
HOME in the build scripts of packages.
All this usually enough to ensure details of the environment do not influence build processes. In some exceptional cases where more control is needed—typically over the date, kernel, or CPU—you can resort to a virtual build machine (see virtual build machines).
You can influence the directory where the daemon stores build trees
TMPDIR environment variable. However, the build tree
within the chroot is always called /tmp/guix-build-name.drv-0,
where name is the derivation name—e.g.,
This way, the value of
TMPDIR does not leak inside build
environments, which avoids discrepancies in cases where build processes
capture the name of their build tree.
The daemon also honors the
environment variables for HTTP and HTTPS downloads it performs, be it
for fixed-output derivations (see Derivations) or for substitutes
If you are installing Guix as an unprivileged user, it is still possible
guix-daemon provided you pass --disable-chroot.
However, build processes will not be isolated from one another, and not
from the rest of the system. Thus, build processes may interfere with
each other, and may access programs, libraries, and other files
available on the system—making it much harder to view them as
If your machine uses the systemd init system,
copying the prefix/lib/systemd/system/guix-daemon.service
file to /etc/systemd/system will ensure that
guix-daemon is automatically started. Similarly, if your
machine uses the Upstart init system, copy the
file to /etc/init.
“Mostly”, because while the set of files
that appear in the chroot’s
/dev is fixed, most of these files
can only be created if the host has them.