---
title: "Proxmox LXC i praksis: de fejl jeg selv lavede"
description: "Unprivileged kontra privileged, uid-mapping til nobody, og hvorfor Docker i en unprivileged LXC driller på nye kerner."
date: 2026-05-26
taxonomies:
  tags: [proxmox, lxc, homelab, selfhost]
draft: false
extra:
  godkendt: "v1:e9ae34841a773a0941e783eb3d16c4bc772cd923d13f0caf22575682400347a1"
---

Næsten alt i mit homelab kører i **LXC-containere** på **Proxmox VE** frem for
fulde virtuelle maskiner. De er lette, starter på et øjeblik og deler kernen med
værten. Men der er et par steder hvor jeg har lært det på den hårde måde.

## Unprivileged kontra privileged

Proxmox defaulter til **unprivileged** containere i GUI'en, og det er den rigtige
default. Internetvendte tjenester som webservere og reverse proxies bør køre
unprivileged af sikkerhedshensyn. DNS, proxies, overvågning og lette tjenester er
perfekte LXC-kandidater.

**Privileged** containere bør du kun bruge til isolerede homelabs uden
internetvendte tjenester, til NFS-servere hvor uid-mapping bliver for besværligt,
eller til hurtige testmiljøer. Min tommelfingerregel: unprivileged medmindre noget
tvinger mig til andet.

## Alt bliver til `nobody`

Den første væg man render ind i med unprivileged containere: hver fil og mappe
mappes til **`nobody`** (uid 65534). Det giver bøvl så snart du har restriktive
rettigheder, eller vil skrive filer med et bestemt uid/gid. Især når du monterer
**netværksshares** ind, introducerer uid-shiftet en hel del kompleksitet du skal
forstå før det spiller.

Løsningen er ikke at give op og køre privileged. Det er at lære `lxc.idmap` at
kende og mappe de specifikke uid'er du har brug for. Det tager en eftermiddag at
forstå, og så har du det som værktøj resten af tiden.

## Docker i en unprivileged LXC er en fælde lige nu

Det her bed mig for nylig. De fleste guides til **Docker i LXC** online er
forældede .. de antager kerne 5.x og runc 1.1.x. På moderne Proxmox med
**kerne 6.14+** og **runc 1.2+** fejler de opskrifter før du overhovedet når frem
til de gamle workarounds. Unprivileged Docker er reelt brudt på nye kerner på
grund af runc's per-namespace sysctl-skrivning og Dockers AppArmor-probe.

Næsten enhver fungerende opsætning i forummerne involverer enten
**kerneændringer på værten**, at slå **AppArmor** helt fra, eller begge dele. Mit
råd: vil du køre Docker, så kør det i en **VM** i stedet, eller i en bevidst
**privileged** LXC du holder isoleret. Det er ikke kampen værd at presse det ind i
en unprivileged container på en ny kerne.

## LXC kontra VM

Jeg vælger LXC til langt det meste: reverse proxy, databaser, statiske websites,
små API'er. Jeg vælger en **VM** når jeg har brug for en anden kerne, fuld
isolation, eller netop Docker-tunge workloads. Reglen er enkel: container når jeg
kan, VM når jeg skal.

## Kilder og videre læsning

- [Proxmox wiki: Unprivileged LXC containers](https://pve.proxmox.com/wiki/Unprivileged_LXC_containers)
- [Docker on Proxmox LXC: what actually works](https://dev.to/mattercoder/docker-on-proxmox-lxc-what-actually-works-and-why-unprivileged-doesnt-45km)
- [Privileged vs. unprivileged LXC](https://proxmoxpulse.com/articles/privileged-vs-unprivileged-lxc-containers-proxmox/)
- [Proxmox: LXC containers vs. VMs](https://homelabstarter.com/proxmox-lxc-vs-vm/)