Incus: No uid/gid allocation configured

Incus
1

I have trouble with getting incus going on a quite fresh archlinux host

[manolo@arch-laptop ~]$ incus launch images:voidlinux hello-world
Launching hello-world
Error: Failed instance creation: Failed creating instance record: Failed initialising instance: Invalid config: No uid/gid allocation configured. In this mode, only privileged containers are supported

There is a running podman installation, which might matter as it also uses /etc/subuid & /etc/subgid.

My files currently look like this:

[manolo@arch-laptop ~]$ cat /etc/subuid
manolo:100000:65536
incus:1000000:65536

[manolo@arch-laptop ~]$ cat /etc/subgid
manolo:100000:65536
incus:1000000:65536

any idea what is going wrong here?

a side question … should not installing incus via packagemanager provide a valid config for this?

2

incus consumes uid/gid map allocations for the root user.

A normal setup is:

root:1000000:1000000000

In both uidmap and gidmap. That is the setup that we’d normally expect most distros to put in place for you at installation time.

1 Like
3

thx

root:1000000:1000000000 lines in /etc/subuid & /etc.subgid however have the same result unfortunately

No uid/gid allocation configured. In this mode, only privileged containers are supported

incus launch images:voidlinux hello-world -c security.privileged=true however works, but as I understand the matter it is encouraged to run unprivileged containers (which is what I did on an older lxd installation without any hassle)

On another lxd instance I have this as a working setup

<username>:100000:65536. But here it does not do anything neither

4

Did you restart incus after updating your subuid and subgid files?

5

What I am doing is

  1. Install Incus package
  2. add personal user to incus & incus-admin groups
  3. sudo systemctl enable --now incus.socket incus.service
  4. add entries to /etc/sub{uid,gid}
  5. sudo systemctl restart incus.socket incus.service
  6. incus launch images:voidlinux hello-world

anything wrong with that sequence maybe?

6

Can you add --verbose to INCUS_OPTS in /etc/default/incus and then sudo systemctl restart incus?

After that, please post the content of /var/log/incus/incusd.log

7

there is no /etc/default/incus. So I guess I need to create is but … whoe exactly to I

add --verbose to INCUS_OPTS

on such a blank file exactly?

8

Hmm, what Linux distribution is this on?

9

Also, can you show:

  • cat /etc/subuid
  • cat /etc/subgid
  • uname -a
  • which newuidmap
  • which newgidmap
10

Can confirm that this is not the case on Archlinux, I ran into the same issue.

Could you please elaborate on why incus is always reading the mapping for root, instead of the one for the user trying to create a container?

11

Because incus runs as root.

12

Would it be possible to allow non-root users to launch containers?

After adding the required mapping for root, as described above, and restarting the daemon, it now works.

13

It’s possible for non-root users to talk to Incus and control it, either fully (members of the incus-admin group) or in a restricted fashion (members of the incus group).

But Incus itself will always run as root as it needs to perform a bunch of privileged actions like generating security profiles, handling filesystem operations, preparing network, …

So at the end of the day, only the allocation for the root user matters to what Incus does.

14

Right, but that is still effectively root, which is… eh.

I was mainly wondering about it since I’m coming from podman and am used to not needing root. I assume incus uses certain operations that require root, and I’m curious as to what those are. I know that one can have unprivileged user namespaces, but apart from that I know very little of how incus (or, rather, LXC) works internally. I guess my question would be better phrased as, in what ways does incus differ from podman in order to require root privileges?

15

The only thing you can do as an unprivileged user is get a user namespace which maps your own single uid and gid to any uid/gid that you want.

Anything else requires privileges, either in obvious ways by running the logic directly as root, or indirectly through setuid/setcap helpers.

Anything that needs to put mounts in place (and doesn’t rely solely on FUSE) needs root privileges, so in our case, that means interacting with ZFS, LVM, btrfs, Ceph, …
The same goes on the network side, only root can create network interfaces on the host system, so all our network stuff requires root (create and run bridges, create veth pairs to attach to the containers, create tap devices for VMs, apply tc/iptables/nft rules, …).

Then the same is true for the security stuff, we need root to generate AppArmor namespaces, generate custom per-instance apparmor policies and load them into the kernel, …

It’s certainly possible to split out every bit of privileged logic into their own setuid/setcap binaries to give the illusion of everything actually being done by the unprivileged user, but it’s basically just that, an illusion :slight_smile:

There are ways to do the filesystem stuff without privileges, but that involves FUSE and so gets rather slow. Similarly, it’s possible to do a bunch of network stuff in userspace by using a tun device inside the container and connecting that to a userspace relay daemon, but again, that’s going to be very slow.

Getting more than one uid/gid isn’t possible without extra privileges (such as using newuidmap/newgidmap), at least until we complete our work on implementing isolated user namespaces (see https://www.youtube.com/watch?v=mOLzSzpVwHU)

16

Thank you for the helpful answer and the link to the FOSDEM video. (Actually, I ran into this issue right after watching the video of your FOSDEM talk – very nice talk and the demo, by the way! trying out incus has been on my list for a while, but I was waiting for the arch package).

It’s quite interesting watching how the namespace subsystem(s) and related infrastructure evolve.