Het grote Proxmox VE topic

[dcm360]

De meest logische reden waardoor dit kan afwijken, is doordat de VM vrijgekomen ruimte niet teruggeeft. Bij de eigenschappen van de virtuele schijf in Proxmox moet 'Discard' aan staan, en de VM moet TRIM/Discard-commando's naar de virtuele schijf sturen. Met die combinatie zou de ruimte als het goed is wel weer moeten kunnen afnemen.

[ge-flopt]

@Luchtenburger Ik ben fan van "df -m / -max-depth=1" en van daaruit verder kijken. Dit geeft per directory aan hoeveel diskruimte er in gebruik is. Als de diskruimte afwijkt met wat je verwacht ga je verder kijken in die directory.

[RudolfR]

@Luchtenburger

Bij mij zijn snapshots van de HA VM wel eens het probleem geweest. Heeft me moeite gekost om die diagnose te stellen toen.

[GoBieN-Be]

du formatted and sorted

code:

alias duf='du -sk * | sort -n | while read size fname; do for unit in k M G T P E Z Y; do if [ $size -lt 1024 ]; then echo -e "${size}${unit}\t${fname}"; break; fi; size=$((size/1024)); done; done'

duf

[ Voor 5% gewijzigd door GoBieN-Be op 11-02-2026 23:10 ]

[Cardinal]

@Luchtenburger de laatste keer dat mij dat overkwam had ik tig kernels over tijd verzameld.
Hoe lang draait dit al en hoevaak ruim je op?

code:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/tools/pve/kernel-clean.sh)"

[Luchtenburger]

Hartelijk dank voor de tips over het vol lopen van mijn LVM-thin disk.
Ik ben niet super handig met het proxmox systeem, ik moet deze informatie dus even rustig analyseren om te zien hoe dit mij kan helpen.

Ik heb in het verleden ook al eens problemen gehad dat ik te veel snapshots maakte waardoor de schijf vol liep, er staan nu geen snapshots op.

De VM draait al een aantal jaren, maar ik weet niet eens zo goed hoe lang (3 jaar? 5 jaar?). Ik ruim dit nooit op. Het systeem draait super stabiel, dus ik kijk er eigenlijk nooit naar.
Onlangs kwam ik erachter dat ik nog op proxmox versie 7 draaide en had ik al problemen om dit te upgraden. Met hulp van hier is dat intussen gelukt.
Daarna ben ik eens beter naar het systeem gaan kijken en zag ik dat de schijf aardig vol zat.

[Airw0lf]

Luchtenburger schreef op donderdag 12 februari 2026 @ 07:21:
Hartelijk dank voor de tips over het vol lopen van mijn LVM-thin disk.
Ik ben niet super handig met het proxmox systeem, ik moet deze informatie dus even rustig analyseren om te zien hoe dit mij kan helpen.

Ik heb in het verleden ook al eens problemen gehad dat ik te veel snapshots maakte waardoor de schijf vol liep, er staan nu geen snapshots op.

De VM draait al een aantal jaren, maar ik weet niet eens zo goed hoe lang (3 jaar? 5 jaar?). Ik ruim dit nooit op. Het systeem draait super stabiel, dus ik kijk er eigenlijk nooit naar.
Onlangs kwam ik erachter dat ik nog op proxmox versie 7 draaide en had ik al problemen om dit te upgraden. Met hulp van hier is dat intussen gelukt.
Daarna ben ik eens beter naar het systeem gaan kijken en zag ik dat de schijf aardig vol zat.

In jouw geval lijkt me Thick-LVM veel handiger - je hebt dan tenminste zicht op de echte allocatie van diskruimte waardoor de kans op verrassingen aanzienlijk afneemt.

Zo heb ik het nu in ieder geval wel draaien - aangevuld met cronjobs die wekelijks een update/upgrade uitvoeren in de nacht van vrijdag op zaterdag. Zijn er zaterdagochtend geen mails binnengekomen over deze jobs en zijn resultaten, dan is het ergens gruwelijk fout gelopen en moet ik aan de bak!

[Luchtenburger]

Thick-LVM zou voor mijn inderdaad wel geschikt zijn denk ik gezien ik maar één VM draai.

Ik heb echter de info van @dcm360 eens goed uitgezocht.
"Discard" stond inderdaad niet aan voor de harddisk van de VM, dus die heb ik aangezet.
Daarna zou de ruimte 'een keer' vrijgegeven moeten worden, maar daar heb ik het geduld niet echt voor.
Dus ik heb het volgende commando in de shell van de node uitgevoerd:

code:

qm guest exec VMIDHERE -- fstrim -a

(hierbij VMIDHERE uiteraard vervangen door de ID van de VM)

Na enige tijd was dit commando succesvol voltooid, op mijn VM-Thin disk wordt nu nog slechts 23.14 GB van de 73.54 GB gebruikt (31%).

Ik kan dus voorlopig weer vooruit, geen reden om de boel om te zetten naar LVM-Thick.

Allen hartelijk dank voor het meedenken !

[ElCondor]

Een vraag, en wellicht is dit al voorbij gekomen, maar ik kon het niet in dit topic vinden.
Ik heb een container waar behoorlijk wat docker containers op draaien (dus docker in een lcx-ception).
Deze lxc is een unprivileged container. Om wat zaken goed in te regelen wilde ik nfs-mounts gaan gebruiken. Daarvoor moet de container echter privileged zijn. Dus, container uit, backup, restore => privileged = true, container aan. Maar dan, geen van de docker containers wil starten. Ik VERMOED, iets met rechten, maar kan er zo even niet achter komen wat precies. Wel gegoogled, maar kan niet echt een oplossing opduikelen. De docker containers komen niet eens tevoorschijn met een docker ps. En docker run <container> geeft de foutmelding dat de container niet gestart kan worden ivm rechten. De container verwijderen en opnieuw maken geeft de melding dat de container niet gestart kan worden omdat het image niet gevonden kan worden of omdat er rechten nodig zijn om het image te downloaden of het image bestaat niet.
Uiteindelijk een roll-back moeten doen (Whoehoe voor PBS) en dan start alles wel.

Heeft iemand een tip de goede richting in?

[Luchtenburger]

In aanvulling op mijn probleem met het vol lopen van de LVM-thin pool, ik heb nu een script aangemaakt (naja... ChatGTP heeft dat grotendeels voor mij gedaan ) die een email stuurt zodra de LVM-thin pool voor meer dan 75% vol zit.

Code van het script:

code:

#!/bin/bash

# === Instellingen ===
THRESHOLD=75                     # Drempel in procenten
VG_NAME="pve"                    # Volume group naam
POOL_NAME="data"                 # Thin pool naam
EMAIL="[e-mail]"        # Ontvanger
HOSTNAME=$(hostname)

# === Huidig gebruik ophalen ===
USAGE=$(/usr/sbin/lvs --noheadings -o data_percent ${VG_NAME}/${POOL_NAME} 2>/dev/null | tr -d ' ')

# Controle of waarde geldig is
if [[ -z "$USAGE" ]]; then
    echo "Kon LVM-thin gebruik niet uitlezen."
    exit 1
fi

# Afronden naar integer
USAGE_INT=${USAGE%.*}

# === Vergelijken met drempel ===
if (( USAGE_INT >= THRESHOLD )); then
    SUBJECT="ALERT: LVM-thin ${VG_NAME}/${POOL_NAME} op ${HOSTNAME} is ${USAGE_INT}% vol"
    MESSAGE="Het LVM-thin volume ${VG_NAME}/${POOL_NAME} op ${HOSTNAME} is ${USAGE_INT}% gebruikt. Drempel is ${THRESHOLD}%."

    echo "$MESSAGE" | mail -s "$SUBJECT" "$EMAIL"
fi

Locatie van dit script en het commando om deze uitvoerbaar te maken:

code:

/usr/local/sbin/
chmod +x /usr/local/sbin/check_lvmthin.sh

En tenslotte met crontab zorgen dat dit script elke 10 minuten uitgevoerd wordt:
Commando voor crontab:

code:

crontab -e

Regel die hier toegevoegd moet worden:

code:

*/10 * * * * /usr/local/sbin/check_lvmthin.sh

Het moet uiteraard wel mogelijk zijn om emails vanuit proxmox te versturen, daar zijn weer andere handleidingen voor op internet te vinden

[Jerie]

Luchtenburger schreef op donderdag 12 februari 2026 @ 07:21:

[..]

De VM draait al een aantal jaren, maar ik weet niet eens zo goed hoe lang (3 jaar? 5 jaar?). Ik ruim dit nooit op. Het systeem draait super stabiel, dus ik kijk er eigenlijk nooit naar.

[..]

Iets zegt me dat je dat bovenstaande script niet iedere 10 minuten hoeft uit te voeren. Eens per week of maand volstaat.

[Quad]

Luchtenburger schreef op zaterdag 14 februari 2026 @ 10:10:
In aanvulling op mijn probleem met het vol lopen van de LVM-thin pool, ik heb nu een script aangemaakt (naja... ChatGTP heeft dat grotendeels voor mij gedaan ) die een email stuurt zodra de LVM-thin pool voor meer dan 75% vol zit.

Code van het script:

code:

#!/bin/bash

# === Instellingen ===
THRESHOLD=75                     # Drempel in procenten
VG_NAME="pve"                    # Volume group naam
POOL_NAME="data"                 # Thin pool naam
EMAIL="[e-mail]"        # Ontvanger
HOSTNAME=$(hostname)

# === Huidig gebruik ophalen ===
USAGE=$(/usr/sbin/lvs --noheadings -o data_percent ${VG_NAME}/${POOL_NAME} 2>/dev/null | tr -d ' ')

# Controle of waarde geldig is
if [[ -z "$USAGE" ]]; then
    echo "Kon LVM-thin gebruik niet uitlezen."
    exit 1
fi

# Afronden naar integer
USAGE_INT=${USAGE%.*}

# === Vergelijken met drempel ===
if (( USAGE_INT >= THRESHOLD )); then
    SUBJECT="ALERT: LVM-thin ${VG_NAME}/${POOL_NAME} op ${HOSTNAME} is ${USAGE_INT}% vol"
    MESSAGE="Het LVM-thin volume ${VG_NAME}/${POOL_NAME} op ${HOSTNAME} is ${USAGE_INT}% gebruikt. Drempel is ${THRESHOLD}%."

    echo "$MESSAGE" | mail -s "$SUBJECT" "$EMAIL"
fi

Locatie van dit script en het commando om deze uitvoerbaar te maken:

code:

/usr/local/sbin/
chmod +x /usr/local/sbin/check_lvmthin.sh

En tenslotte met crontab zorgen dat dit script elke 10 minuten uitgevoerd wordt:
Commando voor crontab:

code:

crontab -e

Regel die hier toegevoegd moet worden:

code:

*/10 * * * * /usr/local/sbin/check_lvmthin.sh

Het moet uiteraard wel mogelijk zijn om emails vanuit proxmox te versturen, daar zijn weer andere handleidingen voor op internet te vinden

Waarom niet in Home Assistant PVE toevoegen, zodat je naast het volume, ook andere zaken kan monitoren? Krijg je geen mail, maar met Signal, HA push of Telegram wel notificaties.

[Luchtenburger]

Jerie schreef op zaterdag 14 februari 2026 @ 10:34:
[...]


Iets zegt me dat je dat bovenstaande script niet iedere 10 minuten hoeft uit te voeren. Eens per week of maand volstaat.

Ik vraag mij ook inderdaad af of dit overkill is. Als ik niet thuis ben en de LVM-thin pool loopt nu vol, dan krijg ik elke 10 minuten een email, wat ik op dat moment niet uit kan zetten.... Ik weet niet of dat echt handig is.

Quad schreef op zaterdag 14 februari 2026 @ 10:46:
[...]

Waarom niet in Home Assistant PVE toevoegen, zodat je naast het volume, ook andere zaken kan monitoren? Krijg je geen mail, maar met Signal, HA push of Telegram wel notificaties.

Tja, dat kan wellicht ook. Dit volstaat voor mij momenteel.

[Anoniemand]

ElCondor schreef op vrijdag 13 februari 2026 @ 21:49:
Een vraag, en wellicht is dit al voorbij gekomen, maar ik kon het niet in dit topic vinden.
Ik heb een container waar behoorlijk wat docker containers op draaien (dus docker in een lcx-ception).
Deze lxc is een unprivileged container. Om wat zaken goed in te regelen wilde ik nfs-mounts gaan gebruiken. Daarvoor moet de container echter privileged zijn. Dus, container uit, backup, restore => privileged = true, container aan. Maar dan, geen van de docker containers wil starten. Ik VERMOED, iets met rechten, maar kan er zo even niet achter komen wat precies. Wel gegoogled, maar kan niet echt een oplossing opduikelen. De docker containers komen niet eens tevoorschijn met een docker ps. En docker run <container> geeft de foutmelding dat de container niet gestart kan worden ivm rechten. De container verwijderen en opnieuw maken geeft de melding dat de container niet gestart kan worden omdat het image niet gevonden kan worden of omdat er rechten nodig zijn om het image te downloaden of het image bestaat niet.
Uiteindelijk een roll-back moeten doen (Whoehoe voor PBS) en dan start alles wel.

Heeft iemand een tip de goede richting in?

Dat lijkt inderdaad een rechten dingetje te zijn. Het zal hier eerder al besproken zijn, ik vind deze site het wel uitgebreid toelichten. Ik heb hem even snel doorgebladerd, maar het lijkt ook prima uit te leggen hoe je je container privilaged kan houden (meer secure) en toch een mount erop kan krijgen.

[ElCondor]

Anoniemand schreef op zaterdag 14 februari 2026 @ 11:43:
[...]

Dat lijkt inderdaad een rechten dingetje te zijn. Het zal hier eerder al besproken zijn, ik vind deze site het wel uitgebreid toelichten. Ik heb hem even snel doorgebladerd, maar het lijkt ook prima uit te leggen hoe je je container privilaged kan houden (meer secure) en toch een mount erop kan krijgen.

Thx, ik zal eens kijken. Zal vandeweek zijn, ben ik bang
Even snel gescant en dit ziet er best duidelijk uit. Ook weer veel te leren, moet ik zeggen.

[ Voor 7% gewijzigd door ElCondor op 14-02-2026 15:51 ]

[ElCondor]

ElCondor schreef op zaterdag 14 februari 2026 @ 15:44:
[...]

Thx, ik zal eens kijken. Zal vandeweek zijn, ben ik bang
Even snel gescant en dit ziet er best duidelijk uit. Ook weer veel te leren, moet ik zeggen.

Nou, vanavond hier eens mee aan de slag gegaan. Een beetje vreemd alleen, want de procedure die in de link wordt beschreven gaat er juist van uit dat de container unprivileged moet blijven en dan user ID's doormapt naar resources op de host.
Dat is niet helemaal mijn wens.
Wat ik wil is juist de container privileged maken om gebruik te kunnen maken van nfs-mounting IN de container: 'sudo mount -a' geeft nu een 'mount: permission denied (are you root?)' foutmelding. Dit komt omdat de container unprivileged is.
Als ik echter de container omzet naar privileged dan werkt docker opeens niet meer. Vermoedelijk omdat de docker root folder niet de juiste ownership meer heeft.
Ik heb na privileged restore geprobeerd om de docker root folder via de HOST prompt te chownen naar id 100000:100000 (root in de container) maar dan nog wil docker geen enkele container starten. En dat terwijl de user ID's vóór het omzetten naar privileged voor de docker root folder wel degelijk user:group 100000:100000 hebben.
Dus wat doe ik dan verkeerd?

Ok, andere manier wellicht. Ik heb ook gezien dat je een NFS share op de host kunt mounten en die dan als mountpoint aan de container door kunt mappen. Dat dient echter ook niet mijn use-case, want ik wil de container wel kunnen laten migreren naar een andere host. Dan zou ik de nfs-mount op al mijn hosts los aan moeten maken? Of is hier een andere manier voor om dit voor elkaar te krijgen?

Anders zit er denk ik niets anders op, om dan maar de docker host container te verwijderen en van scratch te beginnen met een VM. Dan ben ik vrij om te doen en te laten wat ik wil, Echter draait er nu authentik en paperless op de betreffende docker instance en die opnieuw optuigen is ook weer gedoe.
Wat een gedoe

Iemand nog tips over hoe dit het best aan te vliegen?

[Liegebeest]

@ElCondor de klassieke manier, die je ook bij Kubernetes clusters ziet, is de NFS share idd meegeven als mount. Zeker niet met NFS rommelen in de container. En ook niet met de hand op de host mounten. Laat de container runtime het zware werk voor je doen.

Je doet t met Docker Compose. Bijv:

code:

# Source - https://stackoverflow.com/a/46481637
# Posted by xrobau, modified by community. See post 'Timeline' for change history
# Retrieved 2026-02-17, License - CC BY-SA 4.0
version: "3.2"

services:
  rsyslog:
    image: jumanjiman/rsyslog
    ports:
      - "514:514"
      - "514:514/udp"
    volumes:
      - type: volume
        source: example
        target: /nfs
        volume:
          nocopy: true
volumes:
  example:
    driver_opts:
      type: "nfs"
      o: "addr=10.40.0.199,nolock,soft,rw"
      device: ":/docker/example"

[ElCondor]

@Liegebeest een hele goeie, als het gaat om data IN containers beschikbaar maken, maar dat is ook net niet mijn usecase.
Wat ik wil is een centrale plek waarnaar ik docker containers/composefiles en dat soort zaken naar toe kan publishen en daarmee live zetten.
Dus de nsf share die ik daarvoor op het oog heb moet op de docker hosts beschikbaar komen.

Mijn idee is dus dat ik een centrale plek heb waar ik de docker configuratie heb staan waar de docker instances hun configuratie vandaan trekken.
Daarmee hoef ik bij release van een nieuwe compose niet naar een specifieke docker host toe te publishen, maar kan ik publishen naar de NFS share en daarmee hebben alle docker hosts beschikking over de nieuwe configuratie. Redploy van de betreffende containers of stacks en klaar is kees.

Maar als dit niet de geëigende weg is, dan hoor ik graag hoe dit beter in te richten.

Het idee is om per docker host de volgende folder structuur te maken waarbij binds een mounted folder is die dus vanaf een nfs share ontsloten wordt. <dockerhost> kunnen dus meerdere folders zijn, 1 folder per host waarbinnen de config en binds te vinden zijn.

Markdown:

mnt/
|
L_dockerdata/ #mounted
  |
  L_docker/
  |  |
  |  L_volumes/
  |
  L_binds/ #mounted
  | |
  | L_<dockerhost>
  |   |
  |   L_<container_bind_data>
  |
  L_<container_source_data> #mounted

De gehele folder dockerdata is nu al op een aantal hosts al gemount, zodat deze centraal gehost zijn.
Dit lukt op waar de dockerhosts VM's zijn, maar niet waar de dockerhost een lxc container is.

[Cyphax]

ElCondor schreef op dinsdag 17 februari 2026 @ 08:16:
@Liegebeest een hele goeie, als het gaat om data IN containers beschikbaar maken, maar dat is ook net niet mijn usecase.
Wat ik wil is een centrale plek waarnaar ik docker containers/composefiles en dat soort zaken naar toe kan publishen en daarmee live zetten.
Dus de nsf share die ik daarvoor op het oog heb moet op de docker hosts beschikbaar komen.

Mijn idee is dus dat ik een centrale plek heb waar ik de docker configuratie heb staan waar de docker instances hun configuratie vandaan trekken.
Daarmee hoef ik bij release van een nieuwe compose niet naar een specifieke docker host toe te publishen, maar kan ik publishen naar de NFS share en daarmee hebben alle docker hosts beschikking over de nieuwe configuratie. Redploy van de betreffende contiainers of stacks en klaar is kees.

Maar als dit niet de geëigende weg is, dan hoor ik graag hoe dit beter in te richten.

Het idee is om per docker host de volgende folder structuur te maken waarbij binds een mounted folder is die dus vanaf een nfs share ontsloten wordt. <dockerhost> kunnen dus meerdere folders zijn, 1 folder per host waarbinnen de config en binds te vinden zijn.

Markdown:

mnt/
|
L_dockerdata/ #mounted
  |
  L_docker/
  |  |
  |  L_volumes/
  |
  L_binds/ #mounted
  | |
  | L_<dockerhost>
  |   |
  |   L_<container_bind_data>
  |
  L_<container_source_data> #mounted

De gehele folder dockerdata is nu al op een aantal hosts al gemount, zodat deze centraal gehost zijn.
Dit lukt op waar de dockerhosts VM's zijn, maar niet waar de dockerhost een lxc container is.

Komt de share uit op de proxmox-machine zelf, of is dat een ander apparaat als een NAS ofzo?

[ElCondor]

Cyphax schreef op dinsdag 17 februari 2026 @ 08:34:
[...]

Komt de share uit op de proxmox-machine zelf, of is dat een ander apparaat als een NAS ofzo?

Dat is een NAS inderdaad.

[Liegebeest]

Wat ik wil is een centrale plek waarnaar ik docker containers/composefiles en dat soort zaken naar toe kan publishen en daarmee live zetten.

De oplossing die jij zoekt heet een container image registry (of repository) en Git. En runtime configuraties doe je via environment variables van de container runtime, niet hard coded.

Waarom probeer je een probleem dat is opgelost houtje touwtje met NFS op te lossen?!

[ Voor 12% gewijzigd door Liegebeest op 17-02-2026 08:46 ]

[Cyphax]

ElCondor schreef op dinsdag 17 februari 2026 @ 08:40:
[...]

Dat is een NAS inderdaad.

Wat ik doe met dit soort situaties is de share mounten op de host en dan dat pad doorgeven via een bind mount. Dan hoeft je container helemaal geen sjoege te hebben van nfs of samba of wat dan ook.

Voor containers en opslag van compose files is het misschien interessant om gitea of forgejo eens te bekijken. Die bieden git (voor de compose files) en een repository voor docker containers. :)

[ElCondor]

Over-engineered dus.
Dat is ook een mogelijkheid. Ik zal eens kijken op welke manier ik docker rechtstreeks uit een git repo kan laten trekken. Mijn stacks etc push ik al naar een lokale git, vooral vanwege version control, niet om te publishen naar productie, maar het publishen naar de docker hosts toe (of dit nu VM's zijn of LXC containers), dat heb ik nog niet als zodanig bekeken.

Cyphax schreef op dinsdag 17 februari 2026 @ 08:48:
[...]

Wat ik doe met dit soort situaties is de share mounten op de host en dan dat pad doorgeven via een bind mount. Dan hoeft je container helemaal geen sjoege te hebben van nfs of samba of wat dan ook.
...

Dat share mounten op een host is dus precies wat ik wil, maar dat wil dus niet als de docker host een unprivileged LXC container is. Dus kip-ei verhaal.
Maar misschien moet ik het dus helemaal anders aanvliegen en de docker hosts direct uit een git repo laten trekken. Ik zal me daar eens in verdiepen.

[Liegebeest]

Container images stop je niet in Git, dat zijn “artifacts”. Die gaan naar een repository/registry. Die kan je zelf met heel weinig moeite opzetten.

[ElCondor]

Liegebeest schreef op dinsdag 17 februari 2026 @ 08:58:
Container images stop je niet in Git, dat zijn “artifacts”. Die gaan naar een repository/registry. Die kan je zelf met heel weinig moeite opzetten.

Ik denk dat we op dezelfde lijn zitten hoor. Images wil ik ook niet storen, het gaat me puur om de compose files en eventuele persistente configuratie files/binds. De bedoeling is dat die niet direct op de dockerhosts leven, maar op een plek die vanuit alle docker hosts bereikbaar is. Dit om te voorkomen dat als een docker host stuk gaat, ik een nieuwe host in de benen kan helpen en deze direct de stacks kan starten.
Maar de compose files vanuit een git repo trekken zou ook een oplossing kunnen zijn.

Ik ga er eens op studeren.

[Cyphax]

ElCondor schreef op dinsdag 17 februari 2026 @ 08:57:
Dat share mounten op een host is dus precies wat ik wil, maar dat wil dus niet als de docker host een unprivileged LXC container is. Dus kip-ei verhaal.
Maar misschien moet ik het dus helemaal anders aanvliegen en de docker hosts direct uit een git repo laten trekken. Ik zal me daar eens in verdiepen.

Ik bedoel dat je de share niet op de docker-host mount maar op de proxmox-machine, en dan geef je dat pad door aan de docker-host die vervolgens zelf weer dat pad kan gebruiken om door te geven aan containers.
Ik heb ook een container die als docker-host dient, die is ook gewoon unpriviliged.

[ Voor 63% gewijzigd door Cyphax op 17-02-2026 09:25 ]

[ElCondor]

Cyphax schreef op dinsdag 17 februari 2026 @ 09:23:
[...]

Ik bedoel dat je de share niet op de docker-host mount maar op de proxmox-machine, en dan geef je dat pad door aan de docker-host die vervolgens zelf weer dat pad kan gebruiken om door te geven aan containers.
Ik heb ook een container die als docker-host dient, die is ook gewoon unpriviliged.

Sorry, ik bedoelde mijn oplossing is over-engineered
-Hey, ninja-edit-

Maar, wat doe je dan als de LXC container moet gaan wandelen naar een andere ProMox node waar de betreffende share mogelijk niet gemount is? Of mount je die dan op ALLE PM-nodes?

[ Voor 17% gewijzigd door ElCondor op 17-02-2026 10:32 ]

[Liegebeest]

En daarom zeg ik: de mount moet nergens zijn behalve op de container zelf. Laat de container wanneer ie opstart de mount regelen. En ja, dan moet de NFS share openstaan voor de hel LXC IP reeks

[InjecTioN]

Liegebeest schreef op dinsdag 17 februari 2026 @ 11:31:
En daarom zeg ik: de mount moet nergens zijn behalve op de container zelf. Laat de container wanneer ie opstart de mount regelen. En ja, dan moet de NFS share openstaan voor de hel LXC IP reeks

Dat is exact de reden waarom ik het alsnog vanuit de container heb gedaan. Ik wil het simpelweg niet tot zover open laten staan. Daarbij is het m.i. echt counter intuïtief om de hypervisor toegang te verschaffen tot iets wat contained (en containerized) moet blijven.

[Liegebeest]

Ik bedoel, één van m’n klanten runt een Kubernetes cluster met twintig nodes en honderden containers. Natuurlijk moet de toegang tot opslag direct op de betrokken containers worden geregeld.

[Quad]

Liegebeest schreef op dinsdag 17 februari 2026 @ 12:10:
Ik bedoel, één van m’n klanten runt een Kubernetes cluster met twintig nodes en honderden containers. Natuurlijk moet de toegang tot opslag direct op de betrokken containers worden geregeld.

Met een unprivileged container kan dat niet, met een mount via docker zou het dus wel kunnen zeg je?

[Liegebeest]

Quad schreef op dinsdag 17 februari 2026 @ 14:00:
[...]

Met een unprivileged container kan dat niet, met een mount via docker zou het dus wel kunnen zeg je?

Correct, want dan zorgt de runtime dat je de directory binnen de container beschikbaar krijgt.

[ElCondor]

Liegebeest schreef op dinsdag 17 februari 2026 @ 14:28:
[...]

Correct, want dan zorgt de runtime dat je de directory binnen de container beschikbaar krijgt.

Poeh, zit nu op werk en ik moet even mijn hoofd er om heen krijgen op welke manier ik mijn structuur dan moet herzien. Maar je hebt een punt. Ik ga eens puzzelen als ik thuis ben.

Wellicht hoort dit meer in het docker topic thuis, maar wat gebruiken jullie om container data uit de container te halen als deze nog opgeslagen is in een docker volume? Ik heb nu een aantal containers draaien die al behoorlijk wat data bevatten (zoals authentik en paperless). Voor Paperless is er een db export functie, dat weet ik, maar is er zoiets ook voor authentik?

Allemaal in ieder geval bedankt voor het meedenken. Het geeft een hoop nieuwe inzichten.,

[Liegebeest]

Het punt is: die data had nooit in de container moeten staan. Dat had altijd al een externe volume moeten zijn. Hoe wil je anders dagelijks of wekelijks updaten naar de nieuwe image versie?

Ik heb ruim een half jaar aan e-mail data in mijn Mailcow instance. Elke dag wordt de hele container omgeving herbouwd en geüpgraded naar de nieuwste versie. De data staat allemaal op mounted volumes.

EDIT:
Ik zal eens uitproberen hoe Proxmox LXC hiermee om kan gaan in een cluster. Bij draait Mailcow via Docker in een VM die wordt gerepliceerd. Dat werkt natuurlijk anders.

[ Voor 79% gewijzigd door Liegebeest op 17-02-2026 16:02 ]

[ElCondor]

Liegebeest schreef op dinsdag 17 februari 2026 @ 15:48:
Het punt is: die data had nooit in de container moeten staan. Dat had altijd al een externe volume moeten zijn. Hoe wil je anders dagelijks of wekelijks updaten naar de nieuwe image versie?

Ik heb ruim een half jaar aan e-mail data in mijn Mailcow instance. Elke dag wordt de hele container omgeving herbouwd en geüpgraded naar de nieuwste versie. De data staat allemaal op mounted volumes.

EDIT:
Ik zal eens uitproberen hoe Proxmox LXC hiermee om kan gaan in een cluster. Bij draait Mailcow via Docker in een VM die wordt gerepliceerd. Dat werkt natuurlijk anders.

Check, daar kom ik nu dus ook achter. Vervelende is dat de generieke installatie instructie op het internet geeft je een compose waarin standaard volumes en binds worden genoemd en niemand (behalve jij) wijst me op de mogelijkheid om deze ook door middel van NFS te configureren. Dus al mijn volumes zitten in de docker/volumes folder. En dat had dus niet gemoeten, begrijp ik nu. Dus ik moet de compose files voor mijn stacks herzien en de persistente data dus laten landen op plekken waar hij onafhankelijk van de echte container kan blijven staan. Ik vrees inderdaad voor container upgrades, want ik heb al eens aan de hand gehad dat ik de portainer container geupgrade had en al mijn docker containers waren pleite.
Ook was mijn eerste docker install de snap versie van Ubuntu, eugh...
Allemaal dingen die je moet leren... Heeft me wat hoofdbrekens gekost om de snap docker te vervangen voor een reguliere docker install en alle containers/stacks nog te kunnen gebruiken.

[Liegebeest]

Quad schreef op dinsdag 17 februari 2026 @ 14:00:
[...]
Met een unprivileged container kan dat niet, met een mount via docker zou het dus wel kunnen zeg je?

Ik moet zelf even niet vergeten dat LXC containers en Docker containers fundamenteel anders werken. Met de eerste heb ik nauwelijks ervaring, met de tweede veel.

Met Docker, Docker Compose, Kubernetes, OpenShift enz is het heel simpel om een NFS share mee te geven als mounted volume wanneer de container start.

LXC onder Proxmox heeft daar niet 1-2-3 een optie voor in de menu's lijkt het.

[Liegebeest]

ElCondor schreef op dinsdag 17 februari 2026 @ 19:49:
[...]
Dus al mijn volumes zitten in de docker/volumes folder. En dat had dus niet gemoeten, begrijp ik nu. Dus ik moet de compose files voor mijn stacks herzien en de persistente data dus laten landen op plekken waar hij onafhankelijk van de echte container kan blijven staan.

Als het je gaat om een HA oplossing waarbij de container tussen nodes heen en weer kan en de data op NFS staat: dan ja, inderdaad.

De vraag is hoe dat met Proxmox gaat werken, want die runt geen Docker, toch? Je hebt het over "docker/volumes"... maar, waarop dan?

Ik heb dat opgelost door mijn Dockerized applicaties in een VM te runnen... en de VM is HA met Proxmox replication...

Ik vrees inderdaad voor container upgrades, want ik heb al eens aan de hand gehad dat ik de portainer container geupgrade had en al mijn docker containers waren pleite.

Euh... Run jij Docker binnen een LXC container?

[ElCondor]

Liegebeest schreef op dinsdag 17 februari 2026 @ 19:55:
[...]

...

De vraag is hoe dat met Proxmox gaat werken, want die runt geen Docker, toch? Je hebt het over "docker/volumes"... maar, waarop dan?

Ik heb dat opgelost door mijn Dockerized applicaties in een VM te runnen... en de VM is HA met Proxmox replication...

Daar heb ik er ook een van, een VM met docker, that is. Alles draait dus op ProxMox en om de boel lightweight te houden dacht ik een LXC met docker te gaan gebruiken. Toen nog onwetend over de beperkignen en zo die ik gaandeweg tegen zou gaan komen.

[...]

Euh... Run jij Docker binnen een LXC container?

Zie mijn eerste post in deze hele discussie:

ElCondor schreef op vrijdag 13 februari 2026 @ 21:49:
Een vraag, en wellicht is dit al voorbij gekomen, maar ik kon het niet in dit topic vinden.
Ik heb een LXC container waar behoorlijk wat docker containers op draaien (dus docker in een lcx-ception).
...

Dus ja, guilty as charged. Het kan en het wordt niet per sé afgeraden en zoals je ziet leer je er ook een hele hoop van.

Voor de duidelijkheid, ik draai drie docker instances, allemaal in hun eigen OS omgeving, virtueel op ProxMox

• Ubuntu VM met eerder een snap docker versie waarvoor ik hemel en aarde heb moeten bewegen om deze op vanilla docker te krijgen
• Unprivileged Alpine LXC container met vanilla docker.
• Debian VM met vanilla docker, hiermee kan ik alles doen wat ik eigenlijk wil

Die laatste heb ik dus onlangs gebouwd met de lessen van de eerste twee in het achterhoofd.

[Cyphax]

ElCondor schreef op dinsdag 17 februari 2026 @ 10:26:
[...]

Sorry, ik bedoelde mijn oplossing is over-engineered
-Hey, ninja-edit-

Maar, wat doe je dan als de LXC container moet gaan wandelen naar een andere ProMox node waar de betreffende share mogelijk niet gemount is? Of mount je die dan op ALLE PM-nodes?

Hehe ik had je verkeerd begrepen, maar toch te laat gezien

Ik heb maar 2 nodes (en ik probeer dan ook nog alles op 1 node te draaien), ik verplaats de containers eigenlijk zelden. Als ik ze vaker zou willen verplaatsen, dan weet ik niet zeker wat ik zou doen, ik denk op alle (in mijn geval hooguit "beide" ) hosts die share mounten inderdaad. Op kleine schaal is dat wel goed te handlen.

Als dat niet meer zou schalen zou ik misschien kijken naar iets als Ceph maar ik probeer eigenlijk opzettelijk klein genoeg te blijven dat zoiets overkill is zonder "incompleet" te worden.

ElCondor schreef op dinsdag 17 februari 2026 @ 21:06:
[...]
Dus ja, guilty as charged. Het kan en het wordt niet per sé afgeraden en zoals je ziet leer je er ook een hele hoop van.

Ach, het is niet ideaal (ik zou zelfs willen zeggen: als je het meeste eigenlijk met Docker wil doen is Proxmox niet de meest logische keus) maar in sommige gevallen is het de minste hassle. Sommige userscripts zetten volgens mij ook een Lxc op waar stiekem dan Docker op draait. Mijn Docker-host is ook een Lxc container, niet een vm.

[ Voor 22% gewijzigd door Cyphax op 17-02-2026 21:14 ]

[ElCondor]

Cyphax schreef op dinsdag 17 februari 2026 @ 21:10:
[...]

Hehe ik had je verkeerd begrepen, maar toch te laat gezien

Ik heb maar 2 nodes (en ik probeer dan ook nog alles op 1 node te draaien), ik verplaats de containers eigenlijk zelden. Als ik ze vaker zou willen verplaatsen, dan weet ik niet zeker wat ik zou doen, ik denk op alle (in mijn geval hooguit "beide" ) hosts die share mounten inderdaad. Op kleine schaal is dat wel goed te handlen.

Als dat niet meer zou schalen zou ik misschien kijken naar iets als Ceph maar ik probeer eigenlijk opzettelijk klein genoeg te blijven dat zoiets overkill is zonder "incompleet" te worden.

[...]

Ach, het is niet ideaal (ik zou zelfs willen zeggen: als je het meeste eigenlijk met Docker wil doen is Proxmox niet de meest logische keus) maar in sommige gevallen is het de minste hassle. Sommige userscripts zetten volgens mij ook een Lxc op waar stiekem dan Docker op draait.

Hahaha, overkill is mijn middelste naam

[AgeOfPanic]

Ik ben bezig met het inrichten van een Proxmox instantie op een Asus NUC 14 Essential (N150). Ik probeer zelf Jellyfin in een LXC aan de praat te krijgen met passthrough van de GPU. Ik heb al een keer het helper script gedraaid en dan werkt het goed. Volgens mij moet alles aan de host kant dus goed staan.
Dan heb je alleen geen zicht meer op de installatie van Jellyfin en ik wil graag weten hoe ik het zelf aan de praat krijg. Ik heb het conf file van de LXC met Jellyfin zo aangepast dat ik er twee devices aan heb toegevoegd:
dev0: /dev/dri/renderD128,gid=993
dev1: /dev/dri/card0,gid=44
Dit heb ik zo overgenomen uit de .conf file van de LXC die ik met het helper script heb gemaakt. Ook de rest van het .conf bestand komt overeen. Verder heb ik op de door mij gemaakte LXC container de intel drivers geïnstalleerd met het commando: apt install xserver-xorg-video-intel. Ik zag dit niet in andere tutorials voorbij komen, maar zag wel dat het helper script Intel drivers ging installeren.
Als ik nu in Jellyfin een bestand probeer af te spelen met transcoding aan begint hij even te laden en daarna springt hij terug naar het dashboard. Heeft iemand nog tips om dit wel werkende te krijgen?

[ElCondor]

AgeOfPanic schreef op woensdag 18 februari 2026 @ 00:30:
Ik ben bezig met het inrichten van een Proxmox instantie op een Asus NUC 14 Essential (N150). Ik probeer zelf Jellyfin in een LXC aan de praat te krijgen met passthrough van de GPU. Ik heb al een keer het helper script gedraaid en dan werkt het goed. Volgens mij moet alles aan de host kant dus goed staan.
Dan heb je alleen geen zicht meer op de installatie van Jellyfin en ik wil graag weten hoe ik het zelf aan de praat krijg. Ik heb het conf file van de LXC met Jellyfin zo aangepast dat ik er twee devices aan heb toegevoegd:
dev0: /dev/dri/renderD128,gid=993
dev1: /dev/dri/card0,gid=44
Dit heb ik zo overgenomen uit de .conf file van de LXC die ik met het helper script heb gemaakt. Ook de rest van het .conf bestand komt overeen. Verder heb ik op de door mij gemaakte LXC container de intel drivers geïnstalleerd met het commando: apt install xserver-xorg-video-intel. Ik zag dit niet in andere tutorials voorbij komen, maar zag wel dat het helper script Intel drivers ging installeren.
Als ik nu in Jellyfin een bestand probeer af te spelen met transcoding aan begint hij even te laden en daarna springt hij terug naar het dashboard. Heeft iemand nog tips om dit wel werkende te krijgen?

klinkt heel bekend en dit is meer voor het JellyFin topic, denk ik, want je hebt inderdaad alles goed staan.
Je moet in de User settings van JellyFin zelf op zoek naar Playback > video Quality > Home Network Quality en deze omhoog schroeven naar 120MBps, of wat voor jou van toepassing is. Dan zul je zien dat het zeker niet altijd nodig is om te transcoderen.
Daarnaast moet je in JellyFin in de System settings > Playback > Transcoding de Hardware accelleration instellen op VAAPI en dan bij Device jouw renderer opgeven, meestal /dev/dri/renderD128

Daarnaast is het aan te raden om de client te installeren en daar mee af te spelen. De webplayer schakelt om de een of andere reden al heel snel terug naar transcoding en dat werkt niet altijd even soepel.
Houdt er verder rekening mee dat JellyFin in mijn ervaring het best omgaat met H264 content in MP4 of MKV containers. Bij mij krijg ik avi's, mov's en bijv wmv niet native aan de praat en heb ik een groot deel van mijn content omgezet naar MP4 H264 om dit in JellyFin te kunnen gebruiken.
H265 werkte bij mij in ieder geval niet en daarom ging hij de boel transcoderen.

Ik blijf hierom vooralsnog hangen bij Plex, omdat ik daar al een pass voor heb en de webplayer is veel efficienter, dus ik hoef niet overal een client te installeren. Daarnaast heeft mijn TV een native Plex app, dus dat is zowieso een reden voor me om bij Plex te blijven.

Gaat het hiermee lukken?

[ Voor 7% gewijzigd door ElCondor op 18-02-2026 08:55 ]

[Theetjuh]

AgeOfPanic schreef op woensdag 18 februari 2026 @ 00:30:
Ik ben bezig met het inrichten van een Proxmox instantie op een Asus NUC 14 Essential (N150). Ik probeer zelf Jellyfin in een LXC aan de praat te krijgen met passthrough van de GPU. Ik heb al een keer het helper script gedraaid en dan werkt het goed. Volgens mij moet alles aan de host kant dus goed staan.
Dan heb je alleen geen zicht meer op de installatie van Jellyfin en ik wil graag weten hoe ik het zelf aan de praat krijg. Ik heb het conf file van de LXC met Jellyfin zo aangepast dat ik er twee devices aan heb toegevoegd:
dev0: /dev/dri/renderD128,gid=993
dev1: /dev/dri/card0,gid=44
Dit heb ik zo overgenomen uit de .conf file van de LXC die ik met het helper script heb gemaakt. Ook de rest van het .conf bestand komt overeen. Verder heb ik op de door mij gemaakte LXC container de intel drivers geïnstalleerd met het commando: apt install xserver-xorg-video-intel. Ik zag dit niet in andere tutorials voorbij komen, maar zag wel dat het helper script Intel drivers ging installeren.
Als ik nu in Jellyfin een bestand probeer af te spelen met transcoding aan begint hij even te laden en daarna springt hij terug naar het dashboard. Heeft iemand nog tips om dit wel werkende te krijgen?

Ik weet niet waar je de gid 993 vandaan hebt, maar ik heb het volgende staan:

code:

dev0: /dev/dri/card0,gid=44
dev1: /dev/dri/renderD128,gid=104

ik maak wel gebruik van een AMD iGPU, maar dat werkt voor mij iig

als ik het install script bekijk, zie ik daar ook 104 bij render staan:

code:

if [[ "$CTTYPE" == "0" ]]; then
  sed -i -e 's/^ssl-cert:x:104:$/render:x:104:root,jellyfin/' -e 's/^render:x:108:root,jellyfin$/ssl-cert:x:108:/' /etc/group
else
  sed -i -e 's/^ssl-cert:x:104:$/render:x:104:jellyfin/' -e 's/^render:x:108:jellyfin$/ssl-cert:x:108:/' /etc/group
fi

[ Voor 10% gewijzigd door Theetjuh op 18-02-2026 09:09 . Reden: install script ]

[AgeOfPanic]

Bedankt voor de antwoorden. Die GID kun je opvragen via een commando. Heb ik ook rechtstreeks overgenomen van het script.
Ik gebruik transcoding eigenlijk nooit, maar heb nu 1 serie die alleen PGS ondertiteling heeft en dat kan Jellyfin niet aan. Als ik het helper script gebruik, dan werkt het als ik transcoding op Intel Quicksync zet. Niet op VAAPI.
Ik ben er wel achter dat het script Jellyfin installeert in een Ubuntu container. Ik probeer het zelf in een Docker container te draaien binnen de LXC. Op die manier kan ik dan de container monitoren met Dockhand. Misschien dat dat nog problemen geeft qua rechten? Moet ik dan in de container nog aangeven welke UID en GID ik wil gebruiken?

[Theetjuh]

Geen idee hoe dat werkt, zover ik weet raadt Proxmox af om docker containers in een LXC te draaien en raadt een VM aan.
Je kunt ook eens kijken naar Pulse/Patchmon als je je LXC of VM wil monitoren op Proxmox.

[Gizz]

@AgeOfPanic ik had hier ook problemen mee:

Gizz in "Het grote Proxmox VE topic"
Gizz in "Het grote Proxmox VE topic"
Gizz in "Het grote Proxmox VE topic"
Gizz in "Het grote Proxmox VE topic"
Na een uurtje of 8 prutsen om de hardware decoding aan de praat te krijgen in een LXC, heb ik Jellyfin direct binnen Proxmox in een docker container gegooid en dat werkte meteen. Tot de dag van vandaag draai ik het zo. Was (en ben) er helemaal klaar mee

[ Voor 3% gewijzigd door Gizz op 18-02-2026 14:05 ]

[dcm360]

Docker direct op Proxmox installeren is verder wel een afrader. Zowel Proxmox als Docker passen de netwerkstack aan, en dat kan elkaar in de weg gaan zitten.

[Gizz]

@dcm360 daar heb ik gelukkig (nog) geen last van gehad. Misschien helpt het ook dat dit de enige container is die ik draai?

Dit is de enige manier waarop ik het voor elkaar kon krijgen, na ruim 8 uur tutorials volgen (voor alleen het aan de praat krijgen van de hardware encoding!) en prutsen wat geen werkende situatie opleverde. Hier in het topic kon ook niemand de vinger leggen op waar het nou mis ging, helaas

[ Voor 8% gewijzigd door Gizz op 18-02-2026 14:35 ]

[AgeOfPanic]

Ik heb nu eerst het helper script aangezet zodat ik in ieder geval aan de slag kan en probeer het dan op mijn testsysteem nog wel eens aan de praat te krijgen. Ik zal eens kijken of het uitmaakt als je Jellyfin direct installeert en heb daarnaast ook nog een tutorial van Wundertech gevonden die een paar dingen anders aanpakt.
De helper scripts zijn geweldig. Binnen een paar minuten heb je een werkend systeem. Ik vind alleen wat vervelend dat het een blackbox is, waarvan ik niet precies weet wat het allemaal doet. Zit dus nu in een tweestrijd: kiezen voor gemak of doorprutsen om het zelf werkende te krijgen.

[InjecTioN]

AgeOfPanic schreef op woensdag 18 februari 2026 @ 17:42:
Ik heb nu eerst het helper script aangezet zodat ik in ieder geval aan de slag kan en probeer het dan op mijn testsysteem nog wel eens aan de praat te krijgen. Ik zal eens kijken of het uitmaakt als je Jellyfin direct installeert en heb daarnaast ook nog een tutorial van Wundertech gevonden die een paar dingen anders aanpakt.
De helper scripts zijn geweldig. Binnen een paar minuten heb je een werkend systeem. Ik vind alleen wat vervelend dat het een blackbox is, waarvan ik niet precies weet wat het allemaal doet. Zit dus nu in een tweestrijd: kiezen voor gemak of doorprutsen om het zelf werkende te krijgen.

Een helper script is geen blackbox. Die zijn juist open. Het komt allemaal van een vaste repository, waarvan je de source altijd kan achterhalen, zolang die online staat.

Zoek de scripts maar eens op. Desnoods ga je met een AI aan de slag om er iets van te maken zodat je wèl snapt wat er in zo’n script gebeurt. Het is niet voor niets een “helper script”.

[AgeOfPanic]

InjecTioN schreef op woensdag 18 februari 2026 @ 17:47:
[...]

Een helper script is geen blackbox. Die zijn juist open. Het komt allemaal van een vaste repository, waarvan je de source altijd kan achterhalen, zolang die online staat.

Zoek de scripts maar eens op. Desnoods ga je met een AI aan de slag om er iets van te maken zodat je wèl snapt wat er in zo’n script gebeurt. Het is niet voor niets een “helper script”.

Goed punt. Misschien had ik moeten zeggen dat je met het gebruik ervan geen inzicht krijgt in wat het precies doet en ik denk niet dat ik genoeg kennis heb om de scripts zelf te onderzoeken. Het is natuurlijk heel goed dat het open source scripts zijn. Dat geeft weer een extra laag zekerheid. Ik zal eens kijken of ik kan begrijpen wat ze doen.

[rachez]

Waarom niet gewoon Docker op een linux vm installeren? Scheelt je een hoop gezeur en zoveel overhead is die 10GB storage toch ook niet?

[InjecTioN]

rachez schreef op donderdag 19 februari 2026 @ 19:51:
Waarom niet gewoon Docker op een linux vm installeren? Scheelt je een hoop gezeur en zoveel overhead is die 10GB storage toch ook niet?

Daar leer je alleen wat van wanneer je docker nog niet kent. Waar je echt wat van leert: docker in een LXC draaien onder Proxmox.

Half serieus bedoeld overigens.

[ElCondor]

@Liegebeest, @Cyphax, gelukt! Vandaag mijn eerste NFS Volume vanuit een container aangelegd.
Veel werk te doen nog, maar dit werkt inderdaad al een trein.
Prachtig! Bedankt voor het meedenken

[rachez]

Mwoah, ik weet niet: die vm draait ook op proxmox, met een stuk of 15 containers, config op de vm, mooi in de backup elke week en nfs voor de grote datasets.

'Mis' dan alleen LXC, wat ik persoonlijk totaal niet erg vind. Maar ieder zijn ding.

[Quad]

@ElCondor Docker container of LXC?

[Cyphax]

ElCondor schreef op donderdag 19 februari 2026 @ 21:51:
@Liegebeest, @Cyphax, gelukt! Vandaag mijn eerste NFS Volume vanuit een container aangelegd.
Veel werk te doen nog, maar dit werkt inderdaad al een trein.
Prachtig! Bedankt voor het meedenken

Bedoel je dan de nfs-mount op de host met doorgifte aan de container of in de container zelf de nfs-mount?

[ElCondor]

Quad schreef op donderdag 19 februari 2026 @ 22:02:
@ElCondor Docker container of LXC?

Docker container in dit geval. Zie eerdere posts van mij in deze draad. Ik heb drie docker instances, allemaal draaiend op ProxMox guests, 1 LXC en 2 VM-s. Ik snap dat docker specifiek commentaar wellicht niet in dit topic thuis hoort, maar ik kreeg veel inspiratie van @Cyphax en @Liegebeest in dit topic, vandaar.

Cyphax schreef op donderdag 19 februari 2026 @ 22:12:
[...]

Bedoel je dan de nfs-mount op de host met doorgifte aan de container of in de container zelf de nfs-mount?

De mount inderdaad gedaan op de docker container. Uiteindelijk ook veel logischer, maar ja, wat je niet weet kun je ook niet toepassen. Weer veel geleerd deze week. Komende week druk met het doorvoeren van de wijzigingen die nodig zijn om alle andere containers op NFS aan te sluiten, wat configuratie betreft.
.
Wel leuk om dan te zien dat het verhuizen van containers veel gemakkelijker wordt tussen de verschillende hosts.
Ook het deployen van wijzigingen in de config bestanden die op de NFS-binds staan is makkelijker, want centraal naar 1 punt, ipv lokaal op iedere docker host zelf.
Tijdens de werkzaamheden bedacht ik me dat ook de source-data binds, die nu dmv mounts op de docker host gekoppeld zijn (fstab) door middel van deze NFS- binds gedaan moeten kunnen worden direct naar de docker containers. Dat scheelt het maintainen van fstab bestanden per docker host.

[ Voor 5% gewijzigd door ElCondor op 20-02-2026 07:59 ]

[Liegebeest]

Sprekend van veel geleerd: ik had laatst al gezegd eindelijk Uptime Kuma te hebben neergezet voor de monitoring van m'n bedrijfsomgeving. Wat nu nieuw is: ik heb voor 't eerst iets met Javascript gedaan! Ik heb een nieuwe "notification provider" gemaakt voor UK, zodat je ook alerts kan sturen met een Teltonika RUT router.

Ik heb op kantoor nl een RUT241 als backup Internet verbinding en dat ding heeft ook een SMS API. Dus voor de ergste alarmen krijg ik nu ook een SMS. De provider is live gegaan in 2.1.2.

[Liegebeest]

Cyphax schreef op donderdag 19 februari 2026 @ 22:12:
[...]

Bedoel je dan de nfs-mount op de host met doorgifte aan de container of in de container zelf de nfs-mount?

We gingen voor het equivalent van de -v volume mount bij Docker. Docker Compose, Kubernetes en dat soort dingen kunnen namelijk uitstekend een NFS share als volume mount doorgeven.

[Rubman]

Ik heb nu een paar weken een NUC draaien met Proxmox wat dockers en een LXC hier en daar. Met name als krachtigere docker, Home Assistant en Media Server dan de Synology.

Maar nu had ik het idee om ook de Chromecast de deur uit te doen en de NUC gewoon achter de TV te hangen en deze te gebruiken als media streamer. Is zoiets überhaupt mogelijk, want lees conflicterende verhalen.

Ik snap dat een volle vervanger van Google TV niet een optie is maar kan er bijvoorbeeld door libreelec en Kodi het geheel vervangen worden om toch gebruik te blijven maken van de Jellyfin server en wat streaming diensten.

[Hazalnootpuur]

Rubman schreef op zaterdag 21 februari 2026 @ 15:29:
Ik heb nu een paar weken een NUC draaien met Proxmox wat dockers en een LXC hier en daar. Met name als krachtigere docker, Home Assistant en Media Server dan de Synology.

Maar nu had ik het idee om ook de Chromecast de deur uit te doen en de NUC gewoon achter de TV te hangen en deze te gebruiken als media streamer. Is zoiets überhaupt mogelijk, want lees conflicterende verhalen.

Ik snap dat een volle vervanger van Google TV niet een optie is maar kan er bijvoorbeeld door libreelec en Kodi het geheel vervangen worden om toch gebruik te blijven maken van de Jellyfin server en wat streaming diensten.

lm

[ Voor 2% gewijzigd door Hazalnootpuur op 21-02-2026 16:58 . Reden: Niet goed gelezen. ]

[Cyphax]

Rubman schreef op zaterdag 21 februari 2026 @ 15:29:
Ik heb nu een paar weken een NUC draaien met Proxmox wat dockers en een LXC hier en daar. Met name als krachtigere docker, Home Assistant en Media Server dan de Synology.

Maar nu had ik het idee om ook de Chromecast de deur uit te doen en de NUC gewoon achter de TV te hangen en deze te gebruiken als media streamer. Is zoiets überhaupt mogelijk, want lees conflicterende verhalen.

Ik snap dat een volle vervanger van Google TV niet een optie is maar kan er bijvoorbeeld door libreelec en Kodi het geheel vervangen worden om toch gebruik te blijven maken van de Jellyfin server en wat streaming diensten.

Ik weet niet zeker of ik je helemaal goed begrijp maar Jellyfin-clients kun je besturen vanuit andere Jellyfin-clients. Als je op een NUC Jellyfin opent kan je die via een andere client, zoals op je telefoon, besturen. Maar dat blijft dan in eerste instantie beperkt tot Jellyfin.

[Rubman]

Cyphax schreef op zaterdag 21 februari 2026 @ 17:02:
[...]

Ik weet niet zeker of ik je helemaal goed begrijp maar Jellyfin-clients kun je besturen vanuit andere Jellyfin-clients. Als je op een NUC Jellyfin opent kan je die via een andere client, zoals op je telefoon, besturen. Maar dat blijft dan in eerste instantie beperkt tot Jellyfin.

Nee ik heb een Jellyfin server draaien op de NUC.
Die indexeert alles wat van *arr etc komt. Nu gebruik ik op de TV met Google TV Wholpin als client (speler) evenals Disney en Videoland zaken.

Maar nu zou ik graag de Google TV willen vervangen door de NUC en daarop naast dat er in een Proxmox LXC Jellyfin server en de *arr's draaien in Docker deze gebruiken om de Chromecast te vervangen voor het daadwerkelijk afspelen op de TV.

Nu heb ik dat al eens gedaan met een Pi met daarop Libreelec en Kodi, maar toen had ik nog niet zoveel streaming diensten.

[Quad]

@Rubman Dat wat jij wilt is niet helemaal geschikt. Ik neem aan dat je de iGPU hebt doorgelust naar Jellyfin voor transcode, hoe wil je dan een VM (want dat moet dan) gaan gebruiken die de iGPU gaat gebruiken, die er niet meer is, voor de video-output.

[Rubman]

Quad schreef op zaterdag 21 februari 2026 @ 19:51:
@Rubman Dat wat jij wilt is niet helemaal geschikt. Ik neem aan dat je de iGPU hebt doorgelust naar Jellyfin voor transcode, hoe wil je dan een VM (want dat moet dan) gaan gebruiken die de iGPU gaat gebruiken, die er niet meer is, voor de video-output.

Ja dat is waar, had ik even niet over nagedacht, dan blijven we lekker bij de Chromecast.

Nu wil transcoding ook niet helemaal lekker werken in de huidige opzet, dus moet ik nog even in duiken al kan het kwestie zijn van gewoonweg te oude NUC die het niet bijbeent. Of mijn settings staan niet lekker.

[Quad]

Check wel ff in Jellyfin of de iGPU iets doet. Welke NUC is het?
En heb je Google TV of de oude ChromeCast?

[Rubman]

Quad schreef op zaterdag 21 februari 2026 @ 20:20:
Check wel ff in Jellyfin of de iGPU iets doet. Welke NUC is het?
En heb je Google TV of de oude ChromeCast?

Ja moet even in de settings kijken of er wel wat gebeurt, wel met een LXC vanuit de helper scripts geïnstalleerd en de transcoding aangezet en igpu doorgezet.

nuc7i5bnk met een i5-7260U en heb de Google TV 4K variant

[InjecTioN]

Rubman schreef op zaterdag 21 februari 2026 @ 20:15:
[...]

Ja dat is waar, had ik even niet over nagedacht, dan blijven we lekker bij de Chromecast.

Nu wil transcoding ook niet helemaal lekker werken in de huidige opzet, dus moet ik nog even in duiken al kan het kwestie zijn van gewoonweg te oude NUC die het niet bijbeent. Of mijn settings staan niet lekker.

Je zou Jellyfin ook volledig achterwegen kunnen laten en iets als Kodi in een VM kunnen installeren op de NUC met GPU-pass-through (VT-d of AMD-Vi ondersteuning is noodzakelijk). Die kan voor het grootste deel taken overnemen van Jellyfin. Veel codecs worden daarin simpelweg ondersteund. Dan heb je ook geen transcoding proxy zoals Jellyfin nodig, wat in die situatie eigenlijk alleen maar overhead veroorzaakt. Kodi is dan simpelweg de enige die de GPU nodig heeft. Wel even network shares (SMB/NFS) gebruiken voor de data die je wilt streamen, maar dat zit bij jou denk ik al wel goed.

Een LXC voor Kodi is ook mogelijk. En dat zorgt voor minder overhead, maar dat kost mogelijk nèt wat meer moeite om het werkend te krijgen. Maar het kan dus wel prima.

Je kan als alternatief ook Kodi installeren op de GoogleTV (En bij voorkeur de GoogleTV in app-only mode zetten). Dan hoef je die NUC niet eens bij de TV in de buurt te hebben (iets met herrie van de ventilator).

Ik draai hier thuis een Jellyfin server zodat ik met mijn AppleTV via Jellyfin kan streamen. Maar ik heb soms alsnog Kodi op de GoogleTV als achtervang nodig, omdat er soms iets niet (lekker) via Jellyfin werkt.

Daarbij is er na een snelle zoekopdracht ook een Jellyfin add-in voor Kodi. Gewoon ter info.

[ElCondor]

Wat een bak!
Het weekeinde tijd besteed aan het omzetten van lokale docker volumes naar NFS-backed volumes voor de meeste van mijn containers.
Wat blijkt: waar dit hele circus om was begonnen, containers draaiend op docker in Alpine LXC bljken alsnog geen gebruik te kunnen maken van NFS-backed volumes, want mounting NFS is 'Not permitted'. Ook niet als de docker service dit wil doen in een unprivileged container.
Ik heb er genoeg van, ik ga Alpine er af gooien en er een Debian VM van maken. Docker in LXC, blijf er ver vandaan als je er grotere services op wilt gaan draaien, of je containers wilt kunnen migreren naar andere hosts.
Zit ik alleen met twee flinke migraties van mijn PaperlessXNG en Authentik die omgezet zullen moeten gaan worden. Paperless heeft een vrij robuuste, zei het bewerkelijke, manier van exporteren en importeren in een nieuwe instance, dus dat is te doen, maar ik weet niet hoe ik dit met Authentik moet gaan aanvliegen.
Dat wordt weer studeren.

[InjecTioN]

ElCondor schreef op maandag 23 februari 2026 @ 08:46:
Wat een bak!
Het weekeinde tijd besteed aan het omzetten van lokale docker volumes naar NFS-backed volumes voor de meeste van mijn containers.
Wat blijkt: waar dit hele circus om was begonnen, containers draaiend op docker in Alpine LXC bljken alsnog geen gebruik te kunnen maken van NFS-backed volumes, want mounting NFS is 'Not permitted'. Ook niet als de docker service dit wil doen in een unprivileged container.
Ik heb er genoeg van, ik ga Alpine er af gooien en er een Debian VM van maken. Docker in LXC, blijf er ver vandaan als je er grotere services op wilt gaan draaien, of je containers wilt kunnen migreren naar andere hosts.
Zit ik alleen met twee flinke migraties van mijn PaperlessXNG en Authentik die omgezet zullen moeten gaan worden. Paperless heeft een vrij robuuste, zei het bewerkelijke, manier van exporteren en importeren in een nieuwe instance, dus dat is te doen, maar ik weet niet hoe ik dit met Authentik moet gaan aanvliegen.
Dat wordt weer studeren.

Heb je de container wel initieel met Privileged, Nested en NFS flags ingeschakeld aangemaakt? Want NFS/SMB werkt eigenlijk alleen maar in privileged mode. Zorg er daarbij ook voor dat de Nested flag aan staat. Sandboxing gebeurt in bijna iedere omgeving (kijk bijvoorbeeld al naar snap of een ontwikkelomgeving voor bijvoorbeeld python). Zo heb ik een tijdje geleden redelijk wat issues gehad met een hoop LXC’s, waarbij nested uit stond. Na inschakelen: echt alle problemen weg.

Ik gebruik een Docker LXC voor Frigate. Ook met device pass through. Werkt echt meer dan prima. Het is een LXC met bovenstaande flags enabled vanaf het opzetten. Wel met een LXC helper opgezet overigens. Maar wel expliciet de LXC. Ik heb niet inhoudelijk onthouden wat er in het script voor de docker LXC helper gebeurt, maar het zag er allemaal wel prima uit toen ik het een aantal maanden geleden installeerde.

[ElCondor]

InjecTioN schreef op maandag 23 februari 2026 @ 09:08:
[...]

Heb je de container wel initieel met Privileged, Nested en NFS flags ingeschakeld aangemaakt? Want NFS/SMB werkt eigenlijk alleen maar in privileged mode. Zorg er daarbij ook voor dat de Nested flag aan staat. Sandboxing gebeurt in bijna iedere omgeving (kijk bijvoorbeeld al naar snap of een ontwikkelomgeving voor bijvoorbeeld python). Zo heb ik een tijdje geleden redelijk wat issues gehad met een hoop LXC’s, waarbij nested uit stond. Na inschakelen: echt alle problemen weg.

Ik gebruik een Docker LXC voor Frigate. Ook met device pass through. Werkt echt meer dan prima. Het is een LXC met bovenstaande flags enabled vanaf het opzetten. Wel met een LXC helper opgezet overigens. Maar wel expliciet de LXC. Ik heb niet inhoudelijk onthouden wat er in het script voor de docker LXC helper gebeurt, maar het zag er allemaal wel prima uit toen ik het een aantal maanden geleden installeerde.

Nee, zie eerdere posts in dit topic. Niet privileged aangemaakt (niet bij nagedacht en dit staat default zo bij het aanmaken van een LXC). Wel een poging gedaan om dmv backup-restore de container om te zetten naar privileged, maar dan willen de containers niet meer starten ivm rechten en dat oplossen is ook een mijl op 7.
Er werd daarom nog aangeraden om docker zelf te laten zorgen voor het mounten van de NFS-volumes door ze als zodanig te definiëren in de compose. Dat werkt op een normale VM, maar niet op een unprivileged LXC.
Catch 22, soort van. Dus ik hap de kogel en ga aan de slag met het in de lucht trekken van een nieuwe VM waar ik alles op ga zetten.

[InjecTioN]

ElCondor schreef op maandag 23 februari 2026 @ 09:13:
[...]

Nee, zie eerdere posts in dit topic. Niet privileged aangemaakt (niet bij nagedacht en dit staat default zo bij het aanmaken van een LXC). Wel een poging gedaan om dmv backup-restore de container om te zetten naar privileged, maar dan willen de containers niet meer starten ivm rechten en dat oplossen is ook een mijl op 7.
Er werd daarom nog aangeraden om docker zelf te laten zorgen voor het mounten van de NFS-volumes door ze als zodanig te definiëren in de compose. Dat werkt op een normale VM, maar niet op een unprivileged LXC.
Catch 22, soort van. Dus ik hap de kogel en ga aan de slag met het in de lucht trekken van een nieuwe VM waar ik alles op ga zetten.

VM werkt inderdaad zeker. Maar zorgt wel voor extra overhead. Mocht je die overhead niet wensen, dan zou ik alsnog voor een privileged+nested+NFS LXC gaan. Anders, zeker voor de VM gaan.

[ElCondor]

InjecTioN schreef op maandag 23 februari 2026 @ 10:15:
[...]

VM werkt inderdaad zeker. Maar zorgt wel voor extra overhead. Mocht je die overhead niet wensen, dan zou ik alsnog voor een privileged+nested+NFS LXC gaan. Anders, zeker voor de VM gaan.

Tot die conclusie was ik ook gekomen.
Er spelen nog wel een aantal andere factoren mee. Ik heb nu bijvoorbeeld een Kavita container draaien die gebruik maakt van SQLite icm MS Entity Framework, één van die twee gooit roet in het eten bij gebruik van Kavita, Om de haveklap stokt de website, gooit met error 500 of 400 en in de logging zie ik geregeld 'database is locked' exceptions voorbij komen.
Ik lees her en der op internet dat SQLite niet lekker om gaat met database files op een NFS share. Dus ik zit er mogelijk aan vast om deze toch weer op lokale storage vwb de docker instance te gaan draaien.
Ik voorzie zo maar eens dezelfde problemen voor Authentik, omdat deze een behoorlijke PostGres database als backend heeft. De vraag is of die lekker omgaat met een NFS-backed volume. Dus die zal mogelijk ook op local storage gedraaid gaan worden.

[Airw0lf]

Met NFS-4.1 zou het moeten werken met "echte" databases omdat deze versie record locking ondersteund bij gebruik door meerdere systemen/applicaties. Bij SQLite zal het altijd een lastige blijven omdat hier "gewone" textbestanden gebruikt worden.

[Quad]

InjecTioN schreef op maandag 23 februari 2026 @ 10:15:
[...]

VM werkt inderdaad zeker. Maar zorgt wel voor extra overhead. Mocht je die overhead niet wensen, dan zou ik alsnog voor een privileged+nested+NFS LXC gaan. Anders, zeker voor de VM gaan.

Mja, met privileged LXC map je root in de LXC op root van je PVE host. En als in je LXC iets mis gaat, bijvoorbeeld via een hack, dan is toegang tot kernel wellicht mogelijk. Als een service een kernel crash veroorzaakt kan dat ook invloed hebben op je host. Met unprivileged LXC wil dat niet.
Met een VM scheidt je volledig de laag tussen de host en het OS van de VM. Kost wel extra resources en opslag, al levert dit wel het gemak op die @ElCondor dan zoekt.

[InjecTioN]

Quad schreef op maandag 23 februari 2026 @ 11:24:
[...]

Mja, met privileged LXC map je root in de LXC op root van je PVE host. En als in je LXC iets mis gaat, bijvoorbeeld via een hack, dan is toegang tot kernel wellicht mogelijk. Als een service een kernel crash veroorzaakt kan dat ook invloed hebben op je host. Met unprivileged LXC wil dat niet.
Met een VM scheidt je volledig de laag tussen de host en het OS van de VM. Kost wel extra resources en opslag, al levert dit wel het gemak op die @ElCondor dan zoekt.

Agreed. Voor een productie omgeving is dit geen gewenste situatie. Alles behalve zelfs. Maar voor een thuis cluster; why not?

Ik heb mijn diensten allemaal achter slot en grendel (wireguard). Daar hoeft ook echt niemand anders bij te komen. Alleen mijn gezin is ervan “afhankelijk”. Daarbij zijn er 3 nodes in mijn cluster met CEPH, waardoor ik het risico met een potentiële crash afvang met High Availability. En onderaan de streep leer je er weer van. Dat is imho waar een thuiscluster ook het grootste deel voor is.

Een vm is in bijna iedere situatie de beste oplossing wanneer je voldoende resources ter beschikking hebt. Laat geheugenprijzen daar voor home clusters nou net roet voor in het eten gooien.

[Quad]

InjecTioN schreef op maandag 23 februari 2026 @ 14:25:
[...]

Agreed. Voor een productie omgeving is dit geen gewenste situatie. Alles behalve zelfs. Maar voor een thuis cluster; why not?

Ik heb mijn diensten allemaal achter slot en grendel (wireguard). Daar hoeft ook echt niemand anders bij te komen. Alleen mijn gezin is ervan “afhankelijk”. Daarbij zijn er 3 nodes in mijn cluster met CEPH, waardoor ik het risico met een potentiële crash afvang met High Availability. En onderaan de streep leer je er weer van. Dat is imho waar een thuiscluster ook het grootste deel voor is.

Een vm is in bijna iedere situatie de beste oplossing wanneer je voldoende resources ter beschikking hebt. Laat geheugenprijzen daar voor home clusters nou net roet voor in het eten gooien.

Het gaat niet alleen om wat extern naar binnen komt. De toepassingen kunnen via de LXC ook je host gewoon laten crashen als daar een fout in optreedt. Ik heb zelf op PBS na alles unprivileged. Wel op 1 host, dus de NFS mount gebeurd via de host. Al ben ik wel van mening dat dit ook niet de veiligste manier is mbt data-toegang!

Een 3-node cluster met CEPH hebben er heel weinig in huis denk ik, nice! Gebruik je TB onderling voor netwerk over TB?

[Jerie]

ElCondor schreef op maandag 23 februari 2026 @ 08:46:
Wat een bak!
Het weekeinde tijd besteed aan het omzetten van lokale docker volumes naar NFS-backed volumes voor de meeste van mijn containers.
Wat blijkt: waar dit hele circus om was begonnen, containers draaiend op docker in Alpine LXC bljken alsnog geen gebruik te kunnen maken van NFS-backed volumes, want mounting NFS is 'Not permitted'. Ook niet als de docker service dit wil doen in een unprivileged container.
Ik heb er genoeg van, ik ga Alpine er af gooien en er een Debian VM van maken. Docker in LXC, blijf er ver vandaan als je er grotere services op wilt gaan draaien, of je containers wilt kunnen migreren naar andere hosts.
Zit ik alleen met twee flinke migraties van mijn PaperlessXNG en Authentik die omgezet zullen moeten gaan worden. Paperless heeft een vrij robuuste, zei het bewerkelijke, manier van exporteren en importeren in een nieuwe instance, dus dat is te doen, maar ik weet niet hoe ik dit met Authentik moet gaan aanvliegen.
Dat wordt weer studeren.

Bij containers staat je data en config op een bepaalde volume, dat moet gewoon lukken om die te hergebruiken.

Authentik heb ik nog nooit gebruikt. Ik gebruik voor IDM liever iets met Rust, maar hoe dan ook, ook daar moet je de config (data is er denk ik niet?) kunnen hergebruiken.

Qua Alpine vs. Debian zag ik laatst benchmarks (ik meen van PostgreSQL) waarbij Debian betere performance gaf. Dan kan Alpine image iets kleiner zijn, heb ik liever betere performance. Die paar MB, who cares?

[ElCondor]

Jerie schreef op maandag 23 februari 2026 @ 14:44:
[...]


Bij containers staat je data en config op een bepaalde volume, dat moet gewoon lukken om die te hergebruiken.

Authentik heb ik nog nooit gebruikt. Ik gebruik voor IDM liever iets met Rust, maar hoe dan ook, ook daar moet je de config (data is er denk ik niet?) kunnen hergebruiken.

Qua Alpine vs. Debian zag ik laatst benchmarks (ik meen van PostgreSQL) waarbij Debian betere performance gaf. Dan kan Alpine image iets kleiner zijn, heb ik liever betere performance. Die paar MB, who cares?

Dat zou je zeggen ja, maar ik heb wel eens meegemaakt dat het redeployen van een container met hergebruik van het al bestaande volume toch mis ging omdat de app detecteerde dat er iets was met de database bestanden waar hij niet mee om kon gaan en toen maar als oplossing een reinitialize deed. Gelukig had ik een backup. Dat is uiteraard wel de fout van de container, dat die er niet goed mee om ging, maar ik ben er nooit gerust op dat dit voor welke app dan ook goed in elkaar steekt. Ik ga altijd uit van het ergste en zorg dat ik allereerst een roll-back scenario heb

[Jerie]

ElCondor schreef op maandag 23 februari 2026 @ 14:50:
[...]

Dat zou je zeggen ja, maar ik heb wel eens meegemaakt dat het redeployen van een container met hergebruik van het al bestaande volume toch mis ging omdat de app detecteerde dat er iets was met de database bestanden waar hij niet mee om kon gaan en toen maar als oplossing een reinitialize deed. Gelukig had ik een backup. Dat is uiteraard wel de fout van de container, dat die er niet goed mee om ging, maar ik ben er nooit gerust op dat dit voor welke app dan ook goed in elkaar steekt. Ik ga altijd uit van het ergste en zorg dat ik allereerst een roll-back scenario heb

Ja, dat soort dingen gebeuren als je een andere database versie gebruikt. Daar gebruik ik deze container voor: https://hub.docker.com/r/pgautoupgrade/pgautoupgrade

Btw, met ZFS is het vrij eenvoudig snapshots en rollbacks te doen.

[ Voor 3% gewijzigd door Jerie op 23-02-2026 17:14 ]

[InjecTioN]

Quad schreef op maandag 23 februari 2026 @ 14:43:
[...]

Het gaat niet alleen om wat extern naar binnen komt. De toepassingen kunnen via de LXC ook je host gewoon laten crashen als daar een fout in optreedt. Ik heb zelf op PBS na alles unprivileged. Wel op 1 host, dus de NFS mount gebeurd via de host. Al ben ik wel van mening dat dit ook niet de veiligste manier is mbt data-toegang!

Ben ik me van bewust inderdaad, maar omdat bij mij de impact van een gecrashte LXC lager is omdat de LXC op een andere node wordt herstart wanneer de node faalt, zie ik daar juist minder risico in.

Risico's worden grotendeels weggenomen omdat ik als enige alles beheer en ook alleen mijn Docker LXC's en een Jellyfin container als privileged ingezet heb ivm NFS en hardware pass-through. Vooralsnog zijn er geen indicaties die doen blijken dat dit een probleem veroorzaakt. Ik ben er ook zelf bij wanneer ik een issue veroorzaak.

Quad schreef op maandag 23 februari 2026 @ 14:43:
[...]
Een 3-node cluster met CEPH hebben er heel weinig in huis denk ik, nice! Gebruik je TB onderling voor netwerk over TB?

Ik gebruik als nodes 3x HP ProDesk 405 G4 met:

• AMD Ryzen 5 Pro 2400GE
• 2x8GB DDR4
• 1 enterprise sATA SSD van 480GB voor CEPH storage,
• 1 OEM NVMe SSD van 256GB voor het OS.
• m.2 a+e-key Intel i226 NIC, (van ome ali) wat 2.5Gbit aan doorvoer biedt als additionele netwerkkaart langs de 1Gbit die reeds on-board zit. Samen bieden ze redundancy middels active-passive configuratie.

Netwerk:

• Voor de 1Gbit uplink van iedere node: 1x ZyXEL EX5601-T1 ( 2x 2.5Gbit, 3x 1Gbit, met OpenWrt)
• Voor de 2.5Gbit uplink van iedere node: 1x Unify Flex Mini 2.5G (5 poorts 2.5Gbit)
• Beide switches aangesloten op: 1x ZyXEL GS1900-8HP (8 poorts PoE 1Gbit switch, met OpenWrt)

Gescheiden VLAN's voor storage, management, LAN, IOT, kinderen, "speeltuin" en guest.

Netwerk ben ik nog niet blij mee, omdat ik graag een 2.5Gbit uplink wilde hebben vanuit mijn kantoor. Die heb ik nu "uit nood" maar even in de unify geprikt in plaats van de GS1900-8HP.

Het enige wat ik nog niet heb is een UPS...

Stiekem ben ik ook nog aan het "dromen" van een dual SFP+ netwerk configuratie voor 2x 10Gbit/s active-passive per node en switches voor redundancy, maar dat is financieel vooralsnog even out-of-reach/niet te verantwoorden.

Ergens wil ik het cluster zelf ook nog wat groter/veiliger maken door er nog 2 identieke proxmox nodes bij te prikken, waardoor ik automatisch weer wat andere netwerk apparatuur nodig heb. Èn dan die UPS natuurlijk nog.

A man can dream, right?

A word of caution: 1 proxmox node is een gateway drug naar meer proxmox nodes

[ Voor 1% gewijzigd door InjecTioN op 23-02-2026 15:55 . Reden: link ome ali ]

[Quad]

@InjecTioN Ik had ook meerdere nodes maar ik heb inmiddels gekozen om op 1 performance systeem te richten, is aardig gelukt.

#	Categorie	Product	Prijs	Subtotaal
1	Processors	Intel Core i5-10600 Boxed	€ 0,-	€ 0,-
1	Moederborden	ASRock H470M-ITX/ac	€ 0,-	€ 0,-
1	Videokaarten	Gigabyte GeForce RTX 5060 Ti WINDFORCE MAX OC 16G	€ 725,05	€ 725,05
3	Interne harde schijven	WD Red Plus (256MB cache, 5.640rpm), 8TB	€ 267,-	€ 801,-
1	Behuizingen	Fractal Design Node 304 Zwart	€ 77,10	€ 77,10
1	Geheugen intern	Corsair Vengeance LPX CMK64GX4M2D3000C16	€ 0,-	€ 0,-
1	Voedingen	Thermaltake Toughpower GF A3 Gold 650W - TT Premium Edition	€ 91,46	€ 91,46
1	Interne ssd's	Kingston A2000 1TB	€ 219,28	€ 219,28
1	Interne ssd's	Samsung 870 Evo (MZ-77E4T0B/EU) 4TB	€ 459,-	€ 459,-
1	Interne ssd's	WD Blue SN570 2TB	€ 235,-	€ 235,-
1	Ups en stekkerdozen	APC Back-UPS BE850G2-GR (Europees)	€ 131,50	€ 131,50
Bekijk collectie Importeer producten			Totaal	€ 2.739,39

1TB als boot en voor LXCs (Plex/PBS/*arr stack/+hele boel meer).
2TB voor de VMs (Tactical RMM, HAOS, Xpenology en W11 Gaming-LLM VM (GPU passtrough voor Ollama en Sunshine))
3x8TB + 1x 4TB passtrough naar Xpenology als NAS. (Xpenology omdat dit het beste werkt met M365 backup)
Geheugen net op tijd gekocht via V&A.
APC UPS met USB passtrough en automatische afsluiting Proxmox via Home Assistant dmv NUT integratie.

2 extra nodes voor Adguard/Nginx proxy en HA zou niet een overbodige luxe zijn, maar dan neemt stroomverbruik ook weer toe en nu vind ik dit wel prima zo.

[InjecTioN]

Quad schreef op maandag 23 februari 2026 @ 17:03:
@InjecTioN Ik had ook meerdere nodes maar ik heb inmiddels gekozen om op 1 performance systeem te richten, is aardig gelukt.

#	Categorie	Product	Prijs	Subtotaal
1	Processors	Intel Core i5-10600 Boxed	€ 0,-	€ 0,-
1	Moederborden	ASRock H470M-ITX/ac	€ 0,-	€ 0,-
1	Videokaarten	Gigabyte GeForce RTX 5060 Ti WINDFORCE MAX OC 16G	€ 725,05	€ 725,05
3	Interne harde schijven	WD Red Plus (256MB cache, 5.640rpm), 8TB	€ 267,-	€ 801,-
1	Behuizingen	Fractal Design Node 304 Zwart	€ 77,10	€ 77,10
1	Geheugen intern	Corsair Vengeance LPX CMK64GX4M2D3000C16	€ 0,-	€ 0,-
1	Voedingen	Thermaltake Toughpower GF A3 Gold 650W - TT Premium Edition	€ 91,46	€ 91,46
1	Interne ssd's	Kingston A2000 1TB	€ 219,28	€ 219,28
1	Interne ssd's	Samsung 870 Evo (MZ-77E4T0B/EU) 4TB	€ 459,-	€ 459,-
1	Interne ssd's	WD Blue SN570 2TB	€ 235,-	€ 235,-
1	Ups en stekkerdozen	APC Back-UPS BE850G2-GR (Europees)	€ 131,50	€ 131,50
Bekijk collectie Importeer producten			Totaal	€ 2.739,39

1TB als boot en voor LXCs (Plex/PBS/*arr stack/+hele boel meer).
2TB voor de VMs (Tactical RMM, HAOS, Xpenology en W11 Gaming-LLM VM (GPU passtrough voor Ollama en Sunshine))
3x8TB + 1x 4TB passtrough naar Xpenology als NAS. (Xpenology omdat dit het beste werkt met M365 backup)
Geheugen net op tijd gekocht via V&A.
APC UPS met USB passtrough en automatische afsluiting Proxmox via Home Assistant dmv NUT integratie.

2 extra nodes voor Adguard/Nginx proxy en HA zou niet een overbodige luxe zijn, maar dan neemt stroomverbruik ook weer toe en nu vind ik dit wel prima zo.

Dat is echt wel een prima systeempje hoor! Als je energie-zuiniger zou willen zijn, dan kan ik je aanraden om de CPU govenor simpelweg tunen door 'm op powersave mode te laten draaien. Ik denk dat de grootste verbruiker bij jou de RTX 5060 TI is, nietwaar?

Draai je ook een LLM op die bak? En misschien zelfs iets van Home Assistant Voice assistant oid? Dat is iets wat ik uiteindelijk ook nog eens wil testen, maar eerst meer geheugen nodig...

Ik ben jaloers op de UPS

Ik forceer de CPU govenor bij mij om niet hoger te gaan dan 1600MHz, ondanks dat die tot 3,4GHz (oid) kan gaan. Daarbij gebruik ik daarin de ingebouwde VEGA 11 GPU van de Ryzen 5 Pro 2400GE. Geheugen-technisch een drama, gezien de beperking van 16GB die ik nu in iedere nodes heb zitten, maar goed te optimaliseren zodat het flexibel blijft (in mijn situatie). Uiteindelijk is het doel om daar ook wat meer geheugen in te prakken. 64GB is de max heb ik al kunnen achterhalen.

Het stroomverbruik is ook ingekrompen op mijn zelfbouw NAS overigens, die ik er langs draai voor een centrale NFS/SMB share met spinning disks. Die heeft zelfs een ITX bord met een gesoldeerde AMD A4-5000 (15W tdp) en 16GB DDR3 (way overkill) erin zitten, met 2x 8TB Seagate Exos disks en een kleine 16GB SSD voor OpenMediaVault, waarbij de disks de meeste stroomverbruik genereren van de NAS (dat was tussen 17 en 20W zonder spinning disks, nu ~40W met spinning disks). De combinatie met mijn 3 proxmox nodes en de NAS verbruikt ongeveer 100W (met gemiddelde load) - gemeten met een Ikea Inspelning.

[Quad]

@InjecTioN Yes, Ik gebruik Ollama die dmv api aan Home Assistant beschikbaar is. Ben er nog niet zover mee dat ik voice assistant ermee gebruik, Google assistant werkt hier prima eigenlijk. Maar het stuurt me dagelijks een overzicht van het weer voor de dag erop.

Ik heb even gekeken, mijn systeem verbruikt 63W continue gemiddeld. (1.51kWh/dag)
Vind ik weinig gezien de hardware die erin zit.
CPU Governor op powersave wordt elke boot afgedwongen.

[edwin2021]

Voor een ups even op marktplaats kijken en dan incalculeren dat er gelijk een accu in moet. Apc is ok (liefst met netwerk management card) Aeton is ook erg goed, accu's gaan langer mee als bij apc.

[Airw0lf]

edwin2021 schreef op maandag 23 februari 2026 @ 20:11:
Voor een ups even op marktplaats kijken en dan incalculeren dat er gelijk een accu in moet. Apc is ok (liefst met netwerk management card) Eaton is ook erg goed, accu's gaan langer mee als bij apc.

Even ee zijstap: wat is een passende Eaton UPS - type Line Interactive - liefst met een echte sinus.

[Theetjuh]

Eaton, niet Aeton

[Airw0lf]

Theetjuh schreef op maandag 23 februari 2026 @ 20:59:
Eaton, niet Aeton

Waar dan?

[edwin2021]

Sorry, type.
Even uit m'n hoofd is het volgens het smart ups type wat een usb aansluiting heeft en spannings stabilisatie.

[Jerie]

Wat is er zo bijzonder aan dat UPS? APC gebruikt toch proprietary kabel om data uit te lezen? Ook lijkt mij de batterij niet makkelijk te vervangen, en meestal looizuur. Het is wel vrij compact vanwege formaat, maar ach.

Dan kun je beter een enterprise NVMe met PLP nemen. Wat duurder, maar kan wel veel meer writes dan consumer spul. Zet je ZIL en ZFS cache erop, en je data op filesystem zal consistent blijven. Wel write-cache op de HDDs uitzetten.

Voor gaming (wel interessant met Sunshine) en Ollama zou ik eGPU overwegen maar schijnt niet te werken met ML (een performance loss van rond de 10% is acceptabel). De totale W die je noemt zal zonder GPU zijn. Tenslotte met SR-IOV kun je GPU diverse keren assignen, aan meerdere VMs en containers (inclusief LXC). Zo doe ik het met de Intel Xe iGPU. 8 virtuele GPUs.

[edwin2021]

Jerie schreef op maandag 23 februari 2026 @ 21:27:
Wat is er zo bijzonder aan dat UPS? APC gebruikt toch proprietary kabel om data uit te lezen? Ook lijkt mij de batterij niet makkelijk te vervangen, en meestal looizuur. Het is wel vrij compact vanwege formaat, maar ach.

Niets, behalve dat Eaton goed wordt ondersteund bij Linux en dat de accu's bij APC gemiddeld om de 3 a 4 jaar vervangen moeten worden 😉

Maar hé, ik heb zelf thuis een mix van APC en Eaton in gebruik. Originele accu voor een 750VA APC is zeker niet goedkoop. Voor een Eaton 650VA is minder als de helft. Beide origineel.

[ Voor 16% gewijzigd door edwin2021 op 23-02-2026 21:35 ]

[Quad]

De APC BE850 G2 die hier staat heeft bij gemiddelde belasting van 65W een runtime van ruim een uur. En heeft een eenvoudig vervangbare en gangbare batterij.
Met NUT is de USB uit te lezen en kan je met die info ook wel acties laten ondernemen.

[edwin2021]

Quad schreef op maandag 23 februari 2026 @ 21:33:
De APC BE850 G2 die hier staat heeft bij gemiddelde belasting van 65W een runtime van ruim een uur. En heeft een eenvoudig vervangbare en gangbare batterij.
Met NUT is de USB uit te lezen en kan je met die info ook wel acties laten ondernemen.

Ik over 2x smc750i, die stabiliseert ook de spanning. Een be850 volgens mij niet. Ik denk ook dat het stabiliseren van de spannings deels de reden is van de korte levensduur. Blijft wel dat de Eaton ook de spanning stabiliseert maar met een betere houdbaarheid van de accu.
O ja, apc software is echt super uitgebreid. Eaton stuk minder.

[RobertMe]

Het grote nadeel van een UPC die de spanning "stabiliseert" is dat ze een enorm stroomverbruik hebben, en wat je er vervolgens voor terug krijgt... * Ik had een APC, volgens mij line-interactive (de middelste variant zeg maar), die 40W uit het stopcontact trok met mijn mini PCtje / serverjte aangesloten. Vervolgens vervangen door een offline standby (?, de "laagste" variant dan) model en nu trekt die 8W uit het stopcontact. Oftewel een 280kWh besparing op jaarbasis.

* Ja, een stabiele spanning. Maar in Nederland is het meest voorkomende nog steeds volledige uitval, en dat is best wel heel erg zeldzaam over het algemeen. Rare / onstabiele spanningen (dus zeg minder dan 200V of goed over de 250V) zijn nog veel zeldzamer. En in omringende landen mag de spanning hoger zijn, in NL moeten omvormers uitvallen bij 230V + 10% oftewel 253V, in BE ligt die grens hoger, dus gangbare hardware zal vast geen problemen hebben met een langdurige hogere spanning van 240 of 250 V.

[Wild Chocolate]

Jerie schreef op maandag 23 februari 2026 @ 21:27:
Wat is er zo bijzonder aan dat UPS? APC gebruikt toch proprietary kabel om data uit te lezen? Ook lijkt mij de batterij niet makkelijk te vervangen, en meestal looizuur. Het is wel vrij compact vanwege formaat, maar ach.
(...)

Is dat een nieuw, milieuvriendelijk type accu?

[Jerie]

Wild Chocolate schreef op maandag 23 februari 2026 @ 23:44:
[...]

Is dat een nieuw, milieuvriendelijk type accu?

Ja, die uit het anarchist cookbook

Loodzuur / lead-acid. Rommel is dat.

LiFePO4 gaat langer meer. Wat zwaarder dan Li-Ion, maar dat maakt voor een UPS niet uit. Nog steeds lichter dan lead-acid, minder gevaarlijk bij brand (qua gas bijvoorbeeld), en gaat veel langer mee (10+ jaar). Ze zijn helaas ook een stuk duurder.

In de PW staan ze trouwens niet. Zul je naar een zogeheten thuisbatterij moeten zoeken. Er staat wel wat Li-Ion in de PW, maar die zijn peperduur. 2,4k EUR, voor die prijzen heb je zo 2+ thuisbatterijen, haha.

[ Voor 8% gewijzigd door Jerie op 24-02-2026 00:58 ]

[Jerie]

RobertMe schreef op maandag 23 februari 2026 @ 22:42:
Het grote nadeel van een UPC die de spanning "stabiliseert" is dat ze een enorm stroomverbruik hebben, en wat je er vervolgens voor terug krijgt... * Ik had een APC, volgens mij line-interactive (de middelste variant zeg maar), die 40W uit het stopcontact trok met mijn mini PCtje / serverjte aangesloten. Vervolgens vervangen door een offline standby (?, de "laagste" variant dan) model en nu trekt die 8W uit het stopcontact. Oftewel een 280kWh besparing op jaarbasis.

* Ja, een stabiele spanning. Maar in Nederland is het meest voorkomende nog steeds volledige uitval, en dat is best wel heel erg zeldzaam over het algemeen. Rare / onstabiele spanningen (dus zeg minder dan 200V of goed over de 250V) zijn nog veel zeldzamer. En in omringende landen mag de spanning hoger zijn, in NL moeten omvormers uitvallen bij 230V + 10% oftewel 253V, in BE ligt die grens hoger, dus gangbare hardware zal vast geen problemen hebben met een langdurige hogere spanning van 240 of 250 V.

Ik vind het zonde van de W in vergelijking met een enterprise NVMe met PLP die nauwelijks meer W kost dan een consumer NVMe. Al geef ik toe dat ik niet naar de huidige prijzen heb gekeken. Je kunt ze ook tweedehands of met minder TB aanschaffen. Op zich valt ook wel wat te zeggen wanneer je stelt: ik wil graag het glasvezelmodem, ONT, plus de WAP aangesloten hebben op een UPS. In geval van stroomuitval kun je dan immers verder. Ik heb zelf niet eens een glasvezelmodem en ONT, wel losse SFP+ en losse WAP. Maar ik hoef er geen met loodzuur in mijn meterkast, en ik heb ook geen zin om elke 3 jaar de batterij of UPS te vervangen.

Bij een succesvolle cyberaanval zou wel schade kunnen ontstaan, maar op zich werkt dat systeem dusdanig dat pieken ergens in Europa zorgen voor dalen elders in Europa omdat alles op elkaar is aangesloten. Er wordt direct op- of afgeschaald, we kunnen een klap van 2 gigawatt incasseren. Aldus Ot van Daalen in zijn boek Voorbereid. Ook kan mjn verdeeldoos een flinke klap hebben.

[edwin2021]

RobertMe schreef op maandag 23 februari 2026 @ 22:42:
Het grote nadeel van een UPC die de spanning "stabiliseert" is dat ze een enorm stroomverbruik hebben, en wat je er vervolgens voor terug krijgt... * Ik had een APC, volgens mij line-interactive (de middelste variant zeg maar), die 40W uit het stopcontact trok met mijn mini PCtje / serverjte aangesloten. Vervolgens vervangen door een offline standby (?, de "laagste" variant dan) model en nu trekt die 8W uit het stopcontact. Oftewel een 280kWh besparing op jaarbasis.

* Ja, een stabiele spanning. Maar in Nederland is het meest voorkomende nog steeds volledige uitval, en dat is best wel heel erg zeldzaam over het algemeen. Rare / onstabiele spanningen (dus zeg minder dan 200V of goed over de 250V) zijn nog veel zeldzamer. En in omringende landen mag de spanning hoger zijn, in NL moeten omvormers uitvallen bij 230V + 10% oftewel 253V, in BE ligt die grens hoger, dus gangbare hardware zal vast geen problemen hebben met een langdurige hogere spanning van 240 of 250 V.

Verbruik, daar zeg je zoiets. Nooit aan gedacht en ga ik eens meten.
Tja waarom 4 ups'en in huis. Ik woon ik buiten gebied met een groot productie bedrijf op ca 400 Meter en toen ik hier ging wonen ging de netspanning echt alle kanten op, halogeen verlichting stond continu te knipperen en minimaal 1x per maand de spanning eraf. Wellicht het moment om eens te kijken of ik kan minderen in de ups'en of een simpelere uitvoering want nog een nadeel van de spanning regulering is dat met de huidige zonnepanelen hij in de zomer zeer regelmatig de spanning naar beneden aan het regelen is omdat de bandbreedte van het regel gebied niet op 253V kan worden gezet.

[edwin2021]

edwin2021 schreef op dinsdag 24 februari 2026 @ 06:54:
[...]

Verbruik, daar zeg je zoiets. Nooit aan gedacht en ga ik eens meten.
Bij mij trouwens een hpe dl350, die blinkt sowieso niet uit in energiezuinigheid....
Tja waarom 4 ups'en in huis. Ik woon ik buiten gebied met een groot productie bedrijf op ca 400 Meter en toen ik hier ging wonen ging de netspanning echt alle kanten op, halogeen verlichting stond continu te knipperen en minimaal 1x per maand de spanning eraf. Wellicht het moment om eens te kijken of ik kan minderen in de ups'en of een simpelere uitvoering want nog een nadeel van de spanning regulering is dat met de huidige zonnepanelen hij in de zomer zeer regelmatig de spanning naar beneden aan het regelen is omdat de bandbreedte van het regel gebied niet op 253V kan worden gezet.