lxc.mount.entry vs. mpX bei unprivilegierten Containern

#proxmox #lxc

Wenn man sich im Proxmox-Wiki den Artikel zu Unprivileged LXC containers durchliest, wird dort nur eine Art von Mountpoints erwähnt, und zwar:

TEXT 
mp[0-9]+: <volume>,mp=<container-path>[,<option>=<value>...]

Es gibt jedoch eine viel bessere Wahl, wenn man Mounts in LXC-Containern definieren will und viel mehr Optionen haben will als bei mpX.

Der Befehl heißt lxc.mount.entry:

TEXT 
lxc.mount.entry: <source> <target> <fstype> <options> <dump> <pass>

Vorteile von lxc.mount.entry sind zum Beispiel:

  • Rekursive Mounts (rbind) – verschachtelte Mountpoints (z. B. nested ZFS-Datasets) werden automatisch mitgemountet; bei mpX fehlt diese Option komplett
  • Volle fstab-Optionsvielfalt – beliebige Mount-Optionen nutzbar (z. B. ro, noexec, nosuid, spezielle Dateisystem-Flags), nicht nur der begrenzte Satz, den Proxmox für mpX vorsieht
  • Beliebige Quelltypen – nicht nur lokale Pfade/Proxmox-Storages, sondern z. B. auch NFS-, CIFS- oder andere bereits gemountete Freigaben lassen sich direkt einbinden
  • Kein Storage-Zwang – der Host-Pfad muss kein von Proxmox verwaltetes Storage-Objekt sein; funktioniert mit jedem beliebigen Verzeichnis
  • Mehr Kontrolle über create=dir/create=file – Zielverzeichnis/-datei kann bei Bedarf automatisch angelegt werden, feingranularer steuerbar als bei mpX

Es gibt jedoch auch Nachteile gegenüber mpX, die berücksichtigt werden müssen:

  • Kein GUI-Support (nur manuelle Config-Bearbeitung)
  • Kein automatisches Backup-Handling über vzdump wie bei mpX (backup=0/1)
  • Kein Storage-Tracking / keine automatische Berücksichtigung bei Live-Migration (Host-Pfad muss auf Zielnode identisch existieren)
  • Keine Validierung beim Speichern – Fehler fallen erst beim Containerstart auf

Weitere Infos gibt’s hier

Zum Anfang ↑