Setting boot.autostart to true on a working container gives error about subuid/subgid being unconfigured

The title pretty much sums it up: I have a working unprivileged container that I tried to set boot.autostart to true on, and get the following error:

Error: Invalid expanded config: No uid/gid allocation configured. In this mode, only privileged containers are supported

My /etc/sub{uid,gid} files are configured correctly, and this container has character devices and storage mounts passed into it, so clearly it’s working fine otherwise. Any ideas? (I did just update the Debian host to 12.6, in case something might have broken in that process.)

That error indicates that Incus did not read a valid uid/gid map when it started.
If your /etc/subuid or /etc/subgid has changed since then, systemctl restart incus should get it to read things again.

If that doesn’t help, please post the content of both files.

I was able to fix this by decreasing the size of root’s subuid/gid allocation range (down to the recommended 1000000000 from 5000000000, which was probably excessive anyway). Unsure why that worked before and then didn’t, maybe something changed with the Debian upgrade?

While I’ve got your attention, does incus ever edit the subuid/gid files in /etc directly, say when setting a specific raw.idmap on a container or something? Or is it setting those mappings by other means when the container runs? Just curious because there were some other mappings in those files that I can’t remember if I added myself at some point or not.

Thanks for all your work with lxc/incus, I use them extensively and they’ve been great.