Docker Mount: volumes, bind mounts en tmpfs uitgelegd

Je hebt net de Docker-container gestopt om een configuratiebestand te updaten, maar na het herstarten bleek alle data weg. Ik ben daar ook geweest.

Dat gebeurt omdat containers standaard vergankelijk zijn – wanneer ze verwijderd worden, verdwijnt alle data die in hun schrijfbare laag staat. Echte applicaties kunnen zo niet werken. Je hebt databases nodig die blijven bestaan, configbestanden die herstarts overleven en logs die je daadwerkelijk kunt benaderen.

Docker mount lost dit probleem op door containeropslag te koppelen aan externe locaties. Er zijn drie types: volumes voor productiedata, bind mounts voor ontwikkelworkflows en tmpfs voor tijdelijke bestanden in het geheugen.

In dit artikel laat ik je zien hoe je het juiste mounttype kiest voor jouw usecase en het correct implementeert. Om alles in dit artikel te begrijpen, heb je een redelijke kennis van Docker en containerisatie nodig. Volg onze Intermediate Docker-cursus om snel bij te spijkeren.

Hoe Docker met opslag omgaat

Docker-containers gebruiken een gelaagd bestandssysteem dat standaard alles als tijdelijk beschouwt.

Wanneer je een Docker-image bouwt, creëert elke instructie in je Dockerfile een nieuwe, alleen-lezen laag. Deze lagen stapelen zich op als een kaartspel. Als je een Ubuntu-image met Python binnenhaalt, krijg je één laag voor het basis-OS en een andere voor Python.

Het addertje is dat al deze lagen alleen-lezen zijn. Je kunt ze niet aanpassen.

Het containerbestandssysteem en de schrijfbare laag

Wanneer je een container start, voegt Docker nog één laag toe bovenop - de schrijfbare containerlaag.

Hier gebeuren alle wijzigingen. Elk bestand dat je maakt, elke config die je aanpast en elk record dat je toevoegt, komt hier terecht.

Klinkt goed, maar het probleem is dat deze laag gekoppeld is aan de levenscyclus van de container.

Als je de container stopt en verwijdert met docker rm, is de schrijfbare laag weg. Alles waar je aan gewerkt hebt, is weg. Docker vraagt geen bevestiging. Het verwijdert gewoon alles.

Dit ontwerp is logisch voor stateless apps die niets hoeven te onthouden tussen runs. Maar echte applicaties zijn niet stateless.

Waarom mounts nodig zijn

De schrijfbare laag heeft twee grote problemen voor productieomgevingen.

Ten eerste, je verliest data wanneer containers stoppen. Wat heb je aan een databasecontainer die na een herstart alle rijen vergeet? Ik kan niets bedenken behalve het draaien van integratietests voor je app.

Ten tweede, je kunt geen data delen tussen containers. Stel dat je een webapp en een background worker draait die beide toegang tot dezelfde bestanden nodig hebben. Als die bestanden in de schrijfbare laag van één container staan, kan de andere container ze niet zien.

Docker-mounts lossen beide problemen op door containers te verbinden met opslag die buiten de containerlevenscyclus bestaat. Je kunt een map van je hostmachine of een door Docker beheerd volume mounten. Je data blijft bestaan, zelfs als containers worden verwijderd. Meerdere containers kunnen dezelfde locatie mounten en in realtime bestanden delen.

Daarom moet je mounts gebruiken. Laten we straks de mounttypes doornemen en dan laat ik zien hoe ze werken.

Docker-mounttypes in vogelvlucht

Docker geeft je drie manieren om met persistente data om te gaan, en elk lost andere problemen op. Dit is wat elk type doet en wanneer je het gebruikt.

Volumes

Volumes zijn Docker's standaardantwoord op persistente opslag.

Docker maakt en beheert volumes voor je in een speciale map op je hostmachine. Je hoeft niet te weten waar die map is; dat wordt allemaal voor je geregeld. Dit maakt volumes overdraagbaar tussen systemen en veilig voor productiegebruik.

Wanneer je een container verwijdert, blijft het volume intact. Als je een nieuwe container start en hetzelfde volume koppelt, staat al je data gewoon waar je het achterliet.

Volumes werken het best voor productiedatabases, applicatiestatus en alle data die je niet mag verliezen.

Bind mounts

Bind mounts koppelen een specifieke map op je hostmachine rechtstreeks aan een container.

Je kiest het exacte pad op je host - zoals /home/user/project - en Docker mappt het in de container. Als je een bestand op je host wijzigt, ziet de container die wijziging direct. Pas je een bestand in de container aan, dan verschijnt het op je host.

Deze realtime sync maakt bind mounts ideaal voor ontwikkeling.

Maar bind mounts brengen risico's met zich mee. Ze stellen hostpaden bloot aan containers en zijn afhankelijk van specifieke mapstructuren die op andere machines misschien niet bestaan.

tmpfs-mounts

tmpfs-mounts slaan data op in het geheugen van je host in plaats van op schijf.

Er wordt niets naar het bestandssysteem geschreven. Wanneer de container stopt, verdwijnt de data volledig. Dit maakt tmpfs-mounts handig voor tijdelijke data die je niet wilt bewaren - denk aan authenticatietokens, sessiedata of cachebestanden die je toch opnieuw opbouwt.

Dat gezegd hebbende, tmpfs-mounts worden beperkt door het beschikbare RAM en werken alleen op Linux-hosts.

Docker-volumes voor persistente data

Volumes zijn Docker's productieklare opslagoplossing, en je zou ze standaard moeten gebruiken tenzij je een specifieke reden hebt om dat niet te doen.

Ze worden volledig door Docker beheerd, werken consistent op verschillende platforms en overleven het verwijderen van containers. Als je databases draait, applicatiestatus opslaat of met data werkt die langer mee moet gaan dan één container, dan zijn volumes het antwoord.

Hoe Docker-volumes werken

Docker bewaart volumes in een speciale map op je hostmachine:

• Linux: /var/lib/docker/volumes/
• macOS: ~/Library/Containers/com.docker.docker/Data/vms/0/data/
• Windows: \\wsl$\docker-desktop-data\data\docker\volumes\, uitgaande van WSL2-backend

Je beheert deze map niet zelf. Docker regelt aanmaak, permissies en opschoning via de eigen API. Deze scheiding betekent dat volumes op Linux, Mac en Windows hetzelfde werken, wat je container-setup overdraagbaar maakt tussen ontwikkel- en productieomgevingen.

Belangrijk om te onthouden is dat volumes onafhankelijk van een container bestaan. Als je een volume maakt, het aan een container koppelt, je app draait en die container vervolgens stopt en verwijdert, dan blijft het volume precies staan met alle data intact.

Start je een nieuwe container en koppel je hetzelfde volume, dan staat je data er nog steeds.

Volumes maken en hergebruiken

Je kunt een benoemd volume aanmaken voordat je een container start:

docker volume create mydata

Koppel het vervolgens bij het starten van een container met de --mount-vlag:

docker run -d \
  --name postgres-db \
  --mount source=mydata,target=/var/lib/postgresql/data \
  postgres:18

Dit mount het mydata-volume op /var/lib/postgresql/data in de container, waar Postgres zijn databasebestanden bewaart.

Je kunt deze container nu stoppen en verwijderen, en daarna een nieuwe starten met hetzelfde volume:

docker rm -f postgres-db

docker run -d \
  --name postgres-db-new \
  --mount source=mydata,target=/var/lib/postgresql/data \
  postgres:18

Je database is terug met alle tabellen en rijen intact.

Dat is precies het punt van volumes: datapersistentie over containerlevenscycli heen.

Volume-data beheren en onderhouden

Je kunt deze opdracht draaien om te zien welke volumes op je systeem bestaan:

docker volume ls

Vervolgens kun je deze opdracht draaien om een specifiek volume te inspecteren en te zien waar het is opgeslagen en welke containers het gebruiken:

docker volume inspect mydata

Dit toont het aankoppelpunt op je host en nuttige metadata. Maar je hoeft zelden direct toegang tot deze map te hebben - dat is de taak van Docker.

Als je klaar bent met het volume en het wilt verwijderen, draai dan deze opdracht:

docker volume rm mydata

Docker laat je geen volume verwijderen dat aan een draaiende container is gekoppeld. Stop eerst de container en verwijder dan het volume.

Als je tot slot resources wilt opschonen en schijfruimte wilt terugwinnen, kun je deze opdracht draaien om alle ongebruikte volumes in één keer te verwijderen:

docker volume prune

Voor productiesetups ondersteunt Docker volumedrivers die verbinding maken met externe opslagsystemen zoals NFS, AWS EFS of cloud-blokopslag. Je specificeert de driver bij het maken van het volume, en Docker regelt de rest. Hiermee kun je data volledig buiten je hostmachine opslaan, wat belangrijk is voor high-availability-omgevingen waar containers tussen servers verplaatsen.

Hierna bespreken we bind mounts.

Bind mounts voor lokale ontwikkeling

Bind mounts geven je directe toegang tot het bestandssysteem van je host vanuit een container, en precies daarom zijn ontwikkelaars er dol op.

Ze zijn perfect voor lokale ontwikkeling, maar hebben afwegingen die ze riskant maken voor productie. Je krijgt realtime bestandssync en geen buildstappen, maar je verliest overdraagbaarheid en kunt veiligheidslekken openen.

Hoe bind mounts werken

Een bind mount mappt een specifieke map op je hostmachine rechtstreeks in een container.

Je specificeert het exacte pad - zoals /home/user/myapp - en Docker stelt het beschikbaar op een pad in de container. Er is geen kopiëren, geen door Docker beheerde opslag, geen abstractielaag. De container ziet je echte hostbestanden.

Als je een bestand op je host wijzigt, ziet de container dat direct. Pas je een bestand in de container aan, dan wordt het op je host bijgewerkt. Beide kanten werken in realtime met dezelfde bestanden.

Hier is een bind mount in actie:

docker run -d \
  --name dev-app \
  --mount type=bind,source=/Users/dradecic/Desktop/app,target=/app \
  python:3.14

Dit mount /Users/dradecic/Desktop/app van mijn host naar /app in de container. Wanneer ik een Python-bestand in /Users/dradecic/Desktop/app met je teksteditor bewerk, ziet de gecontaineriseerde app de wijziging meteen.

Je kunt ook de kortere syntax gebruiken:

Veelvoorkomende ontwikkelworkflows

De meest voorkomende usecase is het mounten van je broncode tijdens ontwikkeling.

Stel dat je een FastAPI-applicatie bouwt. Je kunt je projectmap in de container mounten, hot reload inschakelen en je hebt een volledige ontwikkelomgeving:

docker run -d \
  --name fastapi-dev \
  --mount type=bind,source=/Users/dradecic/Desktop/app,target=/app \
  -w /app \
  -p 8000:8000 \
  python:3.14 \
  sh -c "pip install fastapi uvicorn && uvicorn main:app --reload --host 0.0.0.0"

Ter referentie, dit is mijn main.py-bestand:

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI(
    title="FastAPI Docker Demo",
    description="A minimal FastAPI app running inside Docker",
    version="1.0.0",
)

class Item(BaseModel):
    name: str
    price: float
    in_stock: bool = True

@app.get("/")
def read_root():
    return {
        "message": "FastAPI is running",
        "docs": "/docs",
        "redoc": "/redoc",
    }

@app.get("/health")
def health_check():
    return {"status": "ok"}

@app.post("/items")
def create_item(item: Item):
    return {
        "message": "Item received",
        "item": item,
    }

Na het draaien van het Docker-commando is de app vanaf mijn hostmachine beschikbaar op poort 8000:

Als je main.py in je editor bewerkt en opslaat, zal FastAPI automatisch herladen. Geen images rebuilden, geen containers herstarten. Je schrijft code zoals lokaal, maar je app draait in een consistente containeromgeving.

Risico's en beperkingen

Bind mounts stellen je hostbestandssysteem bloot aan containers, en dat kan veiligheidsproblemen veroorzaken.

Een container met een bind mount kan bestanden op je host lezen en schrijven. Draai je een container als root - wat de standaard is - dan heeft die roottoegang tot die gemounte bestanden. Kwaadaardige code of een gecompromitteerde container kan alles in de gemounte map aanpassen of verwijderen.

Overdraagbaarheid is een ander probleem.

Bind mounts zijn afhankelijk van specifieke paden op de host. De /Users/dradecic/Desktop/app bestaat niet op jouw machine of op een productieserver. Dit breekt de belofte van "werkt overal" van containers.

Platformverschillen spelen ook mee. Windows en Mac gebruiken een VM om Docker te draaien, dus bind mounts gaan door een extra translatielaag. Dat maakt bestandsbewerkingen trager en kan subtiele bugs veroorzaken met file watching en symlinks.

Productieomgevingen zouden nooit bind mounts moeten gebruiken.

Ze zijn te afhankelijk van hostspecifieke paden, te riskant qua beveiliging en onmogelijk te versioneren. Volumes lossen al deze problemen op, daarom zijn ze de standaard in productie.

Behandel bind mounts als een ontwikkeltool - snel, handig en krachtig, maar niet iets wat je in de buurt van productie wilt hebben.

tmpfs-mounts voor tijdelijke data

tmpfs-mounts slaan data op in het RAM van je host in plaats van op schijf. Dat maakt ze perfect voor data die je niet wilt behouden.

Gedrag van opslag in het geheugen

Een tmpfs-mount bestaat volledig in het geheugen.

Docker reserveert RAM op je hostmachine en stelt het beschikbaar als een bestandssysteem in de container. Een bestand dat naar een tmpfs-mount wordt geschreven, raakt je schijf nooit. De data blijft in het geheugen totdat de container stopt.

Wanneer je de container stopt, wordt alles in de tmpfs-mount verwijderd. Er is geen opschoning nodig, geen achtergebleven bestanden, geen spoor van wat er was. Elke keer dat je de container herstart, krijg je een frisse, lege tmpfs-mount.

Kortom, tmpfs-mounts zijn voor data die je expliciet niet wilt bewaren - tijdelijke berekeningen, sessietokens of gevoelige info die niet mag blijven bestaan na gebruik.

Typische usecases

De meest voorkomende usecase is het opslaan van secrets of gevoelige data.

Stel dat je een container draait die een API-sleutel of databasewachtwoord nodig heeft. Sla het op in een tmpfs-mount en het secret wordt nooit op schijf bewaard. Als de container stopt, verdwijnt het secret uit het geheugen. Er is geen bestand dat je per ongeluk commit of zichtbaar laat op het bestandssysteem.

Caches zijn ook een goede match. Build-artifacten, gecompileerde code of gedownloade dependencies die je toch opnieuw genereert, hoeven niet te blijven bestaan. Zet ze in tmpfs voor snellere toegang tijdens de levensduur van de container en laat ze verdwijnen wanneer je klaar bent.

Tijdelijke bestanden werken hier ook goed - denk aan sessiedata, lockfiles of tussentijdse resultaten die alleen relevant zijn terwijl de container draait.

Basisconfiguratie

Draai dit commando om een tmpfs-mount te maken met de --tmpfs-vlag:

docker run -d \
  --name temp-app \
  --tmpfs /tmp:rw,size=100m \
  python:3.14

Dit maakt een tmpfs-mount van 100MB op /tmp in de container. Met de optie size beperk je hoeveel RAM de mount mag gebruiken.

Je kunt ook de --mount-syntax gebruiken:

docker run -d \
  --name temp-app \
  --mount type=tmpfs,destination=/tmp,tmpfs-size=104857600 \
  python:3.14

De waarde tmpfs-size is in bytes - 104857600 bytes is 100MB.

Als je geen grootte opgeeft, gebruikt tmpfs tot de helft van het RAM van je systeem. Dat is riskant - om voor de hand liggende redenen. Stel altijd expliciete limieten in.

Het enige grote nadeel is dat tmpfs-mounts alleen op Linux werken.

Mac en Windows Docker Desktop ondersteunen ze niet omdat Docker daar binnen een Linux-VM draait en tmpfs directe kernelsupport vereist.

Docker-mountsyntax en configuratie

Docker geeft je twee manieren om mounts te definiëren, en de juiste syntax kiezen maakt je commando's leesbaarder en makkelijker te debuggen.

Beide benaderingen werken, maar de ene schaalt beter wanneer je geavanceerde opties of meerdere mounts in één container nodig hebt.

--mount vs --volume

De --mount-vlag gebruikt expliciete key-valueparen, terwijl -v of --volume een door dubbele punten gescheiden string gebruikt.

Hier is dezelfde volumemount met beide syntaxes:

# Using --mount
docker run -d \
  --mount type=volume,source=mydata,target=/app/data \
  python:3.14

# Using -v
docker run -d \
  -v mydata:/app/data \
  python:3.14

Beide maken een volume met de naam mydata en mounten het op /app/data in de container.

Gebruik --mount voor alles wat verder gaat dan basissetups. Het is uitgebreider, maar de expliciete keys maken duidelijk wat elk deel doet. Wanneer je opties toevoegt zoals alleen-lezen toegang of aangepaste volumedrivers, blijft het leesbaar terwijl -v als een cryptische string kan ogen.

De -v-syntax is prima voor simpele ontwikkelworkflows waarbij je commando's met de hand typt.

Veelgebruikte mountopties

De optie readonly voorkomt dat containers gemounte data wijzigen:

docker run -d \
  --mount type=volume,source=mydata,target=/app/data,readonly \
  python:3.14

Dit is handig voor configuratiebestanden of referentiedata die containers wel moeten lezen maar nooit mogen aanpassen. Een container die naar een readonly-mount schrijft, krijgt een permissiefout.

Voor volumes slaat de optie volume-nocopy het kopiëren van bestaande data uit het containerimage naar het volume over:

docker run -d \
  --mount type=volume,source=mydata,target=/app/data,volume-nocopy \
  python:3.14

Standaard kopieert Docker wat er op het mountpunt in het image staat naar een nieuw volume. Als je volume-nocopy instelt, krijg je een leeg volume ongeacht wat er in het image staat.

Voor tmpfs-mounts stelt de optie tmpfs-size een geheugenlimiet in:

docker run -d \
  --mount type=tmpfs,target=/tmp,tmpfs-size=104857600 \
  python:3.14

Dit begrenst de tmpfs-mount tot 100MB. Zonder dit kan een tmpfs-mount al het beschikbare RAM gebruiken.

Mounten over bestaande data heen

Wanneer je mount op een map die al in het containerimage bestaat, verbergt de mount volledig wat daar stond.

Stel dat je image een map /app/data met ingebouwde configbestanden heeft. Wanneer je een volume op /app/data mount, verdwijnen die configbestanden. De container ziet alleen wat er in het volume staat.

Dit gebeurt bij alle mounttypes - volumes, bind mounts en tmpfs. De gemounte inhoud krijgt voorrang en de originele map is niet toegankelijk zolang de mount actief is.

Mounts gebruiken met Docker Compose

Docker Compose maakt het eenvoudig om mounts te definiëren en te delen tussen meerdere containers in je applicatiestack.

In plaats van lange docker run-commando's met mountvlaggen te typen, definieer je alles in een docker-compose.yml-bestand. Ik laat je zien hoe.

Volumes en bind mounts definiëren in Compose

Hier is een Compose-bestand met zowel volume- als bind mount-voorbeelden:

services:
  service-1:
    image: ubuntu:latest
    command: sleep infinity
    volumes:
      - ./code:/app          # Bind mount for development
      - shared:/data         # Named volume shared with worker

  service-2:
    image: ubuntu:latest
    command: sleep infinity
    volumes:
      - shared:/data         # Same volume as service-1

volumes:
  shared:

De sleutel volumes onder elke service definieert wat er wordt gemount. Relatieve paden zoals ./code maken bind mounts, terwijl namen zoals shared naar benoemde volumes verwijzen.

De toplevelsectie volumes declareert benoemde volumes die Compose aanmaakt en beheert. Zowel service-1 als service-2 mounten hetzelfde shared-volume, zodat ze dezelfde bestanden zien. Schrijf een bestand vanuit de ene container en de andere kan het direct lezen.

Het commando sleep infinity houdt containers draaiend zodat je erin kunt exec'en - puur ter demonstratie.

Data persistent maken en verifiëren

Start je stack met docker compose up -d, en controleer dan of mounts werken:

# Write data to the shared volume from app
docker compose exec service-1 sh -c "echo 'test' > /data/file.txt"

# Read it from worker
docker compose exec service-2 cat /data/file.txt

Als beide commando's werken, zijn je volumes correct geconfigureerd.

Je kunt nu dit commando draaien om alles te stoppen en te verwijderen:

docker compose down

Je benoemde volumes blijven aanwezig. Als je de stack opnieuw start met docker compose up -d, staat de data die je eerder schreef er nog. Zo blijven databases bewaard over deployments heen - het volume overleeft de container.

Wil je volumes verwijderen wanneer je de stack stopt, voeg dan de -v-vlag toe:

docker compose down -v

Dit verwijdert alle volumes die in je Compose-bestand zijn gedefinieerd. Gebruik het wanneer je een schone lei wilt.

Volumes vullen met initiële data

Het meest voorkomende patroon is het gebruik van een aparte init-container om het gedeelde volume te seeden:

services:
  init:
    image: ubuntu:latest
    command: sh -c "mkdir -p /source && echo 'initial data' > /source/seed.txt && cp /source/* /dest/"
    volumes:
      - shared:/dest

  service-1:
    image: ubuntu:latest
    command: sleep infinity
    depends_on:
      - init
    volumes:
      - shared:/data

  service-2:
    image: ubuntu:latest
    command: sleep infinity
    depends_on:
      - init
    volumes:
      - shared:/data

volumes:
  shared:

De init-container maakt seeddata en kopieert die naar het shared-volume en stopt daarna. Zowel service-1 als service-2 starten daarna en vinden de ge-seede data klaar voor gebruik.

Compose regelt de complexiteit van het coördineren van meerdere containers en hun gedeelde opslag in één versiebeheerd bestand.

Prestatie en beveiliging van Docker-mounts

Het verkeerde mounttype kiezen kan je containers vertragen of beveiligingslekken creëren waarvan je het bestaan niet wist. Lees dit onderdeel als je dat wilt voorkomen.

Prestatieafwegingen tussen mounttypes

Volumes bieden de beste prestaties op Linux omdat ze direct op het hostbestandssysteem worden opgeslagen zonder vertaal-laag.

Op Mac en Windows draait Docker binnen een Linux-VM. Volumes presteren daar nog steeds goed omdat ze binnen die VM blijven. Bind mounts moeten daarentegen bestanden synchroniseren tussen je host-OS en de Linux-VM, wat overhead toevoegt. Bestandsoperaties op bind mounts kunnen op Mac en Windows aanzienlijk trager zijn dan op native Linux.

tmpfs is de snelste optie voor lezen en schrijven omdat alles in RAM gebeurt. Geen disk I/O, geen bestandssysteem-overhead. Maar je wordt beperkt door het beschikbare geheugen en data verdwijnt wanneer de container stopt.

Als je op Linux zit en maximale performance nodig hebt, gebruik dan volumes. Als je op Mac of Windows trage bestandsoperaties merkt tijdens ontwikkeling, is dat waarschijnlijk bind mount-overhead. Schakel over op volumes voor productieworkloads.

Beveiligingsimplicaties van mounts

Elke mount geeft containers toegang tot iets buiten hun geïsoleerde bestandssysteem, en dat creëert risico.

Bind mounts zijn de grootste zorg. Als je /home/user mount in een container, kan een gecompromitteerde container je SSH-sleutels lezen, je shellconfig aanpassen of bestanden door je hele homedirectory verwijderen. Draai je die container als root - de standaard - dan heeft hij roottoegang tot die bestanden.

Volumes verkleinen dit risico omdat ze geïsoleerd zijn in Docker's opslagmap. Een container kan via volumes geen willekeurige hostpaden mounten. Maar volumes kunnen nog steeds data lekken tussen containers als je ze onzorgvuldig deelt.

tmpfs-mounts minimaliseren persistentierisico - secrets in het geheugen verdwijnen wanneer containers stoppen. Maar ze beschermen niet tegen runtime-aanvallen waarbij een gecompromitteerde container secrets uit het geheugen leest.

De algemene regel is dat mounts containerisolatie doorbreken, dus gebruik ze zorgvuldig.

Best practices voor veilige mounts

Mount alleen wat containers nodig hebben en niets meer.

In plaats van je hele projectmap te mounten, mount je alleen de submap die de container gebruikt. In plaats van /var/log met schrijfrechten te mounten, mount je die read-only als de container alleen logs hoeft te lezen.

Gebruik waar mogelijk de optie readonly:

docker run -d \
  --mount type=bind,source=/app/config,target=/config,readonly \
  ubuntu:latest

Dit voorkomt dat containers gemounte data aanpassen en beperkt de schade als ze gecompromitteerd raken.

Draai containers als niet-rootgebruikers om de impact van bind mount-kwetsbaarheden te verkleinen. Maak een gebruiker in je Dockerfile en schakel over voordat de container start:

RUN useradd -m appuser
USER appuser

Ruim ongebruikte volumes regelmatig op met docker volume prune. Oude volumes stapelen zich na verloop van tijd op, nemen schijfruimte in en kunnen mogelijk gevoelige data bevatten van verwijderde containers.

Mount nooit gevoelige hostmappen zoals /, /etc of /var tenzij je een specifieke reden hebt en de risico's begrijpt. Elke mount moet een duidelijk doel en minimale scope hebben.

Docker-mountproblemen oplossen

Mountproblemen uiten zich meestal als permissiefouten, ontbrekende bestanden of containers die niet willen starten - en ze worden bijna altijd veroorzaakt door dezelfde set issues.

Zo diagnosticeer en fix je de meest voorkomende problemen waar je tegenaan loopt.

Permissie- en eigendomsfouten

Permissiefouten ontstaan wanneer de gebruiker in de container geen toegang heeft tot gemounte bestanden.

Docker-containers draaien standaard als root. Wanneer root een bestand aanmaakt in een bind mount, is dat bestand eigendom van root op je host. Als je het met je reguliere gebruikersaccount probeert te bewerken, krijg je een "permission denied"-fout.

Het omgekeerde gebeurt ook. Mount een map die jij bezit in een container die als niet-rootgebruiker draait, en de container kan er mogelijk niet naar schrijven.

Je kunt bestands-eigendom controleren met ls -la in de gemounte map:

ls -la /path/to/mounted/directory

Als bestanden eigendom zijn van root maar je container draait als een andere gebruiker, heb je een mismatch. Los dat op door de container te draaien als dezelfde gebruiker die de bestanden bezit:

docker run -d \
  --user $(id -u):$(id -g) \
  -v ./data:/app/data \
  ubuntu:latest

Dit draait de container als je huidige gebruiker in plaats van root, zodat de eigendom van bestanden in de bind mount overeenkomt.

Voor volumes regelt Docker permissies automatisch wanneer containers bestanden aanmaken. Maar als je fouten ziet, controleer dan onder welke gebruiker de gecontaineriseerde app draait en of die schrijfrechten heeft op het mountpunt.

Pad- en configuratiefouten

De meest voorkomende fout is het mounten van een pad dat niet op de host bestaat.

Probeer /home/user/project te mounten terwijl die map niet bestaat, en Docker maakt een lege map aan die eigendom is van root. Je container start wel, maar mount het verkeerde - een lege map in plaats van je echte project.

Controleer altijd of paden bestaan voordat je ze mount:

ls /home/user/project

Als de map niet bestaat, maak hem dan eerst aan of corrigeer het pad in je mountcommando.

In Docker Compose worden relatieve paden opgelost vanuit de map waarin je docker-compose.yml staat. Als je bestand in /home/user/app/ staat en je gebruikt ./data, dan zoekt Docker naar /home/user/app/data.

Verplaats je het Compose-bestand, dan breekt de mount.

Een andere veelgemaakte fout is mounten op het verkeerde doelpad in de container. Mount op /app/data terwijl je app /data verwacht, en de app kan zijn bestanden niet vinden. Check de documentatie of Dockerfile van je app om te bevestigen waar data verwacht wordt.

Platformspecificieke eigenaardigheden

Op Linux werken bind mounts direct met het hostbestandssysteem.

Op Mac en Windows draait Docker in een Linux-VM. Bind mounts synchroniseren bestanden tussen je host-OS en die VM, wat timing-issues oplevert. File watchers - tools die je app herladen bij bestandswijzigingen - missen soms updates door syncvertragingen.

Mac en Windows gaan ook anders om met bestandspermissies. De VM vertaalt permissies tussen het host-OS en Linux, waardoor bestanden in containers soms met incorrecte eigenaarschap lijken te verschijnen.

Symlinks werken niet altijd betrouwbaar in bind mounts op Mac en Windows. De VM kan symlinks die buiten de gemounte map wijzen niet altijd oplossen, waardoor bestanden in containers ontbreken of kapot lijken.

tmpfs-mounts werken helemaal niet op Mac en Windows omdat de VM tmpfs niet aan de host blootstelt. Als je een tmpfs-mount probeert te gebruiken, negeert Docker het stilzwijgend of geeft het een fout, afhankelijk van de versie.

Als je op Mac of Windows ontwikkelt en last hebt van vreemde bestands-syncproblemen, schakel dan over op benoemde volumes voor betere prestaties en betrouwbaarheid. Bewaar bind mounts voor ontwikkelworkflows waar realtime sync belangrijker is dan perfecte consistentie.

Conclusie

Kortom: gebruik volumes voor productiedata die moet blijven bestaan, zoals databases, geüploade bestanden, applicatiestatus - alles wat je niet kunt verliezen. Ze worden door Docker beheerd, zijn platformonafhankelijk en de veiligste keuze voor belangrijke data.

Bind mounts horen bij ontwikkelworkflows waarin je realtime bestandssync tussen je host en containers nodig hebt. Wanneer je code in je editor wijzigt, zie je de veranderingen meteen in je gecontaineriseerde app. Maar houd ze uit productie: ze zijn te afhankelijk van hostspeficieke paden en creëren onnodige beveiligingsrisico's.

Als je klaar bent om dieper in containerisatie en virtualisatie te duiken, bekijk dan onze cursus: Containerization and Virtualization with Docker and Kubernetes.