Proxmox 9.2 ist da, und der eigentliche Streit dreht sich darum, wie viel Macht die UI haben sollte
Das Release wirkte groß, weil die Erwartungen größer wurden
Proxmox 9.2 kam nicht einfach als weitere Versionsnummer daher. Es landete wie ein Meilenstein für eine Community, die sich seit Jahren still dieselbe Frage stellt: Wie viel von dem hässlichen Kram sollte die Plattform endlich einfacher machen? Der Release-Thread hatte die übliche Aufregung, die übliche „Ich update später"-Energie und die übliche Mischung aus vorsichtigen Admins und Homelab-Draufgängern. Aber die stärkste Reaktion galt nicht einem glanzvollen Highlight-Feature. Sie galt dem Schmerz. Altem, vertrautem, berechtigungsbezogenem Schmerz.
Das sagt viel darüber aus, wo Proxmox heute steht. Die Nutzer fragen nicht mehr nur, ob es VMs gut ausführen kann. Diese Schlacht ist größtenteils gewonnen. Sie fragen, ob es die tägliche Arbeit mit Containern, geteiltem Storage, Backups, Migrationen, Berechtigungen und hybriden Homelab-Setups weniger nach einem Stapel zusammengeklebter Forenbeiträge aussehen lassen kann. Vor ein paar Jahren hätte ein Release, das das UID- und GID-Mapping von Containern verbessert, wie eine Randnotiz geklungen. In diesem Thread war es genau das, was die Leute seltsam glücklich machte.
Und ehrlich gesagt, das passt. Infrastruktur-Nutzer bejubeln nicht immer die glänzenden Dinge. Manchmal jubeln sie, weil eine Config-Datei, die früher wie eine verfluchte Matheaufgabe aussah, jetzt sauberer gehandhabt werden kann. Das ist nicht langweilig. Das ist Befreiung mit Web-UI.
Das hässliche UID-Mapping-Problem kommt endlich ans Licht
Im Zentrum der Diskussion stand das LXC-Identity-Mapping. Falls Ihnen bei diesem Ausdruck schon die Augen glasig werden: genau das ist das Problem, das Proxmox 9.2 entschärfen will. Auf dem Papier sind unprivilegierte Container großartig. Sie sind sicherer. Sie verkleinern den Explosionsradius. Es ist das, von dem viele wissen, dass sie es eigentlich nutzen sollten. Dann kommt die Realität mit Bind-Mounts, Host-Datasets, NFS-Shares, Medienbibliotheken, Download-Clients, User-IDs und Group-IDs daher, und plötzlich ist jeder nur noch ein missglücktes chown von einem emotionalen Zusammenbruch entfernt.
Ein Nutzer zeigte den alten Weg mit einem Stapel von lxc.idmap-Zeilen, die UIDs und GIDs in Blöcken mappen. Das war die Art von Konfiguration, die weniger nach Administration aussieht und mehr nach schwarzer Magie, die man um 2 Uhr nachts von einem Fremden kopiert hat. Ein anderer sagte im Grunde, dass der neue Ablauf das alles in eine simple Auswahl verwandelt: aussuchen, welche Container-IDs auf welche Host-IDs gemappt werden. Kein Ringen mehr mit /etc/subuid oder /etc/subgid, nur damit ein Container ein Host-Verzeichnis anfassen kann, ohne dass man den Verstand verliert.
Deshalb reagierten die Leute so heftig. Das Feature trifft eine sehr spezifische Wunde. Viele Proxmox-Nutzer betreiben mehrere LXCs gegen Host-Storage. Mal ist es ein ZFS-Dataset für Medien. Mal ein NFS-Share. Mal ein Haufen App-Daten, der sauber begann und langsam zu einem Berechtigungssumpf wurde. Zu verwalten, welcher Nutzer in welchem Container auf welchen Pfad des Hosts zugreifen darf, wird fast unmöglich, sobald das Setup wächst. Ein Kommentator sagte, den Überblick über all die verschiedenen UIDs und GIDs über Datasets und Container hinweg zu behalten sei „unmöglich zu verfolgen und zu pflegen". Das ist keine Übertreibung. Das passiert, wenn gute Sicherheitspraktiken auf echten Homelab-Wildwuchs treffen.
Die neuen Mapping-Tools machen Linux-Berechtigungen nicht auf magische Weise einfach. Das schafft nichts. Aber sie verschieben einen guten Teil dieser Komplexität von „diese furchteinflößende Datei bearbeiten und hoffen" hin zu etwas, das normaler Administration näherkommt. Das zählt.
Das „777-Leben" ist lustig, weil jeder weiß, warum es dazu kommt
Natürlich brachte das Berechtigungsthema sofort die Geständnisse hervor. Jemand scherzte, im 777-Leben zu leben, weil einem die Kopfschmerzen einfach zu viel wurden. Ein anderer antwortete, 777 sei in einem begrenzten Homelab mit Snapshots und Backups vielleicht „akzeptabel", aber auf der Arbeit absolut nicht. Dieser kleine Austausch ist im Grunde die gesamte Kluft zwischen Homelab und Produktion in zwei Kommentaren.
Jeder weiß, chmod 777 ist kein Plan. Es ist eine weiße Fahne. Aber Leute schwenken diese Fahne normalerweise nicht, weil sie nachlässig sind. Sie schwenken sie, weil sie erschöpft sind. Sie haben den sicheren Weg versucht, wurden unter ID-Mapping begraben, sahen zu, wie die App das Dataset nicht lesen konnte, änderten den Besitzer zweimal, zerschossen einen weiteren Container und entschieden schließlich, dass es heute Abend nur darum ging, den Dienst zum Laufen zu bringen. Die zukünftige Sicherheit kann ja ein Ticket aufmachen.
Das ist der gefährliche Charme von Homelabs. Sie beginnen als Experiment und werden langsam zur Infrastruktur. Der Fileserver wird wichtig. Die Medienbibliothek wird wichtig. DNS wird wichtig. Die Hausautomation wird wichtig. Dann wird die „vorübergehende" Berechtigungsabkürzung Teil des Fundaments. Sechs Monate später erinnert sich niemand mehr, warum ein Dataset UID 121001 gehört oder warum ein LXC als Nutzer schreibt, den es nur gibt, weil eine Anleitung das so vorgab.
Manche Nutzer widersprachen der Idee, dass jeder Fall komplexes Mapping braucht. Jemand argumentierte, dass unzählige Tutorials das Ganze überkomplizieren, und dass man in vielen Setups einen Host-Nutzer mit hoher UID anlegen kann, der sich ganz natürlich auf den Nutzer im Container mapped, ganz ohne eigene idmap-Zeilen. Ein anderer bevorzugte es, wo immer möglich echte Host-IDs zu verwenden, besonders wenn Daten später per virtiofs von einem LXC in eine VM wandern könnten. Dieser Punkt ist leise wichtig. Der Container von heute könnte die VM von morgen sein. Wenn alle Dateien seltsamen Offset-IDs gehören, wird die Migration zu einem Wochenendprojekt mit chown, Reue und vielleicht Kaffee, der so stark ist, dass man Farben hört.
Der Traum vom OCI-Container wartet weiter vor der Tür
Dann kam der größere Wunschlisten-Punkt: erstklassige OCI-Container-Unterstützung. Hier wurde die Spaltung in der Community lauter. Ein Nutzer sagte, er wolle OCI-Support, um kein Docker mehr in einem LXC laufen zu lassen und stattdessen alles direkt in der Proxmox-UI zu verwalten, idealerweise mit Replikation, HA und all den Annehmlichkeiten auf Plattformebene. Das ist der Traum, um den viele Nutzer kreisen: Proxmox zu dem einen Ort machen, an dem sich VMs, LXCs, App-Container, Storage, Backups und Failover alle verbunden anfühlen.
Der Reiz ist leicht zu verstehen. Docker in einem LXC laufen zu lassen funktioniert für viele Leute, aber es fühlte sich immer ein bisschen an, als würde man ein winziges Apartment in einem anderen Apartment bauen. Es ist praktisch, aber nicht elegant. Die Leute wollen, dass Proxmox weiß, was diese Container sind, statt nur das zu hosten, was sie hostet. Sie wollen aufhören, zwischen Denkmodellen zu wechseln. Sie wollen Apps im Docker-Stil mit Infrastrukturkontrollen im Proxmox-Stil.
Aber der Widerspruch fiel scharf aus. Ein Kommentator fragte, welche Orchestrierung und welches Tooling man eigentlich von einem Hypervisor erwarte. Docker Compose, so das Argument, sei ein Feature auf Docker-Ebene, nicht auf Proxmox-Ebene. Unterschiedliche Schichten. Unterschiedliche Aufgaben. Das ist die konservative Position, und sie ist nicht falsch. Proxmox ist gut, weil es einen klaren Schwerpunkt hat: virtuelle Infrastruktur. Wenn es versucht, gleichzeitig Docker Compose, Portainer, Kubernetes-lite und Hypervisor zu sein, könnte die Plattform schnell unübersichtlich werden.
Trotzdem liegt die andere Seite auch nicht falsch. Die Welt hat sich verändert. Für viele Nutzer umfasst „Infrastruktur" mittlerweile OCI-Container, ob es Hypervisor-Puristen gefällt oder nicht. Wenn die Hälfte der Nutzerbasis Docker in LXCs laufen lässt, ist das ein Signal. Das heißt nicht zwingend, dass Proxmox das Docker-Tooling komplett kopieren sollte, aber es bedeutet, dass der aktuelle Workaround verbreitet genug geworden ist, um Aufmerksamkeit zu verdienen.
Die interessanteste Antwort liegt wahrscheinlich irgendwo in der Mitte. Proxmox muss kein App Store werden. Es kann aber auch nicht so tun, als wären OCI-Workloads egal. Der Trick liegt darin, die Proxmox-typische Version von OCI-Support zu finden: integriert genug, um sich erstklassig anzufühlen, zurückhaltend genug, um die Plattform nicht in einen verwirrten Haufen konkurrierender Abstraktionen zu verwandeln.
Proxmox-Nutzer wollen Power, aber sie sind es leid, bestraft zu werden
Das klarste Thema in der Release-Diskussion war nicht Faulheit. Es war Erschöpfung. Die Leute sind bereit zu lernen. Sie sind bereit, Configs zu bearbeiten. Sie sind bereit, Docs zu lesen, Backups zu testen, Container neu aufzusetzen, UIDs zu mappen und öffentlich über Storage-Semantik zu streiten. Das ist keine Gruppe, die Angst vor Komplexität hat. Aber sie ist es leid, Komplexität zu ertragen, die sich unnötig anfühlt.
Es gibt einen Unterschied zwischen Power und Bestrafung. Power bedeutet, Container-Nutzer sicher auf Host-Storage mappen zu können. Bestrafung bedeutet, zehn zerbrechliche lxc.idmap-Zeilen und ein perfektes Verständnis von untergeordneten ID-Bereichen zu brauchen, nur um einem Dienst Zugriff auf einen Ordner zu geben. Power bedeutet, unprivilegierte Container mit geteilten Datasets zu betreiben. Bestrafung bedeutet, aufzugeben und 777 zu nutzen, weil sich jede sichere Option wie eine Falle anfühlt. Power bedeutet, entscheiden zu können, ob ein Workload in eine VM, ein LXC oder einen OCI-Container gehört. Bestrafung bedeutet, Tools zu verschachteln, weil die Plattform den Workflow noch nicht ganz abdeckt.
Deshalb fühlt sich 9.2 wie Fortschritt an, auch wenn es nicht alles löst. Die besten Infrastruktur-Verbesserungen fügen nicht immer ein brandneues Spielzeug hinzu. Manchmal nehmen sie einfach einen Grund weg, warum Leute etwas Riskantes taten. Wenn einfacheres UID-Mapping mehr Nutzern hilft, unprivilegierte statt privilegierte Container zu wählen, ist das eine Sicherheitsverbesserung, verpackt als Komfort. Wenn die UI den Storage-Zugriff verständlicher macht, ist das keine Verdummung. Das ist der Abbau unnötiger Reibung.
Ein paar Leute im Thread sagten im Grunde: „Dieses winzige Ding macht mich glücklich, und vielleicht ist das traurig." Das ist nicht traurig. Es ist genau das, was ausgereifte Software tun sollte. Sie sollte die schmerzhaften Dinge, über die Nutzer immer wieder stolpern, weniger schmerzhaft machen, ohne den Leuten, die sie brauchen, die echte Mechanik zu verstecken.
Das Release zeigt, wie Proxmox in eine schwierigere Rolle hineinwächst
Proxmox hat jetzt eine knifflige Aufgabe. Es muss der Person mit einem einzelnen Mini-PC ebenso dienen wie der Person, die einen VMware-Ersatz evaluiert. Es muss Einsteigern helfen, ohne Experten zu beleidigen. Es muss Features hinzufügen, ohne aufgebläht zu werden. Es muss alte Schmerzpunkte glätten, ohne zu einer glänzenden Appliance zu werden, die zu viel versteckt. Das ist eine schwierige Balance, und 9.2 zeigt beide Seiten davon.
Die Begeisterung rund um UID- und GID-Mapping beweist, dass Nutzer es lieben, wenn Proxmox Komplexität auf verantwortungsvolle Weise in die UI zieht. Die OCI-Debatte beweist, dass Nutzer weiter nach mehr fragen werden, manchmal deutlich mehr. Die 777-Witze beweisen, dass Leute weiterhin Fluchtwege brauchen, weil echte Systeme unordentlich werden. Die Kommentare zur Portabilität beweisen, dass die Community über „heute Abend zum Laufen bringen" hinaus denkt, hin zu „werde ich dieses Setup später hassen?".
Das ist die eigentliche Geschichte von Proxmox 9.2. Nicht nur ein Release. Ein Zeichen dafür, dass eine Plattform von ihrem eigenen Erfolg nach oben gezogen wird. Nutzer vertrauen ihr mehr an, also erwarten sie mehr. Sie bauen größere Setups, also schmerzen die rauen Kanten mehr. Sie nähern sich Produktionsgewohnheiten an, also beginnen sich die alten Homelab-Abkürzungen peinlich anzufühlen. Sie wollen Enterprise-Features, aber sie wollen trotzdem, dass sich die Plattform zugänglich genug anfühlt, damit ein Wochenend-Admin sie übersteht.
Proxmox 9.2 beendet nicht die Debatte darüber, was Proxmox werden sollte. Es schärft sie. Die Plattform kann fokussiert auf virtuelle Infrastruktur bleiben und trotzdem Container weniger schmerzhaft machen. Sie kann die UI verbessern, ohne jedes fortgeschrittene Feature zu einem Spielzeug zu machen. Sie kann die Shell-Fraktion respektieren und normale Menschen trotzdem vor Config-Datei-Turnübungen retten.
Das größte Kompliment für 9.2 ist, dass die Leute sofort anfingen, sich auszumalen, was als Nächstes kommt. Das bedeutet, das Release hat funktioniert. Es hat einen hässlichen Teil des Systems menschlicher wirken lassen, und sobald Nutzer das einmal gekostet haben, wollen sie es überall.