Nesting and Docker inside LXC: what the flag enables and what it costs · Proxmox VE

“Can I run Docker in an LXC container?” is the most-asked Proxmox question that has a one-word answer and a one-page explanation. The word is yes. The page is why the official position is that you should not, why thousands of estates do it anyway and are fine, and how to tell which of those two situations you are in.

What `nesting` actually is

The documentation is terse and precise: nesting exposes procfs and sysfs to allow nested containers.

That is the whole feature. It is not a privilege escalation, a capability grant, or a Docker compatibility mode. It removes two masks.

By default PVE mounts parts of /proc and /sys inside a container as read-only or replaces them with restricted views, because a container has no business reading the host’s kernel state and a great deal of /sys is host state. But a container runtime inside the container - Docker, Podman, systemd-nspawn, or lxc again - needs to read and write those same interfaces to create its own namespaces and cgroups. Without them it cannot start anything.

Read-only / Safethe difference nesting makes, seen from inside

# pct exec 200 -- ls /sys/fs/cgroup/ | head -6
pct exec 200 -- cat /proc/self/cgroup

cgroup.controllers
cgroup.max.depth
cgroup.procs
cgroup.subtree_control
init.scope
system.slice
0::/

Illustrative output

0::/ is the container’s view of its own cgroup root - a nested cgroup namespace. That is what nesting buys, and it is what Docker’s daemon needs to place its containers in cgroups of their own.

Configuration changeenable nesting on an unprivileged container— Changes the container config. Requires a restart. Enabling nesting alone does not change the container's privilege level.

set -euo pipefail
CTID=210

pct set "$CTID" --features nesting=1
pct reboot "$CTID"

pct config "$CTID" | grep -E '^(unprivileged|features):'

features= replaces the whole list, it does not append

pct set 210 --features nesting=1 on a container that already had features: keyctl=1,nesting=1 leaves it with nesting=1 only. There is no add-one-flag form.

Read the current value first and rewrite it in full:

CTID=210
pct config "$CTID" | grep '^features:'
pct set "$CTID" --features nesting=1,keyctl=1

This bites hardest on containers configured months ago by someone else, where the flag you are about to drop is the one holding something obscure together.

The other feature flags, and what each is for

Flag	Exposes	Typical reason
`nesting=1`	procfs and sysfs, for nested containers	Docker, Podman, nested LXC, some `systemd` units
`keyctl=1`	`keyctl` syscalls for kernel key management	`systemd`-based images that use the kernel keyring; some Docker builds
`fuse=1`	FUSE filesystem support	`fuse-overlayfs`, `sshfs`, `rclone`, `s3fs` inside the container
`mknod=1`	Device node creation	Legacy device-passthrough configs; see the device passthrough lesson
`mount=`	A named list of filesystem types the container may mount	A container that must mount NFS or CIFS itself
`force_rw_sys=1`	Read-write access to system filesystems	Rare; a compatibility escape hatch

For Docker in an unprivileged container, nesting=1 is the required one and keyctl=1 is frequently needed too, depending on the images being run.

Running Docker in an unprivileged container

It works. Here is the shape of it, and the one check that most people skip.

Configuration changeprepare a container for Docker— Changes the container config and installs packages inside it. Restart required for the feature change to take effect.

set -euo pipefail
CTID=210

pct set "$CTID" --features nesting=1,keyctl=1
pct reboot "$CTID"

pct exec "$CTID" -- apt-get update
pct exec "$CTID" -- apt-get install -y docker.io

pct exec "$CTID" -- docker run --rm hello-world

Read-only / Safethe check people skip - which storage driver did Docker choose?— Read-only. This is the single most informative command about whether Docker-in-LXC is going to behave here.

set -euo pipefail
CTID=210

pct exec "$CTID" -- docker info --format 'Storage Driver: {{.Driver}}'
pct exec "$CTID" -- docker info --format 'Backing Filesystem: {{.DriverStatus}}'
pct exec "$CTID" -- df -h /var/lib/docker

If that reports overlay2, you are in good shape. If it reports vfs, you have a problem that will not announce itself for weeks.

The vfs storage driver, and the rootfs that fills up out of nowhere

The symptom. A container with a 32 GiB rootfs running four small Docker images fills its disk. docker system df reports a couple of gigabytes of images. du on /var/lib/docker reports twenty-six. The numbers do not agree, and the container is dying.

What happened. Docker’s overlay2 driver stores each image layer once and composes them with an overlay mount. That requires the underlying filesystem to support being an overlayfs upper layer. Where it cannot - some container-rootfs and kernel-feature combinations - Docker falls back to the vfs driver, which has no layer sharing at all: every layer of every image is a full recursive copy of the layer below it.

A ten-layer image whose final size is 400 MiB can occupy several gigabytes under vfs. Ten images share nothing, so the growth is multiplicative rather than additive, and it happens at docker pull time - long before anyone correlates it with a change.

Why the first diagnosis is wrong. docker system df reports logical image sizes and deduplicated totals. Under vfs those numbers bear almost no relationship to the bytes on disk, so the tool you would naturally reach for actively tells you there is no problem. People prune, gain nothing, and conclude the disk accounting is broken.

The check:

CTID=210
pct exec "$CTID" -- docker info --format '{{.Driver}}'
pct exec "$CTID" -- du -sh /var/lib/docker
pct exec "$CTID" -- docker system df

Two of those three disagreeing is the diagnosis.

The fixes, in order of preference:

Give /var/lib/docker its own volume mount point on a backend whose filesystem supports overlayfs upper layers, so overlay2 is available.
Enable fuse=1 and install fuse-overlayfs, which gives layer sharing in userspace at some performance cost.
Move the workload to a VM, where Docker gets an ordinary block device and an ordinary filesystem and none of this arises.

Do not “fix” it by making the container privileged. That changes the security posture to solve a storage problem, and it may not even help.

Three runtimes, one kernel

A Docker container inside an LXC container inside PVE is not three layers of isolation. It is three configurations of the same isolation, applied by one kernel, and they compose by intersection rather than by stacking.

PVE’s LXC container gets a user namespace mapping container 0..65535 to host 100000..165535, a set of dropped capabilities, an AppArmor profile and a cgroup subtree.
Docker inside it creates further namespaces and a nested cgroup subtree. Those are children of the LXC container’s, so the Docker container’s root is host UID 100000 too, and its cgroup limits are bounded by the LXC container’s.
Every one of those namespaces is enforced by the same kernel that runs the host. There is no second kernel anywhere in this picture.

Two consequences follow, and they point in opposite directions.

The reassuring one: because the mappings nest, a Docker container running as root inside an unprivileged LXC container is running as host UID 100000. A Docker escape lands the attacker in the LXC container’s namespace as an unmapped, unprivileged host user - which is a strictly better outcome than a Docker escape on bare metal, where it lands as host root.

The sobering one: nesting requires exposing procfs and sysfs, which are exactly the interfaces that container-escape research targets. You have widened the kernel surface the innermost workload can reach in order to make the nesting work at all. And a kernel vulnerability reachable from that surface is not contained by any of the three layers, because all three are that kernel.

Which is why the honest summary is neither “it is fine” nor “never do it”. It is: nesting trades a wider kernel surface for a lower privilege level, and whether that trade is good depends entirely on whether you trust the code in the innermost container.

The decision, stated properly

The official Proxmox position is that Docker workloads belong in a VM. The reasoning is sound and it is about support and layering, not about a specific exploit. Here is the decision as it actually presents itself:

Situation	Answer	Why
Third-party or customer-supplied images	VM	You are not the author of the innermost code. The kernel is shared.
A regulated workload with an isolation requirement	VM	“Namespaces” will not satisfy an auditor asking about tenant separation.
Docker Compose stack you wrote, on your own cluster	LXC with nesting is defensible	Trusted code, and you gain density and instant start
Home lab, single tenant	LXC with nesting is fine	The threat model is a household
A CI runner building untrusted pull requests	VM, emphatically	This is the worst case: hostile code, by design, on every run
It needs to survive a live migration	VM	See below
Someone said “make it privileged and it works”	Stop	That is a different and much larger decision

Privileged plus nesting is close to giving away the host

Nesting on an unprivileged container is a considered trade. Nesting on a privileged container is a different thing entirely: container root is host root, and you have just handed that root a writable view of procfs and sysfs.

Writable /sys from a UID-0-on-the-host process is enough to reach kernel interfaces that were never designed to be exposed to anything but the host’s own administrator. Treat a privileged container with nesting as host-equivalent, because that is what it is, and do not let it exist because a tutorial said it was the easy way to get Docker working.

If a workload will not run under unprivileged=1 with nesting=1, that is information: it wants host-level access, and the right container for it is a virtual machine.

What happens if you live-migrate a container running Docker?

You do not, and finding that out during a node evacuation is a bad time.

Live migration of a container relies on checkpointing and restoring process state. A Docker daemon inside the container has its own namespaces, its own cgroup subtree, network interfaces it created, and open state against the kernel that the checkpoint cannot reliably capture and replay. In practice the container is migrated offline: stopped, moved, started - which is a real outage for everything the Docker daemon was running.

The knock-on effects are what actually hurt:

HA failover restarts everything. Every Docker container inside comes up fresh, in whatever order Docker chooses, with no coordination of the startup ordering your Compose file assumed.
Node evacuation is not transparent. The evacuation procedure in node evacuation assumes guests move without service loss. A Docker-in-LXC container breaks that assumption, so it needs its own line in the maintenance plan.
Anything Docker kept on a bind mount is subject to the bind-mount migration trap described in bind mounts - which is where Docker volumes usually live.

If a workload’s availability requirement includes surviving a host maintenance window without a restart, Docker-in-LXC does not meet it. A VM does, because live migration of a VM moves memory pages and does not care what is running inside them.

Verification and undo

Read-only / Safea Docker-in-LXC container that is actually healthy— Read-only. Each of the four checks can fail independently and each has a different fix.

set -euo pipefail
CTID=210

# 1. Privilege level is what you think it is.
pct config "$CTID" | grep -E '^unprivileged:' || echo 'unprivileged: 0 (PRIVILEGED)'

# 2. Only the features you intended are set.
pct config "$CTID" | grep -E '^features:'

# 3. Docker chose a layer-sharing storage driver, not vfs.
pct exec "$CTID" -- docker info --format '{{.Driver}}'

# 4. On-disk usage and Docker's own accounting agree within reason.
pct exec "$CTID" -- du -sh /var/lib/docker
pct exec "$CTID" -- docker system df

Service impact possibleturn nesting back off— Restarts the container. Anything running inside Docker stops. Docker will not start again until nesting is restored.

set -euo pipefail
CTID=210

pct exec "$CTID" -- systemctl stop docker
pct set "$CTID" --delete features
pct reboot "$CTID"

pct config "$CTID" | grep -E '^features:' || echo 'no features set'

Note what the undo does not do: images and volumes under /var/lib/docker remain on the rootfs, consuming space, with nothing able to read them. If you are decommissioning Docker rather than pausing it, remove them before you remove the flag, while the daemon can still enumerate what it owns.

Knowledge check

Why this matters

Docker-in-LXC is the clearest example in this course of a question where the official answer and the common practice diverge, and where repeating either one without understanding is a mistake.

The reason the official answer is “use a VM” is not that a specific exploit exists. It is that you are running three container configurations on one kernel, in a stack where nobody owns the whole picture: Proxmox supports the outer container, Docker supports the inner one, and the interaction between them is yours. When it breaks in an unusual way, there is no vendor for the seam.

The reason so many estates run it anyway is that for trusted, self-authored workloads on a single-tenant cluster, the trade is genuinely good, and the nested UID mapping makes the privilege picture better than people assume.

What separates a considered choice from cargo-culting is being able to answer three questions without looking anything up: is the innermost code trusted, does the workload need to survive a live migration, and which storage driver did Docker actually pick. An operator who can answer those has made a decision. An operator who enabled nesting because a forum post said to has made a wish.

What nesting actually is