Run Docker Inside an LXC on Proxmox VE Without Going Privileged

If you are hitting Cannot connect to the Docker daemon at unix:///var/run/docker.sock inside a Proxmox LXC container, the usual advice is to make the container privileged. In most cases you do not need to, and you should not want to.

An unprivileged container with nesting=1 runs Docker fine. This guide covers that setup, the correct pct syntax (two commands that circulate widely do not exist), and when a privileged container is genuinely the only option.

Correcting two commands you will see elsewhere

An earlier version of this article, and plenty of forum posts, suggest this:

# Neither of these works
pct set <VMID> -nesting 1
pct set <VMID> -privileged 1

Both are wrong:

• nesting is not a top-level option. It lives inside --features. The correct form is pct set <VMID> --features nesting=1.
• There is no -privileged option at all. The flag is --unprivileged, with inverted meaning (1 = unprivileged). The Proxmox documentation marks it “(Should not be modified manually.)” — privileged status is decided when the container is created, and flipping it on an existing container is not a supported workflow. If you truly need to change it, restore a backup into a new container instead.

Why unprivileged is the right default

This is not a stylistic preference. The Proxmox documentation is unusually blunt about it:

The LXC team considers this kind of container as unsafe, and they will not consider new container escape exploits to be security issues worthy of a CVE and quick fix.

That is about privileged containers, and it has a practical consequence: a container escape from a privileged LXC is not treated as a vulnerability that gets patched. In an unprivileged container, root inside is mapped to an unprivileged user outside, so — in Proxmox’s words — most security issues “will affect a random unprivileged user, and would be a generic kernel security bug rather than an LXC issue.”

Proxmox’s own guidance is that privileged containers “should only be used in trusted environments.” A box exposed to the internet, even behind a tunnel, is not that.

The setup

Nesting can only be changed while the container is stopped, so start there.

1. Stop the container

pct stop <VMID>

2. Enable nesting

pct set <VMID> --features nesting=1

nesting exposes procfs and sysfs inside the container, which is what lets a container runtime operate in there. Confirm it applied:

pct config <VMID> | grep -E 'features|unprivileged'

You want to see features: nesting=1 and unprivileged: 1.

3. Start it and get a shell

pct start <VMID>
pct exec <VMID> -- bash

4. Install Docker

Use Docker’s own convenience script rather than the distribution package. apt install docker.io pulls whatever version Debian or Ubuntu froze at, which is typically years behind:

curl -fsSL https://get.docker.com | sh

5. Verify

systemctl enable --now docker
docker info

docker info talks to the daemon over the Unix socket. If it returns system information rather than the socket error, the nesting change did its job.

A working reference configuration

This is not theoretical. We verified it on Proxmox VE 9.1.7 with Docker 29.7.2 running inside an unprivileged LXC that hosts Docker workloads continuously:

$ pct config <VMID> | grep -E 'features|unprivileged|ostype'
features: nesting=1
ostype: debian
unprivileged: 1

$ pct exec <VMID> -- docker --version
Docker version 29.7.2, build a7dcaa6

Unprivileged, nesting on, running current Docker. No privileged flag anywhere.

Worth noting the version gap while we are here: Docker 29.x is current, and guides still telling you to expect 20.10 are describing a release from 2021. If you followed one and installed docker.io from apt, check docker --version before debugging anything else.

When unprivileged genuinely is not enough

Some workloads do need more than nesting. The honest list is short:

Notice how many of those are solved by a more specific --features flag rather than by going privileged. Reach for the narrow flag first.

That last row is Proxmox’s own recommendation: for “maximum isolation and the ability to live-migrate”, run your containers inside a VM rather than directly in LXC. On a homelab that is often more isolation than you need, but it is the answer for anything production-facing.

Rolling it back

Nesting is reversible in the same way it was set:

pct stop <VMID>
pct set <VMID> --delete features
pct start <VMID>

Note that --delete features clears the whole features list, not just nesting. If you had mount or fuse set as well, re-apply them in one command rather than deleting.

Sources

• Proxmox VE docs — Linux Container (privileged vs unprivileged, the LXC team’s position, nesting)
• Proxmox VE docs — pct manual page (--features and --unprivileged syntax)
• Docker docs — Install Docker Engine on Debian

Related reading