On Debian, when running:

$ fakeroot cdebootstrap stable /tmp/foo

cdebootstrap downloads the packages, but when it has to extract them, I get this error:

E: Failed to unshare: Operation not permitted

How can I run cdebootstrap as non-root?

This part in unshare's manual seems relevant, but am not sure how:

EPERM (since Linux 3.9)
              CLONE_NEWUSER was specified in flags 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
  • Can you list the packages, and their associated permissions here: ls -al /tmp/foo? – eyoung100 Jul 29 '15 at 22:18
  • Yes, they're in /tmp/foo/var/cache/bootstrap/, and their permissions are set to 644 to my user. – Florian Margaine Jul 29 '15 at 22:22
  • Have you tried sudo fakeroot It's the fakeroot that isn't permissioned right...? – eyoung100 Jul 29 '15 at 22:37
  • @eyoung100 I'm not sure I understand? sudo fakeroot does work. – Florian Margaine Jul 29 '15 at 22:43

maybe /tmp is the issue. try

$fakeroot cdebootstrap stable $HOME/somedir

| improve this answer | |
  • No, it's not working either, same error. – Florian Margaine Jul 29 '15 at 22:02


Your issue has to do with permission inheritance. cdbootstrap will inherit the permissions of fakeroot, which can be elevated via sudo. Issue:

sudo fakeroot cdbootstrap /tmp/foo

If the above command succeeds, permissions on /tmp are the issue. See What are common rights for /tmp ? I unintentionnally set it all public recursively, for what the default permissions should be. Generally, writing anything into /tmp that wasn't put there by an application is a bad idea, and fakeroot has it's own issues. From the man page:


   Library versions
          Every command executed within fakeroot needs to be linked to the
          same version of the C library as fakeroot itself.

          fakeroot  doesn't  wrap open(), create(), etc. So, if user joost
          does either

          touch foo
          ls -al foo

          or the other way around,

          touch foo
          ls -al foo

          fakeroot has no way of knowing that in the first case, the owner
          of  foo  really  should be joost while the second case it should
          have been root.  For the Debian packaging, defaulting to  giving
          all "unknown" files uid=gid=0, is always OK. The real way around
          this is to wrap open() and  create(),  but  that  creates  other
          problems, as demonstrated by the libtricks package. This package
          wrapped many more functions, and tried to do  a  lot  more  than
          fakeroot .  It turned out that a minor upgrade of libc (from one
          where the stat() function didn't use open() to one with a stat()
          function that did (in some cases) use open()), would cause unex-
          plainable segfaults  (that  is,  the  libc6  stat()  called  the
          wrapped  open(),  which  would then call the libc6 stat(), etc).
          Fixing them wasn't all that easy, but once fixed, it was just  a
          matter  of  time  before another function started to use open(),
          never mind trying to port it to a  different  operating  system.
          Thus  I decided to keep the number of functions wrapped by fake-
          root as small as possible, to limit the  likelihood  of  'colli-

   GNU configure (and other such programs)
   of the file will be 000. The bug is that if root does the same,  open()
   will succeed, as the file permissions aren't checked at all for root. I
   choose not to wrap open(), as open() is used by many other functions in
   libc  (also  those  that  are already wrapped), thus creating loops (or
   possible future loops, when the implementation of  various  libc  func-
   tions slightly change).

Better Solution

Instead of using privilege escalation to achieve what you're trying to do consider using a proper chroot, as outlined in the DebootstrapChroot Documentation for Ubuntu, or the Official Debian Documentation for DebBootStrap.

| improve this answer | |
  • I don't want to use sudo. I want to have a user-space chroot, hence my reason to use fakeroot in the first place. It's also not an issue with /tmp/, since it has the same issue with a folder in $HOME. – Florian Margaine Jul 30 '15 at 0:27
  • Read the Documentation I provided under Better Solution and install the DebBootstrap in userspace, Fakeroot will not work using the method you're trying to use it for, because of the Limitations in the Limitation Section above. Fakeroot is mainly used to modify config files, and build debian packages. It cannot emulate a full fleged chroot – eyoung100 Jul 30 '15 at 0:34

Not the answer you're looking for? Browse other questions tagged or ask your own question.