LXD failed start container after update

Hey I am back here. I have been going solid for almost a year or so without any problems . I recently updated last night and rebooted and noticed the LXD service will start , but the container will not. Thinking this was a kernel issue, I rerolled back to old kernel , but after seeing that it’s still not working , I came here…

O.S Centos 7.
Linux myserver 3.10.0-862.14.4.el7.x86_64 #1 SMP Wed Sep 26 15:12:11 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Here is the info logs on the instance that I am running called centy.
https://pastebin.com/Ftm4mHwY

I thought this was a UID issue or something , but I haven’t had problems with this before.
The service is running because I can download a new image but that image will not start.

I want to say though that I like this container technology. Its for the most part solid especially since cent Os has been supported.

Hmm, so this is a bit confusing.

The error appears to be:

            lxc 20191028190329.614 ERROR    lxc_conf - conf.c:lxc_map_ids:2657 - newuidmap failed to write mapping "newuidmap: uid range [0-1000000000) -> [1000000-1001000000) not allowed": newuidmap 11302 0 1000000 1000000000 1000000000 0 1

But this would imply that you’re using a hand built LXD rather than the snap, is that correct?

If it is, then can you show what you have in /etc/subuid and /etc/subgid as the problem appears to be related to that.

If not using the snap, then those two files, if they exist, must contain a valid map for the root user which covers the uid/gid ranges used by your containers, in this case, you’d need it to have access to uids
1000000 through 1001000000.

In such a scenario, quite a few things could have happened to cause this change:

  • Something changed the content of /etc/subuid /etc/subgid
  • The files didn’t exist before and something created them now, empty, blocking everything
  • You had those files around but didn’t have the newuidmap/newgidmap binaries
  • You had those binaries but they weren’t marked setuid

If you do use /etc/subuid and /etc/subgid, I suspect they should contain:

root:1000000:1000000000

(allowing the root user to use 1000000000 uid/gid, starting at id 1000000)