Cannot start container when setting lxc.uts.name = foo

LXC
1

HI,

as title says i cannot start container when setting lxc.uts.name = foo

it start fine when commenting lxc.uts.name = foo out on the config file.

When the container running, one cannot set hostname also.

sudo lxc-checkconfig | grep -i uts
Utsname namespace: enabled

please help.

thnx.

2

What LXC version?

3

felipe@satriani ~> lxc-ls --version
5.0.2

felipe@satriani ~> uname -a
Linux satriani 6.1.0-11-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-4 (2023-08-08) x86_64 GNU/Linux

4

Ok and what error are you getting?

5 
felipe@satriani:~$ lxc-start -n debian-bookworm-01 -d -F 
Running scope as unit: run-r46a3b9c031434ed1bf036628898a6544.scope
lxc-start: debian-bookworm-01: ../src/lxc/cgroups/cgfsng.c: __cgfsng_delegate_controllers: 3341 Device or resource busy - Could not enable "+cpu +memory +pids" controllers in the unified cgroup 8
lxc-start: debian-bookworm-01: ../src/lxc/conf.c: setup_utsname: 876 Operation not permitted - Failed to set the hostname to "debian-bookworm-01"
lxc-start: debian-bookworm-01: ../src/lxc/conf.c: lxc_setup: 4376 Failed to setup the utsname debian-bookworm-01
lxc-start: debian-bookworm-01: ../src/lxc/start.c: do_start: 1272 Failed to setup container "debian-bookworm-01"
lxc-start: debian-bookworm-01: ../src/lxc/sync.c: sync_wait: 34 An error occurred in another process (expected sequence number 3)
lxc-start: debian-bookworm-01: ../src/lxc/start.c: __lxc_start: 2107 Failed to spawn container "debian-bookworm-01"
lxc-start: debian-bookworm-01: ../src/lxc/tools/lxc_start.c: main: 306 The container failed to start
lxc-start: debian-bookworm-01: ../src/lxc/tools/lxc_start.c: main: 311 Additional information can be obtained by setting the --logfile and --logpriority options
6

Okay so that’s starting from an unprivileged user with the systemd scope stuff.
Can you show your container’s config file to make sure the uid/gid map is correct?

7

Sure, here it is:

.local/share/lxc/debian-bookworm-01/config


# Template used to create this container: /usr/share/lxc/templates/lxc-download
# Parameters passed to the template:
# For additional config options, please look at lxc.container.conf(5)

# Uncomment the following line to support nesting containers:
#lxc.include = /usr/share/lxc/config/nesting.conf
# (Be aware this has security implications)

# Subuids and subgids mapping
# "Secure" mounting
# Network configuration
# Disable AppArmor confinement for containers started by non-root
# See https://discuss.linuxcontainers.org/t/unprivileged-container-wont-start-cgroups-sysvin$
# https://discuss.linuxcontainers.org/t/cannot-use-generated-profile-apparmor-parser-not-ava$

# Distribution configuration
lxc.include = /usr/share/lxc/config/common.conf
lxc.include = /usr/share/lxc/config/userns.conf
lxc.arch = linux64


# Container specific configuration
lxc.include = /etc/lxc/default.conf
lxc.idmap = u 0 100000 65536
lxc.idmap = g 0 100000 65536
lxc.mount.auto = proc:mixed sys:ro cgroup:mixed
lxc.apparmor.profile = unconfined
# Unprivileged containers started by ROOT can use lxc.apparmor.profile = generated
lxc.rootfs.path = dir:/home/felipe/.local/share/lxc/debian-bookworm-01/rootfs
#lxc.mount.entry = /home/backuppc /home/felipe/.local/share/lxc/debian-bookworm-01/rootfs/va$

# Network configuration
lxc.net.0.type = veth
lxc.net.0.link = lxcbr0
lxc.net.0.flags = up
lxc.net.0.hwaddr = 00:FF:1b:d6:aa:fe
lxc.uts.name = debian-bookworm-01

felipe@satriani:~$ cat /etc/subuid
felipe:100000:65536

felipe@satriani:~$ cat /etc/subgid
felipe:100000:65536

The exact same config in other machine works fine.
Thank you.

8

Yeah, that looks fine.

Maybe manually try something like:

stgraber@castiana:~$ unshare -u -U -r
root@castiana:~# hostname foo
root@castiana:~# cat /proc/sys/kernel/hostname 
foo
root@castiana:~# 
logout
9 
felipe@satriani:~$ lxc-attach -n debian-bookworm-01 
Running scope as unit: run-r5a7f806e50874b87bdcd2c354b503399.scope
root@satriani:/# unshare -u -U -r
root@satriani:/# hostname foo
hostname: you must be root to change the host name

Hi. It should be something with the OS infrastructure because at some time debian introduced running unconfined regular user containers via systemd-run, that is not the case anymore, as I mentioned, the same container runs perfectly on a different machine with same lxc, kernel and debian version. it should be something that kept on after upgrade. I don’t know where to dig though

10

You may want to look for anything user namespace related in /proc/sys as a number of distros have added extra knobs there to limit what an unprivileged user can do.

In this case, a low or zero value in /proc/sys/user/max_uts_namespaces could explain it.
May be worth going over /proc/sys/user/* to see if there’s anything in there that may cause this.