[lxc-users] Container fails to start with 'uid range not allowed'

[Sean Templeton]

I have been trying to create an unprivileged container for the past couple days with no success. After having read the entire Internet, I'm about to give up and just create a privileged container. But maybe you all can figure out what I am doing wrong.

I created a user 'zrw' on the host and am trying to map the uid and guid from the container to this user. I have created the container but have otherwise not touched it. My end goal is to install Samba in the container and mount a directory on the host to share out.

When I create the user, /etc/subuid and /etc/subgid automatically have the following added:
root at server:/# cat /etc/sub* | grep zrw
zrw:689824:65536
zrw:689824:65536

but "id -u zrw" and "id -g zrw" both return 1000. Why would 689824 automatically be put in the /etc/sub* files? From all of my reading I thought the uid and guid in the /etc/sub* files should be the same as the user and group ids?
I changed the subuid and subgid files to
zrw:689824:65536
zrw:1000:1

I then put this mapping in the container's .conf file (along with many other different variations, like id_map = u 0 689824 65536)
lxc.id_map = u 0 100000 1000
lxc.id_map = g 0 100000 1000
lxc.id_map = u 1000 1000 1
lxc.id_map = g 1000 1000 1
lxc.id_map = u 1001 100000 64535
lxc.id_map = g 1001 100000 64535

When I start the container I get the following output:

lxc-start: cgroups/cgfsng.c: create_path_for_hierarchy: 1321 Path "/sys/fs/cgroup/systemd//lxc/100" already existed.
lxc-start: cgroups/cgfsng.c: cgfsng_create: 1385 No such file or directory - Failed to create /sys/fs/cgroup/systemd//lxc/100: No such file or directory
lxc-start: cgroups/cgfsng.c: create_path_for_hierarchy: 1321 Path "/sys/fs/cgroup/systemd//lxc/100-1" already existed.
lxc-start: cgroups/cgfsng.c: cgfsng_create: 1385 No such file or directory - Failed to create /sys/fs/cgroup/systemd//lxc/100-1: No such file or directory
... same output as above repeating up to systemd//lxc/100-33

newuidmap: uid range [0-1000) -> [689824-690824) not allowed
lxc-start: start.c: lxc_spawn: 1164 Failed to set up id mapping.
lxc-start: start.c: __lxc_start: 1357 Failed to spawn container "100".
newuidmap: uid range [0-1000) -> [689824-690824) not allowed
lxc-start: conf.c: userns_exec_1: 4379 Error setting up child mappings
lxc-start: cgroups/cgfsng.c: recursive_destroy: 1276 Error destroying /sys/fs/cgroup/systemd//lxc/100-20
newuidmap: uid range [0-1000) -> [689824-690824) not allowed
lxc-start: conf.c: userns_exec_1: 4379 Error setting up child mappings
lxc-start: cgroups/cgfsng.c: recursive_destroy: 1276 Error destroying /sys/fs/cgroup/cpuset//lxc/100-20
lxc-start: conf.c: userns_exec_1: 4379 Error setting up child mappings
... same output as above repeating up to 100-33 for cgroup/cpu, cgroup/blkio, cgroup/memory, cgroup/devices, etc.

lxc-start: tools/lxc_start.c: main: 365 The container failed to start.


You can tell how many tries I've made by the fact that it creates a new 100-<incremented number here> every time I try to start the container.
Every variation of mapping I have tried always ends with uid range not allowed.

On another note, if I delete the container and then try to rm -rf /sys/fs/cgroup/pids/lxc/100* I get "Operation not permitted" on a ton of files in those directories, and consequently the directories are not deleted. To "solve" that a previous time, I reinstalled the operating system. From other reading it does not appear there are any attributes set on these files and lsattr gives "lsattr: Inappropriate ioctl for device While reading flags on ./cgroup.procs" for every file. Are these files created with a special permission when creating the container, the container fails to start, and somehow the error handling code can't delete them so I'm stuck with them forever? (Unless I pull the nuclear option of course.)

I would appreciate any help!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20170128/ff6131c6/attachment-0001.html>