Storage

Pools (Proxmox)

Pool	Type	Use
local	directory	ISOs, misc
main / local-lvm	LVM	guest disks
backups	dir on vg0/backups LV (/mnt/backups)	vzdump guest backups — see “Backup state”
storagebox	CIFS (Hetzner Storage Box)	bulk/media data only (backups moved off 2026-09)

Source of truth on the host: /etc/pve/storage.cfg.

Hetzner Storage Box

Configured at the datacenter level (not per-VM) via the Proxmox storage UI.

cifs: storagebox
    path /mnt/pve/storagebox
    server «SB_HOST»
    share backup
    content backup
    prune-backups keep-all=1
    username «SB_USER»
    options uid=0,gid=0,file_mode=0777,dir_mode=0777

Notes:

• The options line was added manually to /etc/pve/storage.cfg after creating the storage via the UI.
• Proxmox mounts it at /mnt/pve/storagebox.
• Treated as durable storage — Hetzner runs the Storage Box on multi-drive-fault-tolerant RAID (see decisions for the caveat: it’s still a single provider/failure domain).
• Never store the Storage Box password or any secrets in this repo.

Exposing it to guests

LXC — bind mount

In /etc/pve/lxc/<vmid>.conf:

mp0: /mnt/pve/storagebox,mp=/mnt/storagebox

QEMU — virtiofs

PVE 9 / QEMU 11 hazard

virtiofs + OVMF firmware deadloops at boot on PVE 9 — QEMU 108 hung in the VirtioFs DXE driver after the 8→9 upgrade; fix was removing virtiofs0. SeaBIOS guests (devvm) are unaffected — SeaBIOS has no virtiofs driver. Prefer mp0 bind mounts (LXC) or a guest-side mount for new work. Incident: 2026-10-08-ovmf-virtiofs-deadloop.

Directory mapping in the Proxmox UI — stored in /etc/pve/mapping/directory.cfg (dir: storageboxmapping, path + security model live there); the mapping name is the mount tag. In /etc/pve/qemu-server/<vmid>.conf:

virtiofs0: storageboxmapping

Guest /etc/fstab — tag must match the mapping name; nofail + automount keep a wedged/slow share from blocking boot:

storageboxmapping /mnt/storagebox virtiofs rw,relatime,nofail,x-systemd.automount 0 0

Only devvm (112) still consumes this — it runs SeaBIOS, which ignores the device. Prefer a bind mount (LXC) for anything new.

Verified 2026-09: CIFS hardlinks work on this mount; files mid-copy return EINVAL on read until the writer closes.

Live mount options (observed 2026-10-03 via findmnt): vers=3.1.1,cache=strict,soft,nounix,serverino,mapposix,actimeo=1, closetimeo=1.

open handles poison alternate names

While a process holds a file open write-mode, opens via the file’s other names (hardlinks, renamed paths) fail with EINVAL until the handle dies. virtiofsd caches backing fds past guest close — only daemon death/dismount releases.

session drops hang, they don't error

A dropped session (observed 2026-10-01 during Hetzner’s planned Storage Box maintenance — CIFS: VFS: ... Error -32 in host dmesg) wedges virtiofs consumers until the server returns and CIFS reconnects. The mount is soft (see options above) — errors surface on timeout rather than hanging strictly forever, but the window is still long enough to take consumers down.

exposure

The Storage Box is publicly reachable (SSH/SFTP/CIFS on the internet, password-only auth). It now holds only media artifacts — nothing sensitive — but a protocol audit is still worthwhile (TODO). Guest backups moved off it 2026-09.

Backup state

Guest backups live on backups — a dedicated thick LV on vg0 (~180G, mounted /mnt/backups, PVE storage type dir, content backup), carved from space freed (256G → 32G, 2026-09). Fresh vzdump backups of all guests were taken 2026-09-29 — total footprint ~19G compressed, so even keep-last-5 retention barely moves the needle on 180G; the old dumps/ copies on the Storage Box were deleted.

• Caveat: same-RAID1 backups. They cover rollback/config loss, not disk failure — no true DR copy exists. The fix is planned: encrypted offsite sync (restic/borg), destination retargetable — see decisions.
• Scheduled via two Datacenter → Backup jobs (added 2026-09): pool lxc-suspend (LXCs, suspend mode — thick LVM can’t snapshot) and pool vm-snapshot (QEMU guests, live snapshot mode — fine on any storage). Mon+Thu 04:00 / 04:15 node-local, storage backups, keep-last=5. New guests get coverage by joining the right pool — no job edits needed.
• DR expectation: rebuild from this vault + restore from backups. See disaster-recovery.