[Docker] [alle OS] Het grote Docker ervaringen en tips topic

[witchdoc]

ja watte....
Leuk verhaal dat ansible maar een stap te ver voor mij vrees ik.

Wat is de beginners editie hiervan?
Ik zoek 'iets' dat simpeler is dan ansible maar wel beter is dan mijn huidige manier: notepad++ met compose files hier en daar zonder enige versioning of automatisering en af en toe nog een docer run erbij ook als de guide dat voorstelt.

Dat dit niet goed werkt heb ik ondertussen door, maar hoe start ik de weg naar iets beter? Weet dat ik noch Linux guru, noch coder ben maar wel wil leren.

Zit zelf op Windows PC met docker op een Proxmox Host met Docker VM.

- VSCode? na installeren Connect to docker host? Verder helaas option overload dus nog steeds geen idee hoe ik het nu echt zou gebruiken.
EDIT: ok, 'gewoon' SSH naar de docker en je kan rechtstreeks op die machine compose file sbeheren met leuke kleurtjes

- Git? Self-hosted? lab? hub? hoe

Hoe hangt dit allemaal aan elkaar?

[ Voor 6% gewijzigd door witchdoc op 21-04-2026 18:33 ]

[synoniem]

witchdoc schreef op dinsdag 21 april 2026 @ 12:32:
ja watte....
Leuk verhaal dat ansible maar een stap te ver voor mij vrees ik.

Wat is de beginners editie hiervan?
Ik zoek 'iets' dat simpeler is dan ansible maar wel beter is dan mijn huidige manier: notepad++ met compose files hier en daar zonder enige versioning of automatisering en af en toe nog een docer run erbij ook als de guide dat voorstelt.

Dat dit niet goed werkt heb ik ondertussen door, maar hoe start ik de weg naar iets beter? Weet dat ik noch Linux guru, noch coder ben maar wel wil leren.

Zit zelf op Windows PC met docker op een Proxmox Host met Docker VM.

- VSCode? na installeren Connect to docker host? Verder helaas option overload dus nog steeds geen idee hoe ik het nu echt zou gebruiken.
- Git? Self-hosted? lab? hub? hoe

Hoe hangt dit allemaal aan elkaar?

Ik heb zowel Dockerfile, docker-compose.yml als de container image zelf in Forgejo (voorheen Gitea) staan (git, container registry en runners ineen). Daarmee heb je versiebeheer van de drie belangrijke onderdelen van Docker. Voor de data heb je meerdere keuzes de meeste van mijn projectjes gebruiken een database of bind volumes die bij allemaal onder de map data staan en dagelijks gebackupped worden naar een externe locatie. Voor Kubernetes/Swarm projecten gebruik ik Rancher voor shared volume of databases of REST api's.

Forgejo/Gitea draai ik overigens ook in Docker maar is een aparte VM die in zijn geheel door Proxmox dagelijks gebackupped wordt naar een externe locatie.

[Wienen]

witchdoc schreef op dinsdag 21 april 2026 @ 12:32:
ja watte....
Leuk verhaal dat ansible maar een stap te ver voor mij vrees ik.

Wat is de beginners editie hiervan?
Ik zoek 'iets' dat simpeler is dan ansible maar wel beter is dan mijn huidige manier: notepad++ met compose files hier en daar zonder enige versioning of automatisering en af en toe nog een docer run erbij ook als de guide dat voorstelt.

Dat dit niet goed werkt heb ik ondertussen door, maar hoe start ik de weg naar iets beter? Weet dat ik noch Linux guru, noch coder ben maar wel wil leren.

Zit zelf op Windows PC met docker op een Proxmox Host met Docker VM.

- VSCode? na installeren Connect to docker host? Verder helaas option overload dus nog steeds geen idee hoe ik het nu echt zou gebruiken.
EDIT: ok, 'gewoon' SSH naar de docker en je kan rechtstreeks op die machine compose file sbeheren met leuke kleurtjes

- Git? Self-hosted? lab? hub? hoe

Hoe hangt dit allemaal aan elkaar?

Ik ben recentelijk aan mijn Homelab avontuur begonnen (en dus ook nog een redelijke leek, maar met mijn IT achtergrond wel heel snel lerende) en heb daarvoor Unraid draaien, met daarop een container met de app Dockhand.

Dit is een container manager waar je heel gemakkelijk al je docker apps kunt beheren. Er zit al een goede compose/env editor in verwerkt, maar deze doet niet aan versiebeheer.

Daarom heb ik Gitea lokaal gehost en deze gekoppeld aan mijn lokaal gehoste Code Server (VS Code) zodat ik nu Code Server gebruik voor het schrijven van m'n yaml/env files, en gitea gebruik voor het bewaren van mijn files en het versiebeheer daarop. Gitea kun je vervolgens weer aan dockhand koppelen zodat je na een commit eventueel automatisch je containers kan laten redeployen.

Dit alles was zelfs voor mij als beginner "relatief" eenvoudig te installeren. Ik heb alles uitgebreid gedocumenteerd (welliswaar in het engels en door AI) maar beschrijft exact alle benodigde stappen en bevat ook mijn deelbare config files. Mocht je interesse hebben dan stuur me maar een DM.

[divvid]

docker compose vraagje: mijn script geeft output over iteraties. Als ik het run met

code:

docker run

dan krijg ik direct de output. Als ik docker compose build/up gebruik, dan krijg ik de output pas als alle iteraties klaar zijn (en dat is nou net niet de bedoeling).

Hoe kan ik dat oplossen
script is een simpel python ding in python 3.11-slime image

[RobertMe]

divvid schreef op zaterdag 2 mei 2026 @ 12:34:
docker compose vraagje: mijn script geeft output over iteraties. Als ik het run met

code:

docker run

dan krijg ik direct de output. Als ik docker compose build/up gebruik, dan krijg ik de output pas als alle iteraties klaar zijn (en dat is nou net niet de bedoeling).

Hoe kan ik dat oplossen
script is een simpel python ding in python 3.11-slime image

Als ik docker compose up doe dan zie ik gewoon live alle stdout / stderr output van de container (/software in de container). Note: zonder -d dus, dan draait die op de achtergrond en zie je dus helemaal geen output.

[dehardstyler]

Wienen schreef op woensdag 22 april 2026 @ 09:20:
[...]


Ik ben recentelijk aan mijn Homelab avontuur begonnen (en dus ook nog een redelijke leek, maar met mijn IT achtergrond wel heel snel lerende) en heb daarvoor Unraid draaien, met daarop een container met de app Dockhand.

Dit is een container manager waar je heel gemakkelijk al je docker apps kunt beheren. Er zit al een goede compose/env editor in verwerkt, maar deze doet niet aan versiebeheer.

Daarom heb ik Gitea lokaal gehost en deze gekoppeld aan mijn lokaal gehoste Code Server (VS Code) zodat ik nu Code Server gebruik voor het schrijven van m'n yaml/env files, en gitea gebruik voor het bewaren van mijn files en het versiebeheer daarop. Gitea kun je vervolgens weer aan dockhand koppelen zodat je na een commit eventueel automatisch je containers kan laten redeployen.

Dit alles was zelfs voor mij als beginner "relatief" eenvoudig te installeren. Ik heb alles uitgebreid gedocumenteerd (welliswaar in het engels en door AI) maar beschrijft exact alle benodigde stappen en bevat ook mijn deelbare config files. Mocht je interesse hebben dan stuur me maar een DM.

Ik vind Dockhand ook top, gebruik het nu 3 maanden ofzo denk ik. Gebruik je hierbij dan gevulde .env files? Ik zit nu nog elke keer in een Github private repo te klooien, maar zelfs daar wil ik geen secrets in etc, dus dan moet ik weer met .env.example werken. Misschien moet ik het ook maar gewoon lokaal hosten.

[synoniem]

dehardstyler schreef op zaterdag 2 mei 2026 @ 13:16:
[...]


Ik vind Dockhand ook top, gebruik het nu 3 maanden ofzo denk ik. Gebruik je hierbij dan gevulde .env files? Ik zit nu nog elke keer in een Github private repo te klooien, maar zelfs daar wil ik geen secrets in etc, dus dan moet ik weer met .env.example werken. Misschien moet ik het ook maar gewoon lokaal hosten.

Dat is de reden dat ik voorheen Gitea nu Forgejo lokaal (in docker) heb draaien. Heb je en een git-repo en een docker registry en de mogelijkheid van actions/runners.

[Wienen]

dehardstyler schreef op zaterdag 2 mei 2026 @ 13:16:
[...]


Ik vind Dockhand ook top, gebruik het nu 3 maanden ofzo denk ik. Gebruik je hierbij dan gevulde .env files? Ik zit nu nog elke keer in een Github private repo te klooien, maar zelfs daar wil ik geen secrets in etc, dus dan moet ik weer met .env.example werken. Misschien moet ik het ook maar gewoon lokaal hosten.

Mijn .env zijn voorzien van alle variabelen en de bijbehorende waardes. Enkel de variabelen van mijn secrets zijn niet voorzien van waardes. Bij het toevoegen van een nieuwe stack importeer ik mijn yaml/env vanuit gitea, dockhand geeft dan aan dat de waardes voor mijn secret variabelen nog handmatig ingevuld moeten worden. Dit doe ik vanuit mijn password manager (zodat ik deze nog wel ergens achter de hand heb) en druk dan op het sleuteltje zodat ze in de vault van Dockhand opgeslagen worden. Vanaf dat moment zijn ze in Dockhand ook niet meer uit te lezen. (vandaar het gebruik van de PW manager)

[dehardstyler]

Wienen schreef op zaterdag 2 mei 2026 @ 14:29:
[...]


Mijn .env zijn voorzien van alle variabelen en de bijbehorende waardes. Enkel de variabelen van mijn secrets zijn niet voorzien van waardes. Bij het toevoegen van een nieuwe stack importeer ik mijn yaml/env vanuit gitea, dockhand geeft dan aan dat de waardes voor mijn secret variabelen nog handmatig ingevuld moeten worden. Dit doe ik vanuit mijn password manager (zodat ik deze nog wel ergens achter de hand heb) en druk dan op het sleuteltje zodat ze in de vault van Dockhand opgeslagen worden. Vanaf dat moment zijn in Dockhand ook niet meer uit te lezen. (vandaag het gebruik van de PW manager)

Dat is nog mooier indd! Ik ga ef knutselen binnenkort.

[Wienen]

Succes 💪🏻 en bij vragen weet je me te vinden!

[divvid]

@RobertMe dat was dus ook wat ik veronderstelde, maar dat gebeurt dus niet. Het lijkt wel of alle output gecached wordt en pas aan het einde van het script weergegeven wordt. Overigens draai ik zonder -d

Inmiddels opgelost. Niet zozeer een docker dingetje, maar een python dingetje. Blijkbaar buffert python de output in non-shell envs.

In de yaml file moet je

code:

environment:
      - PYTHONUNBUFFERED=1

specificeren, anders wordt de output door python blijkbaar gebufferd.
typisch zo'n dingetje waar je een paar uur op stuk bijt. (google was ook niet erg behulpzaam)

[ Voor 47% gewijzigd door divvid op 03-05-2026 15:31 ]

[Mars Warrior]

Ik merkte in mijn CrowdSec-setup wederom dat domme gedoe dat vpatches niet tot een decision leiden omdat CrowdSec dat pas doet als een IP-adres verschillende vpatches raakt. Reden: voorkomen van false positives als een gebruiker 'per ongeluk' een vpatch raakt.

Tuurlijk. Die gaat 'per ongeluk' toegang tot een .env file oid vragen

Oftewel: duizenden onnodige Alerts...

Werd dus tijd voor een aangepaste profiles.yaml...

YAML:

name: force_vpatch_ban
filters:
  - Alert.GetScenario() == "crowdsecurity/appsec-vpatch"
decisions:
  - type: ban
    duration: 4h
on_success: break

.
En hoppa, weg met die idiote onnodige rode Alert blokken



Nu blijf ik waarschijnlijk ook weer netjes binnen de 500 alerts per maand voor het gratis account

Verder ga ik nog wat experimenteren met mTLS. Sommige apps ondersteunen dit, dus zou ik nog wat minder alerts binnenkrijgen omdat zo'n bot al helemaal geen verbinding meer kan opbouwen…

Moet wel zeggen dat adoptie traag is. Bitwarden doet er al een jaar over om het in de iOS-app te bouwen, laat staan in de Windows-app. Moeilijk hoor die paar regels code om een certificaat mee te geven. Echt heel moeilijk, en het past elke keer net niet binnen het release window

Self-hosting heeft natuurlijk niet zo veel prioriteit als de eigen stack.

[Le Enfant!]

Edit: Opgelost door 'block bogon network' uit te schakelen in de VLAN interface in Opnsense.

Ik ben nu al een kleine week aan het proberen om een L2 ipvlan aan te maken om een aantal containers binnen een VLAN te beheren, maar dit wil maar niet lukken.
Ik heb de ipvlan aangemaakt met volgend command:
[code]
docker network create -d ipvlan \
--subnet=192.168.X.0/24 \
--gateway=192.168.X.1 \
-o parent=enp5s0.4 \
br0.4
[/code]
Volgende werd in de docker compose file geplaatst per container:
[code]services:
test:
image: test
container_name: test
networks:
br0.4:
ipv4_address: "192.168.X.3"
ports:
- 7878:7878
restart: unless-stopped


networks:
br0.4:
external: true
name: br0.4[/code]

De port van de container staat gedefinieerd in deze file, maar bij het testen heb ik dit weggelaten in de docker compose.

Als ik vanaf mijn laptop de web interface van de containers probeer te bereiken, dan krijg ik een foutmelding dat de pagina niet kan bereikt worden.
Als ik ping vanaf de VLAN van de laptop of vanaf de opnsense firewall naar een IP binnen de IPvlan, dan krijg ik geen reply.
Als ik een trace laat lopen vanaf de VLAN van de laptop of vanaf de firewall naar een IP binnen de IPvlan, dan krijg ik een reply tot en met de fysieke docker host. Maar vanaf dan krijg ik geen reply.
Als ik ping vanuit de docker containers naar de default gateway, dan krijg ik geen reply. Als ik ping vanaf de container naar andere containers binnen de IPvlan, dan lukt dit wel. Pingen naar de docker host lukt dan weer niet, maar dit is normaal gedrag volgens de documentatie van Docker.

Wat heb ik tot nu toe allemaal geprobeerd:
- promiscuous mode ingeschakeld op zowel de docker host als de VLAN interface op de opnsense firewall,
- als test een static route aangemaakt op zowel de docker host, docker container als op de opnsense firewall
- port forwarding op de docker host ingeschakeld
- de poort van de switch waar de fysieke docker host mee is verbonden aangepast naar een trunk port.
- Als test een macvlan netwerk aangemaakt, maar daar hetzelfde probleem
- Als test een L3 IPvlan aangemaakt met een static route en dat lukt wel. Maar dan loopt al het verkeer binnen de VLAN van de docker host en niet op de VLAN van de containers.

In principe zou het moeten lukken volgens de Docker documentatie en volgens Claude, maar toch wil het maar niet werken. Ik heb tevens nog eens alles overlopen met Claude, maar daar draaien we ondertussen ook rondjes.

Iemand die me op weg kan helpen om dit probleem op te lossen? Ik zie even door de bomen het bos niet.

[Arunia]

Na ondertussen allerlei dingen gefixt te hebben ook buiten Docker om.
Ga ik toch kijken of ik binnenkort Docker Desktop onder Windows kan uit faseren en over te stappen naar iets anders, of gewoon plat WSL2. Maar blijf het spannend vinden om "opnieuw" te beginnen. Plat een backup maken lijkt niet mogelijk te zijn zodat ik die weer terug kan zetten in een nieuwe omgeving. Heb hier echt al tig keer naar gezocht. Maar eerlijk is eerlijk, zoveel dingen draai ik nog niet welke of een backup nodig hebben of eigenlijk wel met een eigen backup deels teruggezet kunnen worden.
Veel is nog in de teststadium, maar het voelt moeilijk om gewoon te zeggen dat ik genoeg in een backup heb zitten en Docker Desktop deinstalleer en dan of iets nieuws, of gewoon Portainer onder WSL2 docker draai.

Ja, ik ben een twijfelaar en altijd geweest.

[Wienen]

Ik ben een paar maanden geleden geswitcht van Windows (met docker desktop) naar Unraid. Dit is allemaal probleemloos verlopen. Het kost wel wat tijd, en Unraid/Linux was nieuw voor me maar met een beetje IT kennis/afiniteit kom je een heel eind!

Wil je dezelfde hardware blijven gebruiken of ga je er iets langs opbouwen? Als je er nieuwe hardware langs gaat plaatsen is het helemaal makkelijk, dan kun je eenvoudig je compose/env files en bijbehorende data overzetten en alles draait probleemloos verder. Ik ben op dezelfde hardware om gegaan en heb mijn Windows installatie omgezet naar een VM welke ik vervolgens weer binnen Unraid gemount heb om zo alles makkelijker over te kunnen zetten en altijd nog iets had om op terug te vallen.

[Arunia]

Wienen schreef op maandag 15 juni 2026 @ 16:12:
Ik ben een paar maanden geleden geswitcht van Windows (met docker desktop) naar Unraid. Dit is allemaal probleemloos verlopen. Het kost wel wat tijd, en Unraid/Linux was nieuw voor me maar met een beetje IT kennis/afiniteit kom je een heel eind!

Wil je dezelfde hardware blijven gebruiken of ga je er iets langs opbouwen? Als je er nieuwe hardware langs gaat plaatsen is het helemaal makkelijk, dan kun je eenvoudig je compose/env files en bijbehorende data overzetten en alles draait probleemloos verder. Ik ben op dezelfde hardware om gegaan en heb mijn Windows installatie omgezet naar een VM welke ik vervolgens weer binnen Unraid gemount heb om zo alles makkelijker over te kunnen zetten en altijd nog iets had om op terug te vallen.

Ik blijf gewoon bij Windows omdat ik er ook andere dingen bij heb. Ik wil Docker Desktop weg hebben omdat ik ondertussen wel weet dat er weinig extra bij komt kijken en ik heb het idee dat DD steeds meer verbruikt terwijl er eigenlijk weinig bij is gekomen.
Tuurlijk is een linux variant beter in het opzicht van Docker, maar op dit moment nog geen reden voor mij om over te stappen.

Daarnaast ook gewoon deze hardware nog. Is redelijk zuinig en nog prima voor ons gebruik. Nou ja, mijn gebruik haha.
Zodra docker goed draait en in gebruik is, kan ik altijd kijken naar een upgrade. Maar voor nu qua prijzen niet echt nuttig om die stap te maken.

/edit:
Ik heb nu net Docker Desktop verwijderd... Here goes nothing! Moet toch ergens beginnen. Ben benieuwd wat het geheugen verbruik gaat doen nadat WSL2 ingesteld is met Docker.
Verwijderen van DD zorgt ook voor het verwijderen van de VM met Docker erin. Ging er niet vanuit, maar had wel een backup van wat ik echt met alles erbij terug wilde hebben.

[ Voor 10% gewijzigd door Arunia op 16-06-2026 11:18 ]

[Wienen]

De reden dat ik van Docker Desktop/Windows ben afgestapt is omdat dit toch niet echt lekker performde, en ik zaken beter wou isoleren. Daarnaast bleek na onderzoek dat 99% van de applicaties welke ik gebruikte er ook een docker image van was.

Voor het andere deel heb ik een Windows VM opgetuigd binnen Unraid zodat ik daar altijd nog op terug kan vallen.

Succes met je migratie 💪🏻

[Arunia]

@Wienen Voor zover zal het bij mij nooit een hele grote omgeving worden. Wel is me opgevallen dat het sinds een half jaar ontzettend veel verbruikt. Mits dat het gedeelte was hoor.

Qua installeren met tutorials is het niet heel erg makkelijk.
Enige wat ik zoek is WSL2, Docker en Docker-Compose met dezelfde uitkomst als middels Docker Desktop.
Alleen om één of andere reden loop je toch tegen vage problemen aan.
Docker hello-world doet het in ieder geval. Alleen nu Portainer dan nog wat ik dan het liefste via docker-compose doe, maar wellicht moet ik daar gewoon vanaf stappen.
Zodra portainer erop staat, kan ik kijken of ik daar bij kom en of het naar buiten toe in het netwerk zelf ook werkt.

Enige voordeel is dat DD dit wel automagisch doet voor je. Genoeg mensen die het zonder DD willen, maar om één of andere reden is iedere uitleg weer anders. Wellicht toch dat iedereen het anders doet.

Maar, het lijkt erop dat Portainer nu wel geinstalleerd is. Volgende stap is automatisch laten starten bij een herstart van Windows. Zelfde probleem met Docker Desktop, maar ook dat is opgelost. Startte hiervoor eerst Windows en dan een batch bestand welke Windows weer locked. >_>

[ Voor 13% gewijzigd door Arunia op 16-06-2026 17:19 ]

[Mars Warrior]

Om nog even terug te komen op een onderwerp van denk ik 6 maanden geleden

Op het werk heeft men een server bijeengesprokkeld. Die is dus gratis vanuit de boekhouding gezien, maar heeft wel een 24 core Xeon, 256GB RAM, en over het 10/40GBit netwerk SSD storage

Dus dat is geregeld. Nu ging het tig maanden geleden over het inrichten van deze server. Hij draait op Proxmox + PBS. Ik ga daar 2 VMs maken:

• een VM voor GitOps
• een VM voor productie

Het grootste punt zit in het onderhoud van alle containers. Dus Ansible gaat niet gebeuren

Ik neig nu sterk naar:

• Forgejo + runner
• Renovate
• Portainer BE (gratis voor 3 nodes) met Edge Agent op de productie node. Die kan vanuit Git een compose file met alles wat daarbij hoort halen en deployen. Klaar
• Mogelijk wat extra's per container om wat scripting en testen uit te voeren in plaats van de standaard image entry, en die dan aanroepen. Ben ik van alles af. Ook geen gezeur meer met depends_on bij reboot van server.

Zou perfect moeten werken volgens de documentatie.

Erbij:

Als ik meer controle wil hebben is Komodo ook een perfect alternatief. Die kan het bouwen van eigen containers en backuppen van databases ook overnemen. Is dat ook meteen verzorgd en hoef ik ook daar verder niks extra's voor te regelen.

Komodo kan ook met SOPS werken zodat alle .env files ook on the fly tijdens deployment gedecrypt worden. Een VScode plugin doet dat ook met decrypt/encrypt, dus dan kunnen er ook geen wachtwoorden en andere sleutels in git/forgejo komen.

Rathole zou ik dan daarbij als container kunnen gebruiken om een tunnel / bridge op te zetten, zodat ik nog zelf wel lekker met SSH en een browser (socks5) overal bij kan komen, zonder dat poort 22 open moet staan. Daar houden ze niet zo van...

[ Voor 24% gewijzigd door Mars Warrior op 17-06-2026 09:08 ]

[Arunia]

Vandaag Docker Engine in WSL2 draaiend waarbij ik Portainer op andere clients aan kan spreken.
Rustdesk en Mealie geinstalleerd waarbij er wel melding gegeven wordt dat de verbinding actief is, maar toch niet helemaal lekker werkt.
Mealie lijkt ook niet helemaal te werken. Container draait, maar daar kom ik dan weer niet bij. Aparte is dan weer dat bij mijn vorige niet Stack variant er 2 poorten open stonden en bij deze dat niet zo is. Maar goed, basis is gelegd. De rest komen we ook wel uit natuurlijk.

[Wienen]

Arunia schreef op woensdag 17 juni 2026 @ 16:25:
Vandaag Docker Engine in WSL2 draaiend waarbij ik Portainer op andere clients aan kan spreken.
Rustdesk en Mealie geinstalleerd waarbij er wel melding gegeven wordt dat de verbinding actief is, maar toch niet helemaal lekker werkt.
Mealie lijkt ook niet helemaal te werken. Container draait, maar daar kom ik dan weer niet bij. Aparte is dan weer dat bij mijn vorige niet Stack variant er 2 poorten open stonden en bij deze dat niet zo is. Maar goed, basis is gelegd. De rest komen we ook wel uit natuurlijk.

Ik wil graag met je meedenken, maar dan zul je toch wel met iets meer info moeten komen. Wellicht enkel ter info bedoeld

[Arunia]

Wienen schreef op woensdag 17 juni 2026 @ 18:47:
[...]

Ik wil graag met je meedenken, maar dan zul je toch wel met iets meer info moeten komen. Wellicht enkel ter info bedoeld

Haha, soms post ik gewoon inderdaad ter info. Dat niet altijd alles van een leien dakje gaat.
Maar het lijkt nu wel te werken, ook na een Windows herstart komt bijvoorbeeld Portainer weer op. Dus, Mijn WSL2 start automatisch en daarin Docker ook. Kostte wat moeite om de juiste uitleg te vinden.

Nu nog wat dingen fixen en het liefste had ik eigenlijk bepaalde mappen op Windows beschikbaar gehad, maar het is wat het is. Denk ook gewoon gewenning. Ik weet hoe het werkt en kan straks ook bepaalde media mappen beschikbaar maken.

[synoniem]

Arunia schreef op donderdag 18 juni 2026 @ 09:33:
[...]

Haha, soms post ik gewoon inderdaad ter info. Dat niet altijd alles van een leien dakje gaat.
Maar het lijkt nu wel te werken, ook na een Windows herstart komt bijvoorbeeld Portainer weer op. Dus, Mijn WSL2 start automatisch en daarin Docker ook. Kostte wat moeite om de juiste uitleg te vinden.

Nu nog wat dingen fixen en het liefste had ik eigenlijk bepaalde mappen op Windows beschikbaar gehad, maar het is wat het is. Denk ook gewoon gewenning. Ik weet hoe het werkt en kan straks ook bepaalde media mappen beschikbaar maken.

Windows mappen zijn toch in WSL2 beschikbaar onder /c/..........?

[Arunia]

synoniem schreef op donderdag 18 juni 2026 @ 17:41:
[...]

Windows mappen zijn toch in WSL2 beschikbaar onder /c/..........?

Klopt volgens mij wel. Kwam er andersom wel achter dat in verkenner je geen rechten hebt.

Daarnaast draait het spul nu wel gelukkig en volgens mij zonder echte problemen. Enige is dat het geheugen gebruik toch nog steeds tegen de 99 procent aan blijft tikken.
Kan zomaar iets anders zijn, maar heb het geheugen gelimiteerd naar 1100MB. Zoveel draait er nog niet.
Je zou zeggen dat 16GB voldoende moet zijn, maar blijkbaar valt dat tegen, terwijl ik best een tijd gewoon geen problemen heb gehad. Anders in deze dure tijden toch maar een upgrade zien te vinden naar 32GB. Moet dan wel de oude vervangen dan omdat ik maar 2 slots heb.

[Wienen]

Mijn unraid systeem waarop ik 26 containers heb draaien gebruikt in totaal maar 6,21GB. Waarvan deze containers slechts 2,74GB gebruiken en het Unraid OS 3,47GB. (OS is volledig in RAM geladen, ongeveer 1,5GB de rest zijn plugins)

Wat betreft geheugengebruik en performance was het echt een verademing om van Windows over te stappen naar Unraid. Al zal dit voor ieder Linux based OS gelden.

[Arunia]

Qua dat is het mij duidelijk, maar overstappen durf ik nog niet zo.

Heb het geheugen ingeperkt en het lijkt rond de 80 procent nu te zitten. Het vage is dat het vroeger geen probleem was en of het nu Windows 10 was of dan nu 11, heb ik geen idee van eigenlijk.

Voor nu de rechten veranderd zodat ik wel op die share kan bewerken, ofwel bestanden kan kopiëren. Dat scheelt weer een stap.

[synoniem]

Arunia schreef op woensdag 1 juli 2026 @ 19:23:
[...]

Klopt volgens mij wel. Kwam er andersom wel achter dat in verkenner je geen rechten hebt.

Daarnaast draait het spul nu wel gelukkig en volgens mij zonder echte problemen. Enige is dat het geheugen gebruik toch nog steeds tegen de 99 procent aan blijft tikken.
Kan zomaar iets anders zijn, maar heb het geheugen gelimiteerd naar 1100MB. Zoveel draait er nog niet.
Je zou zeggen dat 16GB voldoende moet zijn, maar blijkbaar valt dat tegen, terwijl ik best een tijd gewoon geen problemen heb gehad. Anders in deze dure tijden toch maar een upgrade zien te vinden naar 32GB. Moet dan wel de oude vervangen dan omdat ik maar 2 slots heb.

Je kan ook het geheugengebruik per container beperken. Onder linux heb ik dat in de regel niet nodig maar onder Windows schijnt het wel te helpen. Kan overigens ook zijn dat je een container hebt met een geheugenlek waardoor die steeds meer geheugen neemt.

[Arunia]

synoniem schreef op vrijdag 3 juli 2026 @ 01:20:
[...]

Je kan ook het geheugengebruik per container beperken. Onder linux heb ik dat in de regel niet nodig maar onder Windows schijnt het wel te helpen. Kan overigens ook zijn dat je een container hebt met een geheugenlek waardoor die steeds meer geheugen neemt.

Op dit moment heb ik het maximum geheugen gebruik op net geen 1100MB staan in .wslconfig.
De kans is zeer groot dat dat nog best veel is, maar dan zou er heel veel geheugen standaard in gebruik zijn. Dat is iets wat ik wel raar vind.
Qua containers heb ik Portainer, Mealie en Rustdesk draaien. Daar komen er nog wel meer bij, maar ik moet even uit zien te vogelen of ik het geheugen gebruik van de containers kan zien. Dit bedenk ik me aan de hand van je bericht natuurlijk, dus nog niet gezocht hierop.
Heb al even gekeken en het lijkt nog ruim onder de 1100MB te zitten. Mealie verbruikt wel verreweg het meeste.
Ben nu Dozzle aan het instellen om zo grafische inzicht te krijgen.

[ Voor 22% gewijzigd door Arunia op 03-07-2026 09:38 ]

[Wienen]

Je kunt in Portainer toch gewoon zien hoeveel geheugen je containers per stuk gebruiken? Ik ben niet bekend met portainer dus weet niet wat er met gemiddeld geheugen bedoeld wordt maar deze zijn al zo laag dat ik me haast niet voor kan stellen dat je containers het probleem zijn van het verhoogde geheugengebruik.

Open eens gewoon je taakbeheer binnen Windows en filter daar op geheugen, dan zie je precies wat je grootverbruikers zijn.

[DjoeC]

Arunia schreef op vrijdag 3 juli 2026 @ 08:56:
[...]

Op dit moment heb ik het maximum geheugen gebruik op net geen 1100MB staan in .wslconfig.
De kans is zeer groot dat dat nog best veel is, maar dan zou er heel veel geheugen standaard in gebruik zijn. Dat is iets wat ik wel raar vind.
Qua containers heb ik Portainer, Mealie en Rustdesk draaien. Daar komen er nog wel meer bij, maar ik moet even uit zien te vogelen of ik het geheugen gebruik van de containers kan zien. Dit bedenk ik me aan de hand van je bericht natuurlijk, dus nog niet gezocht hierop.
Heb al even gekeken en het lijkt nog ruim onder de 1100MB te zitten. Mealie verbruikt wel verreweg het meeste.
Ben nu Dozzle aan het instellen om zo grafische inzicht te krijgen.
[Afbeelding]

In Portainer kun je geheugen gebruik bekijken via de "stats" (statistieken) vzv beschikbaar. Ik heb (o.a.) Dozzle amir20/dozzle:latest draaien waar je het (gemiddeld) geheugengebruik van alle containers gelijk kunt zien - naast dat je meteen de logging vzv beschikbaar kunt bekijken.

Opmerkelijk: Op mijn raspberry pi met OMV 7 laat Docker zelf (sudo docker stats) het geheugen gebruik niet zien....

[Arunia]

Wienen schreef op vrijdag 3 juli 2026 @ 10:04:
Je kunt in Portainer toch gewoon zien hoeveel geheugen je containers per stuk gebruiken? Ik ben niet bekend met portainer dus weet niet wat er met gemiddeld geheugen bedoeld wordt maar deze zijn al zo laag dat ik me haast niet voor kan stellen dat je containers het probleem zijn van het verhoogde geheugengebruik.

Open eens gewoon je taakbeheer binnen Windows en filter daar op geheugen, dan zie je precies wat je grootverbruikers zijn.

Ik heb hier al eens meer naar gekeken en lijkt ook niet alsof WSL2 en docker het probleem is, maar kom er ook niet achter wat nu precies zoveel verbruikt. Er zijn wat losse programma's die draaien. Deze wil ik langzaamaan verplaatsen naar Docker. Twijfel nog over Plex, maar wellicht die ook.
Crashplan, WSL, Zulu verbruiken wel het meeste. Waarom Edge erbij staat is mij een raadsel. Ja, die heb ik soms open voor uitleg en dergelijke, maar nu was deze afgesloten.
Los van elkaar lijkt het allemaal niet zo heel veel, maar opgeteld loopt het wel hard op denk ik.
Maar met 16GB aan ram zou ik toch wel voldoende moeten hebben. Hiervoor had ik 8GB enkele DIMM en eigenlijk geen problemen. Alles is wel standaard geupdate.

[DjoeC]

Arunia schreef op vrijdag 3 juli 2026 @ 13:33:
[...]

[Afbeelding]

Ik heb hier al eens meer naar gekeken en lijkt ook niet alsof WSL2 en docker het probleem is, maar kom er ook niet achter wat nu precies zoveel verbruikt. Er zijn wat losse programma's die draaien. Deze wil ik langzaamaan verplaatsen naar Docker. Twijfel nog over Plex, maar wellicht die ook.
Crashplan, WSL, Zulu verbruiken wel het meeste. Waarom Edge erbij staat is mij een raadsel. Ja, die heb ik soms open voor uitleg en dergelijke, maar nu was deze afgesloten.
Los van elkaar lijkt het allemaal niet zo heel veel, maar opgeteld loopt het wel hard op denk ik.
Maar met 16GB aan ram zou ik toch wel voldoende moeten hebben. Hiervoor had ik 8GB enkele DIMM en eigenlijk geen problemen. Alles is wel standaard geupdate.

Verkijk je je misschien op wat er voor cache en andere "gebruik geheugen als beschikbaar" taken gebruikt wordt? Ik heb eenzelfde soort actieve taken lijst die niet optelt tot mijn totale geheugengebruik.....

[Arunia]

DjoeC schreef op vrijdag 3 juli 2026 @ 13:59:
[...]

Verkijk je je misschien op wat er voor cache en andere "gebruik geheugen als beschikbaar" taken gebruikt wordt? Ik heb eenzelfde soort actieve taken lijst die niet optelt tot mijn totale geheugengebruik.....
[Afbeelding]

Dit heb ik zeg maar. Jij hebt ruim meer geheugen dan dat ik heb en qua in gebruik zitten we op hetzelfde. Alleen ik heb minder totaal geheugen.

[Wienen]

@Arunia jouw processen gebruiken helemaal niet zoveel geheugen, ik kan me ook haast niet voorstellen dat deze bij elkaar opgeteld 95% van je RAM geheugen verbruiken. Ik zit op mijn Windows laptop met 16GB op 85% en heb vele grotere processen/apps draaien die 1,5 tot 2GB per stuk in beslag nemen.

Ik zou daar toch eens verder induiken. Wellicht dat WSL onderwater toch meer geheugen gebruikt wat Windows niet goed laat zien.

[Arunia]

Wienen schreef op vrijdag 3 juli 2026 @ 14:32:
@Arunia jouw processen gebruiken helemaal niet zoveel geheugen, ik kan me ook haast niet voorstellen dat deze bij elkaar opgeteld 95% van je RAM geheugen verbruiken. Ik zit op mijn Windows laptop met 16GB op 85% en heb vele grotere processen/apps draaien die 1,5 tot 2GB per stuk in beslag nemen.

Ik zou daar toch eens verder induiken. Wellicht dat WSL onderwater toch meer geheugen gebruikt wat Windows niet goed laat zien.

Dat heb ik dus ook. Het is dat de CPU niet zo veel in gebruik is, anders zou ik denken dat ik gehacked ben en er een miner draait op de server. Maar ook daar heb ik al eens naar gezocht.
Na herstart zit ik vaak wel op 85%, maar dat loopt wel iets op. Blijf het apart vinden, mijn eigen pc staat ook veel lager, maar goed, potato, potato en niet echt te vergelijken. Of ik moet daar dezelfde dingen op draaien.

Sowieso wat ik al zei, vind ik het vreemd dat het een jaar of iets langer geleden niet zo was. Maar ja, wie weet dat het ergens een Windows update is geweest die het verbruik omhoog gooit.
Ik heb er al eens zo'n programma tegenaan gegooid, maar ook die gaf me niet echt de uitkomst.
WSL2 heb ik op max 1100MB gezet qua ram geheugen. Dus meer dan dat zal die niet moeten gebruiken en zo te zien gebeurd dat ook niet echt. Home Assistant verbruikt ook niet zoveel.

Weet niet echt hoe ik het moet troubleshooten eigenlijk. Ik weet dat het gewoon mogelijk moet zijn om ruim lager in verbruik te zitten.

[ Voor 11% gewijzigd door Arunia op 03-07-2026 15:51 ]

[DjoeC]

Arunia schreef op vrijdag 3 juli 2026 @ 15:50:
[...]

Dat heb ik dus ook. Het is dat de CPU niet zo veel in gebruik is, anders zou ik denken dat ik gehacked ben en er een miner draait op de server. Maar ook daar heb ik al eens naar gezocht.
Na herstart zit ik vaak wel op 85%, maar dat loopt wel iets op. Blijf het apart vinden, mijn eigen pc staat ook veel lager, maar goed, potato, potato en niet echt te vergelijken. Of ik moet daar dezelfde dingen op draaien.

Sowieso wat ik al zei, vind ik het vreemd dat het een jaar of iets langer geleden niet zo was. Maar ja, wie weet dat het ergens een Windows update is geweest die het verbruik omhoog gooit.
Ik heb er al eens zo'n programma tegenaan gegooid, maar ook die gaf me niet echt de uitkomst.
WSL2 heb ik op max 1100MB gezet qua ram geheugen. Dus meer dan dat zal die niet moeten gebruiken en zo te zien gebeurd dat ook niet echt. Home Assistant verbruikt ook niet zoveel.

Weet niet echt hoe ik het moet troubleshooten eigenlijk. Ik weet dat het gewoon mogelijk moet zijn om ruim lager in verbruik te zitten.

Misschien kun je hier iets mee? Je doet iig aan paging, het lijkt alsof je 16GB in je PC hebt met een 16GB paging file. Je hebt meer dan 16GB in gebruik en dus moet Windows ook paging gaan managen. Dan zit je ook nog met alle processen die filehandles hebben openstaan - vermoedelijk veel in R-W en niet read only waardoor ze niet vrijgegeven kunnen worden. En onder Docker zou het me niet verbazen als dat flink grotere aantallen zijn als je de Docker file structuren bekijkt......

Maar - dit is zeker niet mijn expertise, ik draai Docker juist onder Linux omdat ik over Linux veel makkelijker inhoudelijke informatie kan vinden (en omdat een Pi met SSD veel minder verbruik heeft bij 24/7), ook daar ben ik geen specialist in.....

O ja, voor de duidelijkheid: Windows pakt al het vrije geheugen voor filecaching en read-ahead. Ook daar zit misschien nog iets om uit te zoeken? Ik denk nu ook aan "uitgestelde writes" - dat kun je uitschakelen dan wordt die ruimte vrij gegeven. Even zoeken waar die optie zit...

Per disk instelbaar: https://help.2brightspark...rror-message-from-windows

[ Voor 9% gewijzigd door DjoeC op 03-07-2026 16:06 ]

[Arunia]

DjoeC schreef op vrijdag 3 juli 2026 @ 15:58:
[...]

Misschien kun je hier iets mee? Je doet iig aan paging, het lijkt alsof je 16GB in je PC hebt met een 16GB paging file. Je hebt meer dan 16GB in gebruik en dus moet Windows ook paging gaan managen. Dan zit je ook nog met alle processen die filehandles hebben openstaan - vermoedelijk veel in R-W en niet read only waardoor ze niet vrijgegeven kunnen worden. En onder Docker zou het me niet verbazen als dat flink grotere aantallen zijn als je de Docker file structuren bekijkt......

Maar - dit is zeker niet mijn expertise, ik draai Docker juist onder Linux omdat ik over Linux veel makkelijker inhoudelijke informatie kan vinden (en omdat een Pi met SSD veel minder verbruik heeft bij 24/7), ook daar ben ik geen specialist in.....

Thanks, ik zal daar ook eens in duiken. Uiteindelijk zal ik het wel vinden, dat weet ik zeker en voor nu draait het onder de 99% wat ook scheelt.
Maar wil er nog een stuk meer dingen onder draaien en dan voorkomen dat het wel weer tegen zijn max aan loopt.

[3DDude]

Taak beheer >> Performance tab >> rechts bovenin op de ... jes klikken en resource manager openen.
Kijken of je daar wat kan vinden.

en anders WSL tuning opzoeken.
https://devalice.jaceclub...slconfig--ramcpuswap-caps

Ik ben voor mijzelf ook is kijken, heb 100GB in cached staan dus vind het bij jou weinig...

[ Voor 16% gewijzigd door 3DDude op 03-07-2026 16:04 ]

[DjoeC]

Arunia schreef op vrijdag 3 juli 2026 @ 16:03:
[...]

Thanks, ik zal daar ook eens in duiken. Uiteindelijk zal ik het wel vinden, dat weet ik zeker en voor nu draait het onder de 99% wat ook scheelt.
Maar wil er nog een stuk meer dingen onder draaien en dan voorkomen dat het wel weer tegen zijn max aan loopt.

Aan Docker hoeft het niet te liggen... Ik draai 20+ containers op een 16GB Raspi 5 met 4TB SSD. Die deden t op een 8GB Pi4 met 2TB sata SSD ook zonder issues.

[Arunia]

@3DDude Ik zie heel veel Java er tussen staan qua 160.000KB per onderdeel als werkset en allemaal rond de 200.000KB als Toegewezen. Kan van alles zijn natuurlijk, maar als er 20 staan is het weinig, dan telt het wel op. Dus daar moet ik verder in gaan duiken. Alhoewel ze allemaal grijs zijn en af en toe opspringen naar zwart. Geen idee wat het verder betekent, maar ook daar zal ik eens naar kijken. Ik maar overigens gebruik van Zulu Java.
WSL lijkt toegewezen op 1.118.660KB en werkset is 360KB. Die zou ik omlaag kunnen gooien, maar dan moet ik daar goed op letten dat deze niet vol loopt en ik dat niet door heb.


Als ik kijk naar harde fouten, dan is dat bij memory compression vooral, maar loopt ook niet op andere vlakken hard omhoog. Maar met het geheugen wat vrij hoog ligt, is het geheugen op dit moment niet echt toereikend.

@DjoeC Ik denk inderdaad dat het ook niet aan WSL2 of Docker ligt.

[ Voor 3% gewijzigd door Arunia op 03-07-2026 16:22 ]

[3DDude]

je kan op kolom filteren he, van hoog naar laag enzo..

[Wienen]

Ik zou toch eens gaan onderzoeken waar die java.exe vandaan komen

[Mars Warrior]

Wienen schreef op vrijdag 3 juli 2026 @ 19:29:
Ik zou toch eens gaan onderzoeken waar die java.exe vandaan komen

Ach. Crashplan is in Java geschreven en heeft per TB aan backup weer x GB nodig aan RAM.

Ik heb slechts 2TB aan backups en de Crashplan docker container gebruikt 22GB RAM

[Wienen]

Mars Warrior schreef op vrijdag 3 juli 2026 @ 20:45:
[...]

Ach. Crashplan is in Java geschreven en heeft per TB aan backup weer x GB nodig aan RAM.

Ik heb slechts 2TB aan backups en de Crashplan docker container gebruikt 22GB RAM

Haha dan hebben we de boosdoener wellicht gevonden

Maar wat is er zo bijzonder aan Crashplan dat je daar aan vast blijft houden als deze zoveel geheugen vreet?

Ik heb m'n backup volledig ingericht met Rustic i.c.m. XyOps voor de backup workflows, en waar Rustic enkel tijdens de backup job even wat geheugen gebruikt draait er verder buiten de job om niks. Werkt als een zonnetje.

[Arunia]

@3DDude Dat sorteren had ik gedaan. Vandaar deze uitkomst. Ook op naam om te zien hoeveel Java.exe onderdelen er voorbij kwamen.
@Wienen Zeker. Het is denk ik met de uitleg van @Mars Warrior wel duidelijk wat er precies gebeurd.
Ik heb 16TB in mijn server zitten en nee, niet alles is vol en niet alles wordt gebackupped.
Waarom ik vast blijf houden aan Crashplan is denk ik het gemak en nog niet iets anders gevonden wat simpel werkt eigenlijk. Betaal er ook maandelijks voor en buiten dat het echt takken traag is (opnieuw backup gemaakt na aangevraagd te hebben over te laten zetten naar een datacenter in Ierland en deze 2 maanden bezig is geweest ), werkt het vrij simpel. Voor nu nog geen zin gehad om opnieuw iets uit te zoeken en gaan leren. Daarnaast is het meeste nog duurder per maand. Tja, komt vast nog wel een keer.
Maar zal eens kijken of real time naar alleen in de nacht overzetten het op zal lossen. In de nacht maakt het verbruik me sowieso weinig uit.

[DjoeC]

Arunia schreef op zaterdag 4 juli 2026 @ 01:33:
@3DDude Dat sorteren had ik gedaan. Vandaar deze uitkomst. Ook op naam om te zien hoeveel Java.exe onderdelen er voorbij kwamen.
@Wienen Zeker. Het is denk ik met de uitleg van @Mars Warrior wel duidelijk wat er precies gebeurd.
Ik heb 16TB in mijn server zitten en nee, niet alles is vol en niet alles wordt gebackupped.
Waarom ik vast blijf houden aan Crashplan is denk ik het gemak en nog niet iets anders gevonden wat simpel werkt eigenlijk. Betaal er ook maandelijks voor en buiten dat het echt takken traag is (opnieuw backup gemaakt na aangevraagd te hebben over te laten zetten naar een datacenter in Ierland en deze 2 maanden bezig is geweest ), werkt het vrij simpel. Voor nu nog geen zin gehad om opnieuw iets uit te zoeken en gaan leren. Daarnaast is het meeste nog duurder per maand. Tja, komt vast nog wel een keer.
Maar zal eens kijken of real time naar alleen in de nacht overzetten het op zal lossen. In de nacht maakt het verbruik me sowieso weinig uit.

Gebruik je het voor Windows of voor Linux? Ik gebruik Backblaze Personal met onbeperkte data. De agent werkt alleen onder Windows en dus heb ik wat ingericht om de relevante Linux meuk naar een Windows disk te backuppen. Momenteel > 20TB bij hen staan, in Amsterdam. In 2024 USD 229,- betaald voor 2 jaar (incl BTW). Zal dit jaar wel een paar tientjes meer worden maar ik kan er geen schijf voor kopen. 1e backup duurde wel een dikke week, nu blijft ie op de achtergrond prima bij. Maar, er zijn een paar grotere backup topics hier in het forum.

Aanvulling: Als je bij Backblaze eem vinkje zet bewaren ze "alle" file versies gedurende 1 jaar. Een aantal files zijn excluded maar mijn backups niet. Die bewaar ik dus een tijdje lokaal, daarna mag BB het voor mij doen. Dat scheelt bij volume backups (Acronis backup van C+D schijf) best een hoop lokale opslag.

[ Voor 8% gewijzigd door DjoeC op 04-07-2026 15:32 ]

[Arunia]

DjoeC schreef op zaterdag 4 juli 2026 @ 12:58:
[...]

Gebruik je het voor Windows of voor Linux? Ik gebruik Backblaze Personal met onbeperkte data. De agent werkt alleen onder Windows en dus heb ik wat ingericht om de relevante Linux meuk naar een Windows disk te backuppen. Momenteel > 20TB bij hen staan, in Amsterdam. In 2024 USD 229,- betaald voor 2 jaar (incl BTW). Zal dit jaar wel een paar tientjes meer worden maar ik kan er geen schijf voor kopen. 1e backup duurde wel een dikke week, nu blijft ie op de achtergrond prima bij. Maar, er zijn een paar grotere backup topics hier in het forum.

De backup topics ken ik inderdaad. Kom er zelf ook om zo nu en dan eens te kijken of er wat nieuws is.
Qua prijs zit ik nu aan de 13 euro of iets per maand.
Ik gebruik het voor Windows. Dus dat zeker een optie kunnen zijn.

[Mars Warrior]

Wienen schreef op vrijdag 3 juli 2026 @ 21:26:
[...]

Haha dan hebben we de boosdoener wellicht gevonden

Maar wat is er zo bijzonder aan Crashplan dat je daar aan vast blijft houden als deze zoveel geheugen vreet?

Ik heb m'n backup volledig ingericht met Rustic i.c.m. XyOps voor de backup workflows, en waar Rustic enkel tijdens de backup job even wat geheugen gebruikt draait er verder buiten de job om niks. Werkt als een zonnetje.

Dat heeft te maken met een stukje historie. Voorheen kon je met CrashPlan gratis naar een andere server back-uppen. Dus een Remote back-up. Dan hebben ze dat uitgesloopt en moest je gaan betalen. Dat was in het begin behoorlijk goedkoop. Ik meen iets van € 60 terwijl ik iets van 10 terabyte had als back-up.

Daarna is CP allerlei beperkingen in gaan voeren. En het is inderdaad zo traag als dikke stront. En het kost inderdaad veel ram geheugen. Maar mijn 128 GB ram stamt nog uit de tijd dat je daar € 300 voor betaalde 🫣

Dus ik zit wel naar een alternatief te kijken, maar dat heeft absoluut geen haast.

[tikkietrugjaap]

Ik loop tegen een probleem aan waarvan ik hoop dat jullie mij richting een oplossing kunnen wijzen.

Hier een deel van mijn compose file met één container als voorbeeld.

YAML:

networks:
  vadjnet:
    driver_opts:
      com.docker.network.bridge.name: vadjnet
    ipam:
      config:
        - subnet: 172.20.0.0/16
services:
  swag:
    image: lscr.io/linuxserver/swag
    container_name: swag
    cap_add:
      - NET_ADMIN
#    sysctls:
#      - net.ipv6.conf.all.disable_ipv6=1
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
      - URL=${DUCKDNSURL}
      - SUBDOMAINS=wildcard
      - VALIDATION=duckdns
        #      - CERTPROVIDER= #optional
        #      - DNSPLUGIN=cloudflare #optional
      - DUCKDNSTOKEN=${DUCKDNSTOKEN}
        #      - EMAIL=<e-mail> #optional
        #      - ONLY_SUBDOMAINS=false #optional
        #      - EXTRA_DOMAINS=<extradomains> #optional
        #      - STAGING=false #optional
    volumes:
      - ${DATA}/swag/config:/config
    ports:
      - 0.0.0.0:443:443
#      - 80:80 #optional
    networks:
      vadjnet:
        ipv4_address: 172.20.0.2
#    dns:
#      - 192.168.41.1
    restart: unless-stopped

Ik heb een proxmoxserver waarop meerdere VM's draaien. Sommige VM's draaien Docker met een aantal containers. De containers draaien op een eigen dockernetwerk zodat de containers elkaar makkelijk kunnen vinden op slechts hun containernaam (bijvoorbeeld swag of qbittorrent).

Het fysieke netwerk bestaat uit een Opnsense router met DNSMasq en Unbound waardoor ik via DHCP IP-adressen uitdeel en de hostname van deze hosts FQDN zijn op het netwerk (bijvoorbeeld desk9800.home.internal).

Het probleem wat ik heb is dat hostnames van hosts op het fysieke netwerk niet op een gebruikelijke manier kunnen worden benaderd vanuit de containers. Wat ik daar mee bedoel is dat een standaard ping vanuit een container naar een host (bijvoorbeeld van de swag container naar desk9800.home.internal) resulteert in:

ping: bad address 'desk9800.home.internal' 

Aanvankelijk dacht ik dat er iets met DNS niet goed ging maar een nslookup vanuit de container resulteert in:

Server:         127.0.0.11
Address:        127.0.0.11:53
Non-authoritative answer:
Name:   desk9800.home.internal
Address: 192.168.10.103
** server can't find desk9800.home.internal: SERVFAIL

Het IP adres van de host wordt wel gevonden. De SERVFAIL komt vermoedelijk omdat nslookup ook ipv6 uitvraagt en er geen ipv6 op het netwerk word gebruikt.

Omdat nslookup laat zien dat DNS, ook binnen de container, lijkt te werken ging ik verder zoeken. Uiteindelijk ben ik op het idee gekomen om bij ping de "-4" optie te gebruiken. Hierdoor wordt ping gedwongen ipv4 te gebruiken. Dit resulteert in:

PING desk9800.home.internal (192.168.10.103): 56 data bytes

Mijn conclusie is daarom dat ik ergens iets niet goed heb ingesteld waardoor commando's zoals ping primair naar ipv6 kijken en vervolgens een error geven. In een poging om ipv6 zoveel mogelijk uit te schakelen binnen Docker heb ik het volgende geprobeerd, alles zonder succes.

1. "ipv6": false toevoegen aan /etc/docker/daemon.json.
2. sysctls:
   - net.ipv6.conf.all.disable_ipv6=1
   toevoegen aan de desbetreffende container in de compose file.

Mijn vraag aan jullie is daarom of jullie weten wat hier fout gaat en in welke richting ik moet denken voor een oplossing? Als er meer informatie nodig is dan hoor ik het uiteraard graag. Alvast bedankt.

[synoniem]

Je zou dit nog kunnen proberen:

YAML:

networks:
  vadjnet:
    ipv4_address: 172.20.0.2
    driver: bridge
    enable_ipv6: false

[tikkietrugjaap]

synoniem schreef op maandag 20 juli 2026 @ 23:07:
Je zou dit nog kunnen proberen:

YAML:

networks:
  vadjnet:
    ipv4_address: 172.20.0.2
    driver: bridge
    enable_ipv6: false

Ik zal dat eens proberen. Bedankt.

[edit]
Ik heb het bovenstaande toegevoegd aan het networks-deel:

networks:
  vadjnet:
    driver_opts:
      com.docker.network.bridge.name: vadjnet
    driver: bridge
    enable_ipv6: false
    ipam:
      config:
        - subnet: 172.20.0.0/16

Maar het resultaat is hetzelfde. Als ik "sudo docker exec -it swag ping desk9800.home.internal" uitvoer krijg ik weer:

ping: bad address 'desk9800.home.internal'

[ Voor 43% gewijzigd door tikkietrugjaap op 21-07-2026 10:29 ]

[Airw0lf]

@tikkietrugjaap - is er een externe dns server die dit kan resolven?

Start die container eens met: --dns <ip-adres van die dns server>. En probeer dan nog eens.

[tikkietrugjaap]

Airw0lf schreef op dinsdag 21 juli 2026 @ 10:49:
@tikkietrugjaap - is er een externe dns server die dit kan resolven?

Start die container eens met: --dns <ip-adres van die dns server>. En probeer dan nog eens.

Bedankt voor de tip maar dat had ik al geprobeerd. Dit is ook zichtbaar in de YAML code die ik aanvankelijk had gepost. Het staat daar nu als comment in omdat het niet leek te werken. Ik was alleen vergeten dit expliciet te melden.

Ik vraag me alleen af of dit wel een DNS kwestie is. Het pingen van de hostname lijkt wel goed te gaan als ik expliciet ipv4 gebruik bij ping.

[Dracoz]

tikkietrugjaap schreef op dinsdag 21 juli 2026 @ 11:38:
[...]

Bedankt voor de tip maar dat had ik al geprobeerd. Dit is ook zichtbaar in de YAML code die ik aanvankelijk had gepost. Het staat daar nu als comment in omdat het niet leek te werken. Ik was alleen vergeten dit expliciet te melden.

Ik vraag me alleen af of dit wel een DNS kwestie is. Het pingen van de hostname lijkt wel goed te gaan als ik expliciet ipv4 gebruik bij ping.

Lijkt me meer een ipv6 issue. Alpine maakt gebruik musl libc en musl is best streng qua ipv6. Je kan proberen dit in te stellen in OPNsense onder unbound dns. Verwacht dat het dan wel werkt.

local-zone: "home.internal." typetransparent

[ Voor 7% gewijzigd door Dracoz op 21-07-2026 12:05 ]

[tikkietrugjaap]

Dracoz schreef op dinsdag 21 juli 2026 @ 12:01:
[...]

Lijkt me meer een ipv6 issue. Alpine maakt gebruik musl libc en musl is best streng qua ipv6. Je kan proberen dit in te stellen in OPNsense onder unbound dns. Verwacht dat het dan wel werkt.

local-zone: "home.internal." typetransparent

Ik heb ook het vermoeden dat het ipv6 gerelateerd is maar ik begrijp alleen niet hoe dat kan als ik nergens ipv6 gebruik.

Dat gezegd hebbende, ik heb binnen Opnsense gezocht naar hetgeen jij voorstelt maar ik kan nergens een local-zone invullen. Bij de general options van Unbound vind ik wel instellingen voor "Local Zone Type" en die staat al op Transparent. Zoeken via Google/AI levert veel oude informatie op waarbij wordt gerefereerd naar een sectie 'Custom options' die niet meer lijken te bestaan.

Misschien ook handig om te weten is dat ik meerdere subdomains heb binnen .internal. De servers waar de VM's op draaien zitten bijvoorbeeld in servers.internal en die desktop die ik probeer te pingen zit in home.internal.

Als laatste, is dit nog een Docker-vraag of kan ik het beter gaan vragen in een Opnsense-thread?

[Dracoz]

tikkietrugjaap schreef op dinsdag 21 juli 2026 @ 12:22:
[...]

Ik heb ook het vermoeden dat het ipv6 gerelateerd is maar ik begrijp alleen niet hoe dat kan als ik nergens ipv6 gebruik.

Dat gezegd hebbende, ik heb binnen Opnsense gezocht naar hetgeen jij voorstelt maar ik kan nergens een local-zone invullen. Bij de general options van Unbound vind ik wel instellingen voor "Local Zone Type" en die staat al op Transparent. Zoeken via Google/AI levert veel oude informatie op waarbij wordt gerefereerd naar een sectie 'Custom options' die niet meer lijken te bestaan.

Misschien ook handig om te weten is dat ik meerdere subdomains heb binnen .internal. De servers waar de VM's op draaien zitten bijvoorbeeld in servers.internal en die desktop die ik probeer te pingen zit in home.internal.

Als laatste, is dit nog een Docker-vraag of kan ik het beter gaan vragen in een Opnsense-thread?

Meer OPNsense gerelateerd imho. Het probleem is dat alpine op dns niveau niet weet dat je netwerk geen ipv6 heeft.

Oja tegenwoordig is het inderdaad zelf via conf bestand in te stellen of via dns override in de webgui van OPNsense geloof ik. Kun je er ook direct meerdere in stellen en dan zou het moeten werken.

[tikkietrugjaap]

Dracoz schreef op dinsdag 21 juli 2026 @ 12:44:
[...]


Meer OPNsense gerelateerd imho. Het probleem is dat alpine op dns niveau niet weet dat je netwerk geen ipv6 heeft.

Oja tegenwoordig is het inderdaad zelf via conf bestand in te stellen of via dns override in de webgui van OPNsense geloof ik. Kun je er ook direct meerdere in stellen en dan zou het moeten werken.

Ok, dan ga ik de vraag stellen in de Opnsense-thread. Bedankt.

[edit]
Mm, er blijkt geen grote Opnsense-thread te zijn. Ik zal wel een eigen thread aanmaken in het Netwerken-forum.

[ Voor 11% gewijzigd door tikkietrugjaap op 21-07-2026 12:52 ]

[Dracoz]

tikkietrugjaap schreef op dinsdag 21 juli 2026 @ 12:50:
[...]

Ok, dan ga ik de vraag stellen in de Opnsense-thread. Bedankt.

[edit]
Mm, er blijkt geen grote Opnsense-thread te zijn. Ik zal wel een eigen thread aanmaken in het Netwerken-forum.

Je kan eventueel hier ff kijkje nemen staat exact uitgelegd wat je moet doen om alles le laten werken. https://homenetworkguy.com/how-to/create-unbound-dns-override-aliases-in-opnsense/

[tikkietrugjaap]

Dracoz schreef op dinsdag 21 juli 2026 @ 12:56:
[...]

Je kan eventueel hier ff kijkje nemen staat exact uitgelegd wat je moet doen om alles le laten werken. https://homenetworkguy.com/how-to/create-unbound-dns-override-aliases-in-opnsense/

Momenteel heb ik al een override voor mijn reverse-proxy dus het override scherm ken ik wel een beetje. Waar ik nu nog mee zit is dat ik niet goed begrijp wat ik zou moeten invullen om binnen Docker containers ook goede DNS te hebben. Ik merk dat ik nog niet helemaal begrijp waarom dit op deze manier gebeurt waardoor het zoeken naar een werkende oplossing een uitdaging is. Hopelijk dat een avondje online speuren mij daar verder in brengt.

Wederom bedankt.

[Mars Warrior]

Klinkt als foutieve AAAA records.

getent ahosts desk9800.home.internal

Of iets als

dig desk9800.home.internal A
dig desk9800.home.internal AAAA

Zou je ook verder moeten helpen.

[RobertMe]

Dracoz schreef op dinsdag 21 juli 2026 @ 12:44:
[...]


Meer OPNsense gerelateerd imho. Het probleem is dat alpine op dns niveau niet weet dat je netwerk geen ipv6 heeft.

Als je IPv6 uit zet hoort de lokale DNS resolver dat natuurlijk gewoon te weten en geen AAAA queries af te vuren. De DNS server aan de andere kant kan immers al helemaal niet weten of de client wel of geen IPv6 doet. Immers weet de DNS server al helemaal niks van het netwerk af. Die kan immers ook op een ander systeem dan de router draaien etc etc etc. Het is toch echt de verantwoordelijkheid van de lokale resolver / OS om de juiste queries te doen. En grote kans dat dat zelfs uit het OS komt en niet zozeer uit de lokale resolver. De applicatie zal immers zelf moeten kiezen of die een A, AAAA, TXT, MX, SOA, DS, ... wilt doen. En ja, applicaties kunnen ook zowel A als AAAA tegelijkertijd doen en de voorkeur geven aan het soort dat als eerste een werkende verbinding levert.

[Dracoz]

RobertMe schreef op dinsdag 21 juli 2026 @ 13:09:
[...]

Als je IPv6 uit zet hoort de lokale DNS resolver dat natuurlijk gewoon te weten en geen AAAA queries af te vuren. De DNS server aan de andere kant kan immers al helemaal niet weten of de client wel of geen IPv6 doet. Immers weet de DNS server al helemaal niks van het netwerk af. Die kan immers ook op een ander systeem dan de router draaien etc etc etc. Het is toch echt de verantwoordelijkheid van de lokale resolver / OS om de juiste queries te doen. En grote kans dat dat zelfs uit het OS komt en niet zozeer uit de lokale resolver. De applicatie zal immers zelf moeten kiezen of die een A, AAAA, TXT, MX, SOA, DS, ... wilt doen. En ja, applicaties kunnen ook zowel A als AAAA tegelijkertijd doen en de voorkeur geven aan het soort dat als eerste een werkende verbinding levert.

Zoals ik zei, Alpine gebruikt de musl libc en die blijft op dns niveau altijd AAAA records opvragen. OPNsense geeft een servfail en daardoor geeft de musl libc bad adress terug.

Een OS zoals bijvoorbeeld Ubuntu zal dit negeren omdat glibc de ipv6 foutmelding negeert en de ipv4 gewoon teruggeeft.

Dit komt dus allemaal omdat die zonetype binnen unbound niet op transparent staat en dus altijd een servfail op ipv6 teruggeeft.

[ Voor 5% gewijzigd door Dracoz op 21-07-2026 13:32 ]

[Dracoz]

tikkietrugjaap schreef op dinsdag 21 juli 2026 @ 13:04:
[...]

Momenteel heb ik al een override voor mijn reverse-proxy dus het override scherm ken ik wel een beetje. Waar ik nu nog mee zit is dat ik niet goed begrijp wat ik zou moeten invullen om binnen Docker containers ook goede DNS te hebben. Ik merk dat ik nog niet helemaal begrijp waarom dit op deze manier gebeurt waardoor het zoeken naar een werkende oplossing een uitdaging is. Hopelijk dat een avondje online speuren mij daar verder in brengt.

Wederom bedankt.

Zet eens een test vm op met bijvoorbeeld ubuntu. Grote kans dat het dan wel werkt omdat die dus glibc gebruiken. Wat je eigenlijk moet doen is zorgen dat je zonetype binnen unbound op transparent staat, dan werkt het ook gewoon binnen alpine etc. Die kun je doen via een .conf bestand

[RobertMe]

Dracoz schreef op dinsdag 21 juli 2026 @ 13:23:
[...]

Zoals ik zei, Alpine gebruikt de musl libc en die blijft op dns niveau altijd AAAA records opvragen. OPNsense geeft een servfail en daardoor geeft de musl libc bad adress terug.

Een OS zoals bijvoorbeeld Ubuntu zal dit negeren omdat glibc de ipv6 foutmelding negeert en de ipv4 gewoon teruggeeft.

Dat lijkt mij gewoon heel sterk. Zou immers betekenen dat Alpine nooit bruikbaar is in een IPv4 only netwerk. En nouja, Alpine is een "vrij populair" base image voor Docker containers en Docker ondersteund pas vrij recent IPv6 (by default). Dus als Alpine zich niks aantrekt van of het OS (/omgeving / container) IPv6 geschikt is dan zou je nooit Alpine als base image hebben kunnen gebruiken (en kan dat nog steeds niet) in een IPv4 omgeving. Waarbij een DNS resolver in het netwerk nog steeds prima op AAAA requests zal antwoorden ook al is die DNS resolver zelf niet via IPv6 met het internet verbonden.

Edit:

$ docker network create --ipv6=false noipv6
9026ff4a7819fcf904732a5a7e80a32b1886e79b3ef8087876ffc2d53ab9426b
$ docker run --rm --network noipv6 -it alpine ash
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
55afa1ecc21d: Already exists
Digest: sha256:28bd5fe8b56d1bd048e5babf5b10710ebe0bae67db86916198a6eec434943f8b
Status: Downloaded newer image for alpine:latest
/ # ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@if255: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether 02:91:ac:5b:ca:58 brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.2/16 brd 172.19.255.255 scope global eth0
       valid_lft forever preferred_lft forever
/ # ping google.com
PING google.com (172.217.171.110): 56 data bytes
^C
--- google.com ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss

Werkt dus prima. Ping gaat naar het IPv4 adres. Doe ik ping -6 google.com laat die wel het IP zien maar "Network unreachable". (Er komt geen antwoord omdat de boel in de firewall is dicht getimmerd. Containers mogen niet naar buiten babbelen tenzij expliciet toegestaan).

[ Voor 41% gewijzigd door RobertMe op 21-07-2026 13:42 ]

[synoniem]

RobertMe schreef op dinsdag 21 juli 2026 @ 13:35:
[...]

Dat lijkt mij gewoon heel sterk. Zou immers betekenen dat Alpine nooit bruikbaar is in een IPv4 only netwerk. En nouja, Alpine is een "vrij populair" base image voor Docker containers en Docker ondersteund pas vrij recent IPv6 (by default). Dus als Alpine zich niks aantrekt van of het OS (/omgeving / container) IPv6 geschikt is dan zou je nooit Alpine als base image hebben kunnen gebruiken (en kan dat nog steeds niet) in een IPv4 omgeving. Waarbij een DNS resolver in het netwerk nog steeds prima op AAAA requests zal antwoorden ook al is die DNS resolver zelf niet via IPv6 met het internet verbonden.

Edit:

$ docker network create --ipv6=false noipv6
9026ff4a7819fcf904732a5a7e80a32b1886e79b3ef8087876ffc2d53ab9426b
$ docker run --rm --network noipv6 -it alpine ash
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
55afa1ecc21d: Already exists
Digest: sha256:28bd5fe8b56d1bd048e5babf5b10710ebe0bae67db86916198a6eec434943f8b
Status: Downloaded newer image for alpine:latest
/ # ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@if255: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether 02:91:ac:5b:ca:58 brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.2/16 brd 172.19.255.255 scope global eth0
       valid_lft forever preferred_lft forever
/ # ping google.com
PING google.com (172.217.171.110): 56 data bytes
^C
--- google.com ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss

Werkt dus prima. Ping gaat naar het IPv4 adres. Doe ik ping -6 google.com laat die wel het IP zien maar "Network unreachable". (Er komt geen antwoord omdat de boel in de firewall is dicht getimmerd. Containers mogen niet naar buiten babbelen tenzij expliciet toegestaan).

Het ligt iets genuanceerder. Bij Alpine vuurt een nslookup voor tegelijkertijd ipv4 en ipv6 af en sommige DNS-servers reageren dan inderdaad met een SERVFAIL (waaronder kennelijk unbound zonder transparent zone). Je kunt dit mitigeren door aan resolv.conf (in de container) dit toe te voegen:

options single-request-reopen

Dan gebruikt nslookup 1 vraag per keer.

[Dracoz]

synoniem schreef op dinsdag 21 juli 2026 @ 13:49:
[...]


Het ligt iets genuanceerder. Bij Alpine vuurt een nslookup voor tegelijkertijd ipv4 en ipv6 af en sommige DNS-servers reageren dan inderdaad met een SERVFAIL (waaronder kennelijk unbound zonder transparent zone). Je kunt dit mitigeren door aan resolv.conf (in de container) dit toe te voegen:

options single-request-reopen

Dan gebruikt nslookup 1 vraag per keer.

Slimme oplossing, nog niet eens aan gedacht om dat toe te voegen. Dat scheelt weer sleutelen in OPNsense inderdaad. Uiteraard is op netwerkniveau de "mooiste" oplossing wel om het op de OPNsense goed in te stellen, dan is het overal in het vervolg opgelost.

[RobertMe]

synoniem schreef op dinsdag 21 juli 2026 @ 13:49:
[...]


Het ligt iets genuanceerder. Bij Alpine vuurt een nslookup voor tegelijkertijd ipv4 en ipv6 af en sommige DNS-servers reageren dan inderdaad met een SERVFAIL (waaronder kennelijk unbound zonder transparent zone). Je kunt dit mitigeren door aan resolv.conf (in de container) dit toe te voegen:

options single-request-reopen

Dan gebruikt nslookup 1 vraag per keer.

Ik draai Unbound, rechtstreeks als mijn DNS (als in: in het voorbeeld verbind de Alpine container direct met Unbound). Alleen heb ik mijn lokale DNS met RPZ gedaan, en niet met Unbounds custom format. Dan zou het issue echt al een niche in een niche in een niche moeten zijn wil je er tegenaan lopen. En ja, ook als ik een lokale naam laat resolven, met of zonder bestaand record van een ander type, krijg ik gewoon een NOERROR terug en geen SERVFAIL.

[synoniem]

RobertMe schreef op dinsdag 21 juli 2026 @ 14:31:
[...]

Ik draai Unbound, rechtstreeks als mijn DNS (als in: in het voorbeeld verbind de Alpine container direct met Unbound). Alleen heb ik mijn lokale DNS met RPZ gedaan, en niet met Unbounds custom format. Dan zou het issue echt al een niche in een niche in een niche moeten zijn wil je er tegenaan lopen. En ja, ook als ik een lokale naam laat resolven, met of zonder bestaand record van een ander type, krijg ik gewoon een NOERROR terug en geen SERVFAIL.

Ja ik zou verwachten dat de optie dns=unbound-ip het probleem ook zou oplossen. De vraagsteller geeft echter aan dat hij dat al geprobeerd heeft en ik heb geen idee hoe zijn verdere configuratie er uit ziet en hoe niche die configuratie is

Ik gebruik zelf pfSense en dat is tegenwoordig steeds minder goed te vergelijken met OPNsense. En het inregelen van ipv6 was nog een aardig klusje om het goed te doen i.c.m. PPPOE.

Maar het probleem dat niet alle dns-servers en m.n. bij consumentenhardware tegen een dubbele nslookup kan komt meer voor.

[tikkietrugjaap]

Even een bericht tussendoor. Ik zie allemaal hele goede informatie voorbij komen. Ik heb vanavond weer tijd om dit op te pakken en zal dan reageren op alles. Mits dit is toegestaan binnen deze thread want het lijkt erop dat dit niet aan Docker ligt.

[Dracoz]

RobertMe schreef op dinsdag 21 juli 2026 @ 14:31:
[...]

Ik draai Unbound, rechtstreeks als mijn DNS (als in: in het voorbeeld verbind de Alpine container direct met Unbound). Alleen heb ik mijn lokale DNS met RPZ gedaan, en niet met Unbounds custom format. Dan zou het issue echt al een niche in een niche in een niche moeten zijn wil je er tegenaan lopen. En ja, ook als ik een lokale naam laat resolven, met of zonder bestaand record van een ander type, krijg ik gewoon een NOERROR terug en geen SERVFAIL.

RPZ is bij jou exact de reden dat dit gedrag voorkomen wordt. ​Als je OPNsense gewoon standaard draait met 'register DHCP leases' in Unbound, krijg je precies die strikte local-zones. Combineer dat met Alpine-containers (die parallel A en AAAA-queries vuren) en je loopt hier dus direct tegenaan.

[tikkietrugjaap]

Ok. Ik heb de berichten gelezen en het lijkt er steeds meer op dat ik iets niet goed heb ingesteld bij DNSMasq en Unbound. Eens kijken of ik zoveel mogelijk antwoorden kan geven zonder een chaotische post te maken:

Mars Warrior schreef op dinsdag 21 juli 2026 @ 13:06:

getent ahosts desk9800.home.internal binnen de container levert niets op. Hij doet wel iets maar vervolgens zie ik gewoon weer de command prompt. Als ik het binnen de VM doe krijg ik:

192.168.10.103  STREAM desk9800.home.internal
192.168.10.103  DGRAM
192.168.10.103  RAW

dig desk9800.home.internal A binnen de container levert op:

; <<>> DiG 9.20.23 <<>> desk9800.home.internal A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45044
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;desk9800.home.internal.                IN      A

;; ANSWER SECTION:
desk9800.home.internal. 1       IN      A       192.168.10.103

;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Jul 21 20:08:13 CEST 2026
;; MSG SIZE  rcvd: 67

dig desk9800.home.internal A binnen de container levert op:

; <<>> DiG 9.20.23 <<>> desk9800.home.internal AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5375
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;desk9800.home.internal.                IN      AAAA

;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Jul 21 20:08:07 CEST 2026
;; MSG SIZE  rcvd: 40

In beide gevallen wordt de Docker DNS aangesproken (127.0.0.11) maar alleen bij ipv4 gaat het goed.

Dracoz schreef op dinsdag 21 juli 2026 @ 13:31:

Mijn VM's zijn allemaal Ubuntu Server (op Home Assistant na). Je bedoelde waarschijnlijk een docker container op basis van ubuntu dus die heb ik opgestart met "sudo docker run --rm --network noipv6 -it ubuntu". Daarna iputils geïnstalleerd en een ping naar desk9800 verliep inderdaad vlekkeloos.

RobertMe schreef op dinsdag 21 juli 2026 @ 13:35:

In jouw voorbeeld ping je google.com. Dat lukt bij mij, vanuit de container, wel. Hij pingt dan automatisch een ipv4 adres. Probeer ik echter jouw stappen maar ping ik mijn eigen host (desk9800) dan krijg ik hetzelfde resultaat.

synoniem schreef op dinsdag 21 juli 2026 @ 13:49:

Ik heb die regel nog niet geprobeerd, bedankt daarvoor. Echter ben ik het wel met @Dracoz eens dat dit beter geregeld kan worden op netwerkniveau. Ik heb iets niet goed ingesteld binnen Opnsense, lijkt het op. Mijn configuratie is, denk ik, niet heel niche. Opnsense router op een kleine PC, daarop DNSMasq voor DHCP en Unbound voor DNS zodat alle hosts middels FQDN kunnen worden gevonden. Een aantal VLANs maar op dit moment hebben die allemaal nog een allow all regel. Elke VLAN zijn eigen domain (home.internal, servers.internal, iot.internal, etc.).

Dracoz schreef op dinsdag 21 juli 2026 @ 16:43:

Ik heb inderdaad 'register DHCP leases' aanstaan binnen Unbound. Ook heb ik, bij Query Forwarding regels aangemaakt per DHCP range in de vorm van "10.168.192.in-addr.arpa" met een server IP van 127.0.0.1. Ook heb ik dergelijke regels per domain dus "servers.internal" met een server IP van 127.0.0.1. Dit scheen te moeten om DNSMasq en Unbound met elkaar te laten praten.

Zoals gezegd lijkt er iets niet goed te gaan binnen Opnsense. Maar waar is mij op dit moment nog niet duidelijk.

[Airw0lf]

@tikkietrugjaap - wat is de nood om met unbound te gaan werken?

Mijn inschatting is dat je er niet aan gaat ontkomen om dnsmasq ook in te zetten voor dns resolving. Waarbij dnsmasq de forwarder is voor unbound - zo heb ik het in ieder geval opgelost.

[Dracoz]

tikkietrugjaap schreef op dinsdag 21 juli 2026 @ 20:59:
Ok. Ik heb de berichten gelezen en het lijkt er steeds meer op dat ik iets niet goed heb ingesteld bij DNSMasq en Unbound. Eens kijken of ik zoveel mogelijk antwoorden kan geven zonder een chaotische post te maken:


[...]

getent ahosts desk9800.home.internal binnen de container levert niets op. Hij doet wel iets maar vervolgens zie ik gewoon weer de command prompt. Als ik het binnen de VM doe krijg ik:

192.168.10.103  STREAM desk9800.home.internal
192.168.10.103  DGRAM
192.168.10.103  RAW

dig desk9800.home.internal A binnen de container levert op:

; <<>> DiG 9.20.23 <<>> desk9800.home.internal A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45044
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;desk9800.home.internal.                IN      A

;; ANSWER SECTION:
desk9800.home.internal. 1       IN      A       192.168.10.103

;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Jul 21 20:08:13 CEST 2026
;; MSG SIZE  rcvd: 67

dig desk9800.home.internal A binnen de container levert op:

; <<>> DiG 9.20.23 <<>> desk9800.home.internal AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5375
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;desk9800.home.internal.                IN      AAAA

;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Jul 21 20:08:07 CEST 2026
;; MSG SIZE  rcvd: 40

In beide gevallen wordt de Docker DNS aangesproken (127.0.0.11) maar alleen bij ipv4 gaat het goed.


[...]

Mijn VM's zijn allemaal Ubuntu Server (op Home Assistant na). Je bedoelde waarschijnlijk een docker container op basis van ubuntu dus die heb ik opgestart met "sudo docker run --rm --network noipv6 -it ubuntu". Daarna iputils geïnstalleerd en een ping naar desk9800 verliep inderdaad vlekkeloos.


[...]

In jouw voorbeeld ping je google.com. Dat lukt bij mij, vanuit de container, wel. Hij pingt dan automatisch een ipv4 adres. Probeer ik echter jouw stappen maar ping ik mijn eigen host (desk9800) dan krijg ik hetzelfde resultaat.


[...]

Ik heb die regel nog niet geprobeerd, bedankt daarvoor. Echter ben ik het wel met @Dracoz eens dat dit beter geregeld kan worden op netwerkniveau. Ik heb iets niet goed ingesteld binnen Opnsense, lijkt het op. Mijn configuratie is, denk ik, niet heel niche. Opnsense router op een kleine PC, daarop DNSMasq voor DHCP en Unbound voor DNS zodat alle hosts middels FQDN kunnen worden gevonden. Een aantal VLANs maar op dit moment hebben die allemaal nog een allow all regel. Elke VLAN zijn eigen domain (home.internal, servers.internal, iot.internal, etc.).


[...]

Ik heb inderdaad 'register DHCP leases' aanstaan binnen Unbound. Ook heb ik, bij Query Forwarding regels aangemaakt per DHCP range in de vorm van "10.168.192.in-addr.arpa" met een server IP van 127.0.0.1. Ook heb ik dergelijke regels per domain dus "servers.internal" met een server IP van 127.0.0.1. Dit scheen te moeten om DNSMasq en Unbound met elkaar te laten praten.

Zoals gezegd lijkt er iets niet goed te gaan binnen Opnsense. Maar waar is mij op dit moment nog niet duidelijk.

Ah top dat resultaat, hier zie je direct dat inderdaad glibc het niets boeit dat die op ipv6 een error terug krijgt maar dat de musl libc volledig kapot gaat daarop.

Gelukkig is de oplossing erg simpel, je hoeft niet je hele keten om te gooien en Dnsmasq als forwarder voor unbound te zetten, dit kan uiteraard maar is imho beetje overkill. Wat je beter kan doen is gewoon in de custom.d folder van unbound een .conf bestand aan te maken met het volgende:

server: 
     local-zone: "home.internal." transparent 
     local-zone: "servers.internal." transparent 
     local-zone: "iot.internal." transparent

Standaard behandelt unbound een lokaal domein vaak namelijk heel strikt of static of deny. Zodra Alpine dan om een AAAA record vraagt wat niet in Unbound staat denk denkt unbound dat het niet bestaat en geeft die een serverfail. Zodra je dit instelt op transparant dan verander je dit gedrag door aan te geven dat als de AAAA record niet bestaat hij gewoon een noerror teruggeeft.

Hoop dat het nu duidelijk is!

[Airw0lf]

Dracoz schreef op dinsdag 21 juli 2026 @ 23:15:
[...]

Gelukkig is de oplossing erg simpel, je hoeft niet je hele keten om te gooien en Dnsmasq als forwarder voor unbound te zetten, dit kan uiteraard maar is imho beetje overkill.

Hoop dat het nu duidelijk is!

Voor mij in ieder geval wel - dank je!

Kan je dan ook volstaan met één regel: local-zone: "internal." transparent? Met het idee dat dan alles wat eindigt op internal op die manier wordt afgehandeld?

Wat ik me ook nog afvraag is hoe unbound weet gaat krijgen van de door dnsmasq uitgegeven ip adressen en bijbehorende, geregistreerde systeemnamen? Hoe zou dat moeten werken?

[ Voor 20% gewijzigd door Airw0lf op 22-07-2026 07:47 ]

[tikkietrugjaap]

Airw0lf schreef op dinsdag 21 juli 2026 @ 21:45:
@tikkietrugjaap - wat is de nood om met unbound te gaan werken?

Mijn inschatting is dat je er niet aan gaat ontkomen om dnsmasq ook in te zetten voor dns resolving. Waarbij dnsmasq de forwarder is voor unbound - zo heb ik het in ieder geval opgelost.

Ik heb dat zo ingesteld nadat ik had gezocht naar oplossingen om hostnames van verschillende apparaten die via DNSMasq een IP krijgen vindbaar te maken. Dit om te voorkomen dat ik IP adressen moest gaan onthouden of teveel DHCP adressen static moest maken.

Dracoz schreef op dinsdag 21 juli 2026 @ 23:15:
[...]

Ah top dat resultaat, hier zie je direct dat inderdaad glibc het niets boeit dat die op ipv6 een error terug krijgt maar dat de musl libc volledig kapot gaat daarop.

Gelukkig is de oplossing erg simpel, je hoeft niet je hele keten om te gooien en Dnsmasq als forwarder voor unbound te zetten, dit kan uiteraard maar is imho beetje overkill. Wat je beter kan doen is gewoon in de custom.d folder van unbound een .conf bestand aan te maken met het volgende:

server: 
     local-zone: "home.internal." transparent 
     local-zone: "servers.internal." transparent 
     local-zone: "iot.internal." transparent

Standaard behandelt unbound een lokaal domein vaak namelijk heel strikt of static of deny. Zodra Alpine dan om een AAAA record vraagt wat niet in Unbound staat denk denkt unbound dat het niet bestaat en geeft die een serverfail. Zodra je dit instelt op transparant dan verander je dit gedrag door aan te geven dat als de AAAA record niet bestaat hij gewoon een noerror teruggeeft.

Hoop dat het nu duidelijk is!

Ik ga hier mee aan de slag. De gedachte erachter is mij helaas nog onduidelijk maar dat komt omdat ik simpelweg geen kaas heb gegeten van DNS. Ik zou niet eens weten wat het verschil is tussen een transparent local-zone en de andere opties. Moet toch maar eens op zoek naar wat meer achterliggende informatie m.b.t. dit onderwerp. Ik vind het wel opmerkelijk dat dit niet in de GUI van Unbound kan worden ingesteld. Maar wellicht is dat een keuze geweest van het Opnsense-team.
In ieder geval bedankt voor de informatie.

[tikkietrugjaap]

Dracoz schreef op dinsdag 21 juli 2026 @ 23:15:
[...]

Ah top dat resultaat, hier zie je direct dat inderdaad glibc het niets boeit dat die op ipv6 een error terug krijgt maar dat de musl libc volledig kapot gaat daarop.

Gelukkig is de oplossing erg simpel, je hoeft niet je hele keten om te gooien en Dnsmasq als forwarder voor unbound te zetten, dit kan uiteraard maar is imho beetje overkill. Wat je beter kan doen is gewoon in de custom.d folder van unbound een .conf bestand aan te maken met het volgende:

server: 
     local-zone: "home.internal." transparent 
     local-zone: "servers.internal." transparent 
     local-zone: "iot.internal." transparent

Standaard behandelt unbound een lokaal domein vaak namelijk heel strikt of static of deny. Zodra Alpine dan om een AAAA record vraagt wat niet in Unbound staat denk denkt unbound dat het niet bestaat en geeft die een serverfail. Zodra je dit instelt op transparant dan verander je dit gedrag door aan te geven dat als de AAAA record niet bestaat hij gewoon een noerror teruggeeft.

Hoop dat het nu duidelijk is!

Terugkoppeling over het bovenstaande.

Ik moest even opzoeken hoe het .conf bestand moest heten en dat was blijkbaar "custom-local-zones.conf". Ik heb dit gemaakt en de regels die jij aangaf erin gezet. Daarna zowel DNSMasq als Unbound opnieuw gestart. Het resultaat was helaas precies als voorheen.

Wat ik daarna heb gedaan is bij Query forwarding de regel voor het domein servers.internal, die naar server IP 127.0.0.1 port 53053 (wat DNSMasq is) verwees, gedisabled. Dat resulteerde in dezelfde foutmelding (Bad Address) maar die foutmelding kwam wel veel sneller. Dat deed me vermoeden dat de foutmelding voornamelijk vanuit DNSMasq kwam. Ik ben toen nog eens in de instelling van DNSMasq gaan zoeken en kwam de optie "DHCP local domain" tegen. De uitleg bij die optie is "Sets all DHCP domains as local. This will configure this DNS server as authoritative; it will not forward queries to any upstream servers for these domains". Dat leek mij een goede om te proberen en inderdaad, nadat ik die optie had aangevinkt, zowel DNSMasq als Unbound opnieuw had opgestart kon in normaal pingen vanuit mijn Docker containers.

Ik vermoed dat er mensen zullen zijn met kennis van DNS die nu vrij luid "duh" roepen maar ik ben vrij content met het resultaat.

Waar ik nog wel een beetje mee zit is dat ik niet uit kan leggen wat er voorheen fout ging en waarom het nu wel werkt. Voor zover ik het begrijp krijgt DNSMasq een DNS verzoek van Unbound voor een host op één van de lokale domeinen. Ik zou toch vermoeden dat hij daar dan gewoon een resultaat voor geeft zoals hij dat ook doet voor alle andere verzoeken maar blijkbaar werkt dat anders.
Ik ben online gaan zoeken naar lesmateriaal om meer over DNS te leren maar dat is een rabbit hole op zichzelf.

Anyway, iedereen bedankt voor het meedenken.

[Airw0lf]

@tikkietrugjaap - mijn 0,500 Euro:

De oorzaak ligt in beiden - unbound en dnsmasq.

Allereerst unbound - die lijkt vooral te zijn gebouwd rondom external DNS resolving bij de bron van het DNS domein. Waarbij af fabriek local resolving niet (goed) werkt. Om dit in goede banen te leiden heb ik in unbound onderstaande settings in een custom config bestand gestoken.

De twee server settings zorgen er voor dat reverse dns lookups goed werken - ook als er geen dnssec actief is (wat in de meeste thuis netwerkjes het geval is).

De eerste forward-zone vertellen unbound waar die terecht kan voor alle domains die eindigen op .lan - in mijn geval dus alle vlans. De tweede forward-zone doet hetzelfde voor alle reverse DNS lookups voor alle vlans. De derde forward-zone is voor external DNS lookups - die worden afgehandeld door bepaalde DNS servers van Cloudflare en KPN.

code:

server:
    insecure-lan-zones: yes
    local-zone: "168.192.in-addr.arpa." nodefault

forward-zone:
    name: "lan."
    forward-addr: 192.168.230.235

forward-zone:
    name: "168.192.in-addr.arpa."
    forward-addr: 192.168.230.235

forward-zone:
    name: "."
    forward-addr: 1.1.1.2
    forward-addr: 1.0.0.2
    forward-addr: 195.121.97.203
    forward-addr: 195.121.97.202

Dan dnsmasq - dat ligt wat ingewikkelder als je met vlans werkt.

Hieronder allereerst mijn aanpak voor vlans.

Via systemd-networkd heb ik de nodige vlan interfaces aangemaakt; waaronder eth0.210, eth0.220 en eth0.230. Het management "vlan" is bij mij altijd eth0. Vervolgens via een dnsmasq-config bestandje de vlans voorzien van dhcp en dns - hieronder een paar van die vlans. Je ziet dat elk vlan/domain aangemerkt is als local domain. Hierdoor blijven alle dns aanvragen lokaal.

code:

# Wired - vlan 210
domain=wired.lan,192.168.210.0/24,local
dhcp-range=set:vlan-210,192.168.210.11,192.168.210.99,168h
dhcp-option=tag:vlan-210,option:router,192.168.210.241
dhcp-option=tag:vlan-210,option:dns-server,192.168.210.235,192.168.100.234
dhcp-option=tag:vlan-210,option:ntp-server,192.168.210.235

# Binnenkant WiFi - vlan 220
domain=wifi.lan,192.168.220.0/24,local
dhcp-range=set:vlan-220,192.168.220.11,192.168.220.99,168h
dhcp-option=tag:vlan-220,option:router,192.168.220.241
dhcp-option=tag:vlan-220,option:dns-server,192.168.220.235,192.168.100.234
dhcp-option=tag:vlan-220,option:ntp-server,192.168.220.235

# Domotica & IoT - vlan 230 - dns forwarder is dnsmasq on homey-be
domain=domotica.lan,192.168.230.0/24,local
dhcp-range=set:vlan-230,192.168.230.11,192.168.230.99,168h
dhcp-option=tag:vlan-230,option:router,192.168.230.241
dhcp-option=tag:vlan-230,option:dns-server,192.168.230.209
dhcp-option=tag:vlan-230,option:ntp-server,192.168.230.235

Om het gedrag zo voorspelbaar mogelijk te krijgen zijn in een apart dnsmasq config bestandje onderstaande parameters opgenomen. Met bind-interfaces zorg je er voor dat dnsmasq alleen actief wordt op daadwerkelijk vooraf bepaalde, bestaande interfaces (versus 0.0.0.0). De no-dhcp zorgt er voor dnsmasq niks doet met dhcp aanvragen via docker.

De laatste 3 zorgen er voor het betreffende systeem gezien wordt als enige dhcp server die altijd zorgt voor een fqdn op basis van het mac-adres - dit laatste wordt afgedwongen via dhcp-ignore-clid.

code:

bind-interfaces
no-dhcp-interface=docker0

dhcp-fqdn
dhcp-authoritative
dhcp-ignore-clid

Er zijn ook nog een paar dns parameters die hier kunnen helpen - maar het voert te ver om die ook allemaal hier op te nemen en uit te leggen. Dit omdat ik dnsmasq gebruik op basis van pihole waardoor een aantal dingen automagically ingesteld worden.

Aangezien dit alles behoorlijk off-topic is wil ik voorstellen om vervolg vragen via een PM te doen.

[ Voor 3% gewijzigd door Airw0lf op 22-07-2026 23:28 ]

[DjoeC]

Gekke vraag misschien maar toch want ik zie vast ergens iets over het hoofd.....

Ik draai op een Pi 5 met veel tevredenheid OpenMediaVault. Nu staat OMV geen desktopomgeving toe op het basis OS, hun keuze en eigenlijk ook wel prima. Op OMV draai ik Docker dus mijn denken is: Waarom geen Raspi OS desktop in Docker, zeg maar: een Raspi in een VM achtige oplossing.

Zoeken heeft me nog niks opgeleverd en dus hier de vraag: Is dit een mogelijkheid en waar kan ik meer info vinden?

[Airw0lf]

DjoeC schreef op donderdag 23 juli 2026 @ 13:20:
Gekke vraag misschien maar toch want ik zie vast ergens iets over het hoofd.....

Ik draai op een Pi 5 met veel tevredenheid OpenMediaVault. Nu staat OMV geen desktopomgeving toe op het basis OS, hun keuze en eigenlijk ook wel prima. Op OMV draai ik Docker dus mijn denken is: Waarom geen Raspi OS desktop in Docker, zeg maar: een Raspi in een VM achtige oplossing.

Zoeken heeft me nog niks opgeleverd en dus hier de vraag: Is dit een mogelijkheid en waar kan ik meer info vinden?

Je kan in OMV - naast de Docker plugin - ook de KVM-plugin installeren. En dan een VM aanmaken met een RPI-OS-plus-desktop. Als ik vragen mag: waarom zou je dat willen doen?

[ Voor 5% gewijzigd door Airw0lf op 23-07-2026 13:38 ]

[DjoeC]

Airw0lf schreef op donderdag 23 juli 2026 @ 13:35:
[...]

Je kan in OMV - naast de Docker plugin - ook de KVM-plugin installeren. En dan een VM aanmaken met een RPI-OS-plus-desktop. Als ik vragen mag: waarom zou je dat willen doen?

Dank je, ik ga die optie eens goed doorlezen. Waarom? Ik wil continue een browserapplicatie met wat automatische acties op de achtergrond laten draaien en die remote kunnen benaderen. En nu bedenk ik me (...) de vraag had dus ook kunnen zijn: Een browser (FF, Chromium, whatever) in Docker. En ik zie nu dat er een Firefox container is voor ARM64, zie je wel: je hebt me getriggerd dat ik de simpele oplossing over t hoofd heb gezien.

Maar, ik ga me ook eens verdiepen in de KVM optie.

[Airw0lf]

DjoeC schreef op donderdag 23 juli 2026 @ 14:15:
[...]

Dank je, ik ga die optie eens goed doorlezen. Waarom? Ik wil continue een browserapplicatie met wat automatische acties op de achtergrond laten draaien en die remote kunnen benaderen. En nu bedenk ik me (...) de vraag had dus ook kunnen zijn: Een browser (FF, Chromium, whatever) in Docker. En ik zie nu dat er een Firefox container is voor ARM64, zie je wel: je hebt me getriggerd dat ik de simpele oplossing over t hoofd heb gezien.

Maar, ik ga me ook eens verdiepen in de KVM optie.

Ok - maar nog steeds... misschien mis ik iets... maar hoe zie je dat met die remote toegang? Want of je een browser gebruikt in een Docker container of in een VM maakt eigenlijk niet uit - remote toegang is nog steeds beperkt tot een CLI/SSH login - toch?

[DjoeC]

Airw0lf schreef op donderdag 23 juli 2026 @ 15:55:
[...]

Ok - maar nog steeds... misschien mis ik iets... maar hoe zie je dat met die remote toegang? Want of je een browser gebruikt in een Docker container of in een VM maakt eigenlijk niet uit - remote toegang is nog steeds beperkt tot een CLI/SSH login - toch?

Ik hoopte op browser in browser waarbij de onderliggende doorloopt als de wrapper afsluit (hopelijk snap je wat ik probeer te zeggen), en ik weer verder kan zodra ik de onderliggende opnieuw benader.

Vergelijk het met een duurtest van de onderliggende browser alleen moet er af en toe wat gewijzigd worden terwijl het draait. Ik kan natuurlijk een losse Pi inrichten, maar dat is nou net niet de bedoeling. Ik wil dus een browser draaien/kunnen benaderen op een headless machine zonder grafische interface omdat OMV dat niet geweldig vind maar mijn Pi5 nog meer dan voldoende capaciteit heeft.

[ Voor 26% gewijzigd door DjoeC op 24-07-2026 10:48 ]

[LEDfan]

Een browser in een Docker container wordt vaak gebruikt voor front-end testen of om automatisch screenshots te nemen. Dit is dan vaak een headless versie van Chrome aangestuurd met https://playwright.dev/ , https://www.selenium.dev/ etc.
Als je echt de browser UI wilt kunnen gebruiken, kan je X en VNC in een Docker container draaien. Bv met https://github.com/fcwu/docker-ubuntu-vnc-desktop , maar misschien zijn er wel meer up to date projecten.

[synoniem]

LEDfan schreef op zaterdag 25 juli 2026 @ 11:13:
Een browser in een Docker container wordt vaak gebruikt voor front-end testen of om automatisch screenshots te nemen. Dit is dan vaak een headless versie van Chrome aangestuurd met https://playwright.dev/ , https://www.selenium.dev/ etc.
Als je echt de browser UI wilt kunnen gebruiken, kan je X en VNC in een Docker container draaien. Bv met https://github.com/fcwu/docker-ubuntu-vnc-desktop , maar misschien zijn er wel meer up to date projecten.

Een meer recent voorbeeld is https://github.com/jlesage/docker-baseimage-gui.

[DjoeC]

@LEDfan @synoniem Komende week wordt t te heet voor de tuin dus ene moment om eens wat te stoeien.
En ja, ik wil echt de UI vanaf de voorgrond (andere browser) kunnen gebruiken en op de achtergrond als (pseudo full-screen) actief houden.

Selenium heb ik van gehoord als testtool. Dat zou voordelen kunnen hebben maar ik weet niet of je daar tijdens een run kunt wijzigen, extra klikken/invullen/etc. En da's geen docker discussie

[daily.data.inj]

Iemand ervaring met docker logs & syslog als remote logging driver? https://docs.docker.com/engine/logging/dual-logging/.

Hiervoor werd de logging via de docker-compose files geregeld. Werkte perfect op 1 groot minpunt na, de logs werden weggeschreven naar een andere docker container (splunk) waardoor ik eerst moest wachten tot de splunk container up was.

Ik heb nu tijd om dit om te gooien, maar dat loopt niet zoals verwacht.
Het zou moeten werken door dit via de daemon te doen: https://docs.docker.com/engine/logging/configure/#configure-the-default-logging-driver.
De logs komen aan op de remote syslog locatie, dus geen network issues. Alleen bij het parsen van de timestamp krijg ik continue errors via deze syslog stroom vanuit docker. Wat er op lijkt dat de timestamp die vanuit de docker logs komt niet volgens rfc5424 is of de configuratie in daemon.json niet meeneemt, zie hieronder wat voorbeelden.

De ontvangende kant (fluent-bit) is redelijk flexibel dus kan daar ik in de config best e.e.a. compenseren. Maar so far heeft dat nog niet voor succes gezorgd.
Deze route werkt overigens voor het ontvangen van andere syslog events perfect. Het lijkt dus echt om deze combinatie te gaan.

code: Foutmeldingen remote syslog

telemetry-layer-fluentbit | [2026/08/19 15:51:21.423] [ warn] [parser:syslog-rfc5424] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2026-08-19T13:51:21+00:00'
telemetry-layer-fluentbit | [2026/08/19 15:51:21.424] [error] [parser] cannot parse '2026-08-19T13:51:21+00:00'
telemetry-layer-fluentbit | [2026/08/19 15:51:21.424] [ warn] [parser:syslog-rfc5424] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2026-08-19T13:51:21+00:00'
telemetry-layer-fluentbit | [2026/08/19 15:51:29.606] [ warn] [input:syslog:syslog.0] error parsing log message with parser 'syslog-rfc5424'

JSON: daemon.json

{
  "insecure-registries" : ["xxxx"],
  "log-driver": "syslog",
  "log-opts": {
    "syslog-format": "rfc5424",
    "syslog-address": "xxx",
    "tag": "{{.Name}}"
  }
}

code: fluentbit-config.yaml

parsers:
  - name: syslog-rfc5424
    format: regex
    regex: '^\<(?<pri>[0-9]{1,5})\>1 (?<time>[^ ]+) (?<host>[^ ]+) (?<ident>[^ ]+) (?<pid>[-0-9]+) (?<msgid>[^ ]+) (?<extradata>(\[(.*?)\]|-)) (?<message>.+)$'
    time_key: time
    time_format: '%Y-%m-%dT%H:%M:%S.%L%z'
    time_keep: On


pipeline:
  inputs:
    - name: syslog
      tag: docker.syslog.udp
      parser: syslog-rfc5424
      listen: 0.0.0.0
      port: 5140
      mode: udp
      receive_buffer_size: 65535
  outputs:
    - name: opensearch
      match: docker.syslog.udp
      host: telemetry-log-opensearch
      port: 9200
      aws_auth: off
      tls: off
      suppress_type_name: on

[babbelbox]

Ik ben absoluut geen expert, maar qua tijdsnotatie zie ik wel iets geks. Je verwacht lijkt het milliseconden, maar die krijg je niet en je tijdzone is in hh:mm notatie, en dat lijkt me geen combi met de Z, die verwacht +of- HHMM, dus zonder :

[daily.data.inj]

babbelbox schreef op woensdag 19 augustus 2026 @ 20:12:
Ik ben absoluut geen expert, maar qua tijdsnotatie zie ik wel iets geks. Je verwacht lijkt het milliseconden, maar die krijg je niet en je tijdzone is in hh:mm notatie, en dat lijkt me geen combi met de Z, die verwacht +of- HHMM, dus zonder :

Ja klopt, schijnbaar een ISO8601 formaat. Alleen config van de docker deamon staat de log driver staat op RFC5424 en daarnaast hebben de compose files geen logging sectie meer.

In ieder geval van het weekend nog even verder gepuzzeld en uiteindelijk, na ook expliciet verwijderen van 'dangling' volumes, kwamen de logs grotendeels door op de remote syslog. Voor nu helemaal goed en weer een mooie stap verder.
Helaas komen er nog genoeg parsing errors voorbij, dus dat wordt een andere keer troubleshooten. Wellicht docker containers 1 voor 1 starten om te kijken of ik wat schuldige containers kan aanwijzen.

[Mars Warrior]

daily.data.inj schreef op maandag 24 augustus 2026 @ 20:22:
[...]

Ja klopt, schijnbaar een ISO8601 formaat. Alleen config van de docker deamon staat de log driver staat op RFC5424 en daarnaast hebben de compose files geen logging sectie meer.

In ieder geval van het weekend nog even verder gepuzzeld en uiteindelijk, na ook expliciet verwijderen van 'dangling' volumes, kwamen de logs grotendeels door op de remote syslog. Voor nu helemaal goed en weer een mooie stap verder.
Helaas komen er nog genoeg parsing errors voorbij, dus dat wordt een andere keer troubleshooten. Wellicht docker containers 1 voor 1 starten om te kijken of ik wat schuldige containers kan aanwijzen.

Enig idee wat die foutmeldingen zijn dan? Want elke container heeft toch gewoon zijn eigen formaat qua output of in ieder geval wat er in de log regel staat?

Dus hoe krijg je Spunk ooit zover dat deze dit fatsoenlijk kan decoderen?

[Dennis]

Gisteren mijn Docker met Traefik, lldap en Authelia werkend gekregen maar met betrekking tot die laatste is er wel heeel erg weinig aanpasbaar. Ik kan niet eens een eigen logo'tje op het inlogscherm zetten of bijvoorbeeld de achtergrondkleur veranderen. Dat vind ik voor mezelf niet zo erg, maar ik wil ook familieleden hier gebruik van laten maken en ik zou het toch wel fijn vinden als ze iets herkennen aan de interface zodat ze ook zien wáár ze inloggen (behalve de url).

[ Voor 0% gewijzigd door Dennis op 27-08-2026 18:49 . Reden: Geen Authentik, maar Authelia. ]

[Ghoulli]

Dennis schreef op donderdag 27 augustus 2026 @ 09:00:
Gisteren mijn Docker met Traefik, lldap en Authentik werkend gekregen maar met betrekking tot die laatste is er wel heeel erg weinig aanpasbaar. Ik kan niet eens een eigen logo'tje op het inlogscherm zetten of bijvoorbeeld de achtergrondkleur veranderen. Dat vind ik voor mezelf niet zo erg, maar ik wil ook familieleden hier gebruik van laten maken en ik zou het toch wel fijn vinden als ze iets herkennen aan de interface zodat ze ook zien wáár ze inloggen (behalve de url).

Keycloak zou dit eventueel wel kunnen, werkt voor het inloggen eigenlijk hetzelfde als Authentik maar is toch wel degelijk anders met opzetten. Zou je eens kunnen proberen als je wil.

[ahbart]

Dennis schreef op donderdag 27 augustus 2026 @ 09:00:
Gisteren mijn Docker met Traefik, lldap en Authentik werkend gekregen maar met betrekking tot die laatste is er wel heeel erg weinig aanpasbaar. Ik kan niet eens een eigen logo'tje op het inlogscherm zetten of bijvoorbeeld de achtergrondkleur veranderen. Dat vind ik voor mezelf niet zo erg, maar ik wil ook familieleden hier gebruik van laten maken en ik zou het toch wel fijn vinden als ze iets herkennen aan de interface zodat ze ook zien wáár ze inloggen (behalve de url).

uhh. In Authentik kun je het logo aanpassen.

In de beheer omgeving: Systeem - Brands en een nieuwe brand aanmaken. Onder Instellingen en merkinstellingen kun je dan van alles aanpassen.

[Dennis]

ahbart schreef op donderdag 27 augustus 2026 @ 17:49:
uhh. In Authentik kun je het logo aanpassen.

In de beheer omgeving: Systeem - Brands en een nieuwe brand aanmaken. Onder Instellingen en merkinstellingen kun je dan van alles aanpassen.

Ik verwar het altijd... ik bedoelde Authelia. Die namen haal ik steeds door elkaar .

[ahbart]

Dennis schreef op donderdag 27 augustus 2026 @ 18:49:
[...]

Ik verwar het altijd... ik bedoelde Authelia. Die namen haal ik steeds door elkaar .

Aah ja. Authelia heb ik ook gebruikt. Die is vrij beperkt. Kun je geen logo mounten als volume of zo?

[Mars Warrior]

Dennis schreef op donderdag 27 augustus 2026 @ 18:49:
[...]

Ik verwar het altijd... ik bedoelde Authelia. Die namen haal ik steeds door elkaar .

https://www.authelia.com/reference/guides/server-asset-overrides/

Is allemaal aanpasbaar hoor in Authelia.

[Dennis]

Ah dank @Mars Warrior, dat heb ik dan gemist. Dat logo is in ieder geval al één ding . En ik zal de feature request voor custom themes eens even een zetje geven.

[daily.data.inj]

Mars Warrior schreef op maandag 24 augustus 2026 @ 21:18:
[...]

Enig idee wat die foutmeldingen zijn dan? Want elke container heeft toch gewoon zijn eigen formaat qua output of in ieder geval wat er in de log regel staat?

Dus hoe krijg je Spunk ooit zover dat deze dit fatsoenlijk kan decoderen?

Daar zijn die docker logging drivers dus voor, het format van de messages kun je configureren.
https://docs.docker.com/engine/logging/drivers/splunk/#message-formats.
Gewoon inline embedded als string was voor mij voldoende, ter illustratie 2 weken geleden:


Nu met een andere logging driver (syslog), komen er parsing errors naar voren omdat ik vermoed dat niet alle messages (en/of containers) zich aan het RFC5424 syslog format houden. Eens kijken of ik wat wijzer wordt vanavond.

[Dennis]

Aangezien hier (denk ik) de meeste kennis zit m.b.t. Traefik even de volgende vraag:

Ik heb vanavond mijn Navidrome met succes gedeployed met een mount van Hetzner Storage Box. Werkt allemaal prima (in de browser), ook netjes met Authelia ervoor.

Maar nu komt de uitdaging: de clients die ik wil gebruiken ondersteunen geen OAuth2. Begrijpelijk want dat moet eigenlijk server side geïmplementeerd worden in Navidrome. Nu lijkt daar wel een discussie over te worden gevoerd maar ik verwacht niet dat dat morgen klaar is .

Dan het alternatief: client side certificates (mutual TLS). Dat ondersteunen de clients die ik wil gebruiken wél. Traefik kan dat in beginsel ook dus dat zal vast configureerbaar zijn. Maar ik wil dan graag die extra stap dat de Subject Common Name (CN) wordt doorgegeven als Remote-User header. Zodat je in Navidrome niet meer in hoeft te loggen.

Wat ik nodig heb lijkt deze plugin ongeveer te doen (andere header, maar principe is gelijk). Heeft iemand dit toevallig in gebruik of iets vergelijkbaars geïmplementeerd hier? Of misschien een andere creatieve oplossing om dit probleem te omzeilen?

[Dennis]

Dit zou trouwens ook een optie kunnen zijn: mTLS met een fallback. Voor mijn use-case met Navidrome zou dat ideaal zijn. Hoewel dan liever met Oauth2.

[Dennis]

Bijna 24 uur later is het gelukt. Heb Claude aan het werk gezet . Die maakte wel een paar fouten maar met wat debuggen konden we dat oplossen.

Ik heb nu dubbele authenticatie, wat werkt via wat middleware die al bestond (passtlsclientcert) en zelfgemaakte (python scriptje dat de common name van het certificaat in de remote-user header stopt). Dus als ik naar mijn Navidrome surf krijg ik eerst de optie mezelf te authenticeren met een certificaat. Bied ik die niet aan, dan kan ik met Authelia inloggen.

Certificaat gebruik ik vanuit Symfonium en werkt prima. De Authelia inlog is handig voor als ik bijvoorbeeld op kantoor ben.

Conclusie: Traefik is cool (en Claude ook).