GNU bug report logs - #77900
Unprivileged guix-daemon fails to build in Docker/relocatable pack

Previous Next

Package: guix;

Reported by: Ludovic Courtès <ludovic.courtes <at> inria.fr>

Date: Fri, 18 Apr 2025 14:25:11 UTC

Severity: normal

To reply to this bug, email your comments to 77900 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#77900; Package guix. (Fri, 18 Apr 2025 14:25:15 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ludovic Courtès <ludovic.courtes <at> inria.fr>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Fri, 18 Apr 2025 14:25:15 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludovic.courtes <at> inria.fr>
To: bug-guix <at> gnu.org
Subject: Unprivileged guix-daemon fails to build in Docker/relocatable pack
Date: Fri, 18 Apr 2025 16:23:42 +0200
When running guix-daemon unprivileged in Docker (or, similarly, in a
‘guix pack -R’ relocatable pack), it fails to spawn the build process:

--8<---------------cut here---------------start------------->8---
ludo <at> fencepost:~/packs/guix$ GUIX_STATE_DIRECTORY=$HOME/var GUIX_LOG_DIRECTORY=$HOME/var/log ./bin/guix-daemon 
^Z
[1]+  Stopped                 GUIX_STATE_DIRECTORY=$HOME/var GUIX_LOG_DIRECTORY=$HOME/var/log ./bin/guix-daemon
ludo <at> fencepost:~/packs/guix$ bg
[1]+ GUIX_STATE_DIRECTORY=$HOME/var GUIX_LOG_DIRECTORY=$HOME/var/log ./bin/guix-daemon &
ludo <at> fencepost:~/packs/guix$ GUIX_DAEMON_SOCKET=$HOME/var/daemon-socket/socket ./bin/guix build guile-bootstrap  --no-substitutes
accepted connection from pid 19182, user ludo
The following derivation will be built:
  /gnu/store/d9gcqaq0mag354svxsdpkvr8swdqsny8-guile-bootstrap-2.0.drv
guix build: error: cannot create process in unprivileged user namespace: Operation not permitted
--8<---------------cut here---------------end--------------->8---

The clone(2) man page lists two reasons for getting EPERM with
CLONE_NEWUSER:

   EPERM  CLONE_NEWUSER was specified in the flags mask,  but  either  the
          effective  user  ID or the effective group ID of the caller does
          not have a mapping  in  the  parent  namespace  (see  user_name‐
          spaces(7)).

   EPERM (since Linux 3.9)
          CLONE_NEWUSER  was specified in the flags mask and the caller is
          in a chroot environment (i.e., the caller's root directory  does
          not  match the root directory of the mount namespace in which it
          resides).

Ludo’.




This bug report was last modified 5 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.