Waar slaat Nextcloud in Docker bestanden op?

Waar Nextcloud in Docker bestanden opslaat

Nextcloud in Docker slaat bestanden op in een datamap binnen de container. De werkelijke locatie op uw server is het volume of de bind mount die u eraan heeft gekoppeld. Bij de image van linuxserver.io, lscr.io/linuxserver/nextcloud, bevinden gebruikersbestanden zich in /data en de Nextcloud-installatie met zijn config.php in /config. Beide zijn paden binnen de container. Eén commando toont het host-pad erachter, en de rest van deze handleiding behandelt het complexere deel van de vraag: alles wat de datamap niet bevat.

Zet de image-tag vast. Paden horen bij een image en niet bij Nextcloud zelf; een zwevende tag kan onverwacht wijzigen. Sinds augustus 2026 is de huidige stabiele tag voor deze image 34.0.3.

services:
  nextcloud:
    image: lscr.io/linuxserver/nextcloud:34.0.3
    container_name: nextcloud
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
    volumes:
      - nextcloud_config:/config
      - nextcloud_data:/data
    ports:
      - 443:443
    restart: unless-stopped

  nextcloud-db:
    image: mariadb:11.8
    container_name: nextcloud-db
    environment:
      - MARIADB_ROOT_PASSWORD=${MARIADB_ROOT_PASSWORD}
      - MARIADB_DATABASE=nextcloud
      - MARIADB_USER=nextcloud
      - MARIADB_PASSWORD=${NEXTCLOUD_DB_PASSWORD}
    volumes:
      - nextcloud_db:/var/lib/mysql
    restart: unless-stopped

volumes:
  nextcloud_config:
  nextcloud_data:
  nextcloud_db:

De twee wachtwoorden zijn afkomstig uit een .env-bestand naast het compose-bestand, zodat ze buiten het compose-bestand zelf blijven. Dat zijn drie volumes in het antwoord, waarvan er slechts één gebruikersbestanden bevat.

Deze containerpaden zijn afkomstig uit de documentatie van die specifieke image. Een andere Nextcloud-image deelt het bestandssysteem anders in en houdt de installatie onder zijn eigen web root. Een pad dat u kopieert uit een forumpost is daarom een gok. Lees de feitelijke situatie af van de container die u draait.

docker inspect nextcloud

De Mounts-sectie van die uitvoer toont elke mount, met Source aan de host-zijde en Destination aan de container-zijde. Die lijst beantwoordt de vraag voor uw configuratie, ongeacht welke image u heeft gekozen.

Hoe vind ik het werkelijke hostpad achter het volume?

Een named volume wordt beheerd door Docker, dus u kiest het pad niet zelf. U vraagt het op.

docker volume ls
docker volume inspect nextcloud_nextcloud_data

De naam is van belang. Docker Compose voorziet volumenamen van een voorvoegsel op basis van de projectnaam. Deze is standaard gelijk aan de naam van de map waarin uw compose-bestand staat. Een volume dat in het bestand als nextcloud_data staat geschreven, bestaat op schijf meestal als nextcloud_nextcloud_data. docker volume ls toont de werkelijke namen. De output van inspect ziet er, ingekort, als volgt uit:

[
    {
        "CreatedAt": "2026-08-18T09:12:44Z",
        "Driver": "local",
        "Mountpoint": "/var/lib/docker/volumes/nextcloud_nextcloud_data/_data",
        "Name": "nextcloud_nextcloud_data",
        "Scope": "local"
    }
]

Mountpoint is het antwoord. Lees dit af van het commando in plaats van er vanuit te gaan, omdat het pad kan wijzigen. Bij rootless Docker bevindt de volledige Docker data root zich in de home-directory van de gebruiker die de daemon uitvoert, waardoor dat pad ergens anders begint.

Een bind mount maakt deze vraag overbodig. Schrijf - /srv/nextcloud/data:/data in het compose-bestand en het hostpad is het pad dat u heeft getypt, wat docker inspect rapporteert als de Source. Deze keuze verandert meer dan alleen het pad, omdat named volumes en bind mounts zich verschillend gedragen wat betreft eigenaarschap en back-ups.

Waarom de datamap geen back-up is

De Nextcloud-handleiding somt vijf onderdelen op die een back-up moet bevatten: de config-map, de map met aangepaste apps, de datamap, de thema-map en de database. Bij deze image bevinden de config-, apps- en thema-mappen zich allemaal onder /config, terwijl de database in een eigen container met een eigen volume draait. Kopieer alleen /data en u hebt het minst interessante deel van het probleem opgeslagen.

De database is van belang omdat de webinterface nooit een map weergeeft. Deze toont rijen uit de bestandscache; daarom adviseert de handleiding om een scan uit te voeren nadat u handmatig bestanden naar de datamap hebt gekopieerd. Herstel /data naast een lege database en u hebt bytes zonder index: geen gebruikers, geen shares, niets in de bestandenlijst. Herstel de database naast een lege /data en elke rij verwijst naar een bestand dat niet bestaat.

config.php bevat de database-inloggegevens en de vertrouwde domeinen. Het bevat ook de instance id, wat de naam is van de app-datamap binnen de datamap. Vraag het aan de draaiende instantie in plaats van te vertrouwen op waarden uit uw geheugen.

docker exec -it nextcloud occ config:system:get datadirectory
docker exec -it nextcloud occ config:system:get instanceid

Het eerste commando toont de datamap die deze instantie daadwerkelijk gebruikt, in dit geval /data. Deze image levert een occ-wrapper op het pad, dus voer het direct uit via docker exec. Kopieer niet de langere sudo- en php occ-vorm uit de Nextcloud-handleiding, die is geschreven voor een installatie buiten een container.

Wat vult stilletjes het datavolume?

Previews en de geschiedenis per gebruiker bevinden zich in hetzelfde volume als de bestanden, en geen van beide wordt getoond in het opslagcijfer dat een gebruiker in de webinterface ziet.

• Previews zijn gegenereerde miniaturen. Ze staan in de app-datamap binnen de datadirectory, genaamd appdata_ gevolgd door het instance-id.
• Verwijderde bestanden blijven in de prullenbak staan. trashbin_retention_obligation staat standaard op auto, wat ze 30 dagen bewaart en daarna alleen verwijdert wanneer er ruimte nodig is. Verwijderde bestanden tellen nog steeds mee voor het gebruikersquotum; wanneer het quotum wordt overschreden, wordt de retentie-instelling genegeerd en wordt de prullenbak opgeschoond totdat het weer binnen het quotum past.
• Oude versies blijven ook staan. versions_retention_obligation staat eveneens standaard op auto. De Versions-app gebruikt nooit meer dan 50% van de ruimte die een gebruiker op dat moment vrij heeft. Bij het opschonen worden eerst de oudste versies verwijderd, waarbij de twee meest recente behouden blijven. Een versie die door een gebruiker handmatig is benoemd, wordt nooit verwijderd.

Meet de situatie voordat u iets verwijdert.

docker exec -it nextcloud sh -c 'du -sh /data/*'
docker exec -it nextcloud sh -c 'du -sh /data/appdata_*'

De eerste regel geeft één getal per gebruikersmap plus de app-datamap. Als het getal van de app-data groot is, zijn previews de oorzaak. De onderstaande opschooncommando's zijn gedocumenteerd en elk ervan vernietigt bewust data.

docker exec -it nextcloud occ trashbin:cleanup --all-users
docker exec -it nextcloud occ versions:cleanup alice
docker exec -it nextcloud occ preview:cleanup

preview:cleanup verwijdert elke gegenereerde preview. Nextcloud genereert deze opnieuw zodra gebruikers die bestanden openen, waardoor de ruimte geleidelijk terugkeert en de CPU de verwerkingslast draagt. Als het volume slechts één onderdeel is van een breder schijfprobleem, zijn oude afbeeldingen en verouderde build-cache meestal het andere deel.

Waarom verschijnen bestanden die ik naar de host kopieer niet in Nextcloud?

Omdat Nextcloud de bestandscache uit de database leest en niet rechtstreeks uit de map. Uw kopieeractie heeft een bestand op de schijf aangemaakt zonder bijbehorende database-entry, waardoor de webinterface niets heeft om weer te geven. De handleiding beschrijft dit specifieke scenario: een scan is vereist nadat bestanden direct naar de datamap zijn gekopieerd.

docker exec -it nextcloud occ files:scan --path="/alice/files/Photos"
docker exec -it nextcloud occ files:scan --unscanned -v
docker exec -it nextcloud occ files:scan --all

Het --path-argument toont ook de structuur binnen de datamap: elke gebruiker heeft een map die vernoemd is naar hun gebruikersnaam, en files daarbinnen bevat wat zij in de webinterface zien. Scan één pad wanneer u weet waar de bestanden zijn geplaatst. --all doorloopt elke gebruiker en duurt lang bij een grote instantie. --unscanned verwerkt alleen bestanden die als nog niet volledig gescand zijn gemarkeerd. -v toont elk bestand terwijl het wordt verwerkt; dit is het verschil tussen een commando dat vastgelopen lijkt en een proces dat u kunt volgen.

Eigenaarschap bepaalt of de scan voldoende is. Een bestand waar de containergebruiker niet naar kan schrijven, wordt wel geïndexeerd maar weigert vervolgens te verplaatsen. Hierdoor lijkt de lijst correct, terwijl het hernoemen of verwijderen vanuit de webinterface mislukt.

Waarom mislukken schrijfacties nadat ik PUID en PGID heb ingesteld?

Omdat de kernel getallen vergelijkt, geen namen. PUID en PGID bepalen het numerieke user id (uid) en group id (gid) waaronder het containerproces wordt uitgevoerd. Elk bestand op de host heeft ook een numerieke eigenaar. Wanneer de twee getallen verschillen, wordt de schrijfactie geweigerd, ongeacht hoe de namen aan beide kanten eruitzien.

docker exec -it nextcloud id abc
sudo ls -ln /var/lib/docker/volumes/nextcloud_nextcloud_data/_data

id abc toont het uid en gid dat de container daadwerkelijk gebruikt; dit zijn de PUID en PGID die u heeft ingesteld. ls -ln toont numerieke eigenaren, en de -n is hierbij van belang: een standaard ls -l vertaalt die getallen via de gebruikerslijst van de host en toont een naam die binnen de container geen betekenis heeft. Vergelijk de twee getallen.

Test de schrijfactie vervolgens in plaats van te gokken.

docker exec -u abc -it nextcloud touch /data/writetest

Een Permission denied waarbij /data wordt genoemd, is de bevestiging. Herstel het eigenaarschap vanuit de container en voer de test daarna opnieuw uit.

docker exec -u 0 -it nextcloud chown -R abc:abc /data
docker exec -u abc -it nextcloud touch /data/writetest
docker exec -u abc -it nextcloud rm /data/writetest

Er is een reden om dit vanuit de container te doen. Bij rootless Docker worden de user ids van de container gemapt via het onderliggende bereik in /etc/subuid, waardoor uid 1000 binnen de container op de host bij een veel hoger uid hoort. Een chown 1000:1000 aan de host-zijde stelt dan een eigenaar in die de container niet kan gebruiken, waardoor de schrijfactie alsnog mislukt. Het uitvoeren van chown binnen de container verloopt via dezelfde mapping die het Nextcloud-proces zelf gebruikt, waardoor de getallen door de constructie altijd overeenkomen. Dit is ook de reden waarom PUID en PGID moeten overeenkomen met de eigenaar op de schijf voordat u met andere vormen van debugging begint.

Hoe maak ik een back-up zodat het herstel ook daadwerkelijk werkt?

Neem de database en de mappen op exact hetzelfde moment. De onderhoudsmodus blokkeert inlogpogingen, zodat er geen uploads plaatsvinden tussen de dump en de kopie.

docker exec -it nextcloud occ maintenance:mode --on
docker exec nextcloud-db mariadb-dump --single-transaction -u nextcloud -p"$NEXTCLOUD_DB_PASSWORD" nextcloud > nextcloud-sqlbkp.sql
docker run --rm -v nextcloud_nextcloud_data:/data:ro -v "$PWD":/backup alpine:3.22 tar czf /backup/nextcloud-data.tgz -C /data .
docker run --rm -v nextcloud_nextcloud_config:/config:ro -v "$PWD":/backup alpine:3.22 tar czf /backup/nextcloud-config.tgz -C /config .
docker exec -it nextcloud occ maintenance:mode --off

Let op wat er ontbreekt in de dump-regel: een -t-vlag. Een TTY herschrijft regeleinden, en een SQL-dump die hierdoor is verwerkt, raakt op een manier corrupt die u pas ontdekt tijdens het herstel. Merk ook op dat een wachtwoord op een opdrachtregel zichtbaar is in de ps-uitvoer terwijl het commando draait; lees het daarom vanuit uw .env-bestand in de shell in plaats van het te typen. Oudere database-images leveren mysqldump in plaats van mariadb-dump, en de handleiding documenteert beide.

Om te herstellen, laadt u de dump in een lege database, pakt u beide archieven uit in nieuwe volumes, start u de containers en schakelt u vervolgens de onderhoudsmodus uit. Als de mappen en de dump van verschillende momenten komen, komen de bestandscache en de schijf niet overeen, en occ files:scan --all repareert slechts één richting. Het vindt bestanden die bestaan zonder bijbehorende rij. Het kan geen bestand terughalen waarnaar een rij verwijst.

Bewaar het resultaat buiten de server. Een kopie die op dezelfde VPS staat, gaat verloren als de VPS uitvalt. Daarom hoort restic naar een externe repository in deze cyclus thuis, en daarom is een provider-snapshot een ander hulpmiddel dan een back-up. Als u de stack nog aan het opbouwen bent, behandelt een volledige Nextcloud-installatie op een VPS de reverse proxy en het TLS (transport layer security)-certificaat die in deze handleiding buiten beschouwing worden gelaten.

FAQ

Waar bevindt zich de Nextcloud-datamap in een Docker-container?

Bij de linuxserver.io-image is dit /data binnen de container, en de installatie met config.php bevindt zich onder /config. Dit zijn containerpaden. Voor het hostpad voert u docker inspect nextcloud uit en leest u de waarde Source in de sectie Mounts, of voert u docker volume inspect uit op het volume en leest u Mountpoint. Andere Nextcloud-images gebruiken andere containerpaden; controleer daarom de documentatie van de door u gebruikte tag en verifieer dit met docker exec -it nextcloud occ config:system:get datadirectory.

Waarom verschijnen bestanden die ik naar het volume kopieer niet in Nextcloud?

Nextcloud toont rijen uit de bestandscache in de database in plaats van de map te lezen. Een bestand dat zonder tussenkomst van Nextcloud wordt geplaatst, heeft geen rij en blijft onzichtbaar. Voer docker exec -it nextcloud occ files:scan --path="/alice/files/Photos" uit voor één map, of occ files:scan --all voor elke gebruiker. Als de bestanden wel verschijnen maar niet kunnen worden verplaatst of verwijderd, is de eigenaarschap de oorzaak: de containergebruiker moet schrijfrechten hebben op deze bestanden.

Is een kopie van het datavolume voldoende om Nextcloud te herstellen?

Nee. Het datavolume bevat de bestandsinhoud. De database bevat de bestandsindex, gebruikers en gedeelde mappen, en config.php bevat de database-inloggegevens en het instance-id. Een werkend herstel vereist de datamap, de configuratiemap, de database en de mappen voor aangepaste apps en thema's indien u deze gebruikt. Neem al deze onderdelen van hetzelfde tijdstip; een database die nieuwer is dan de bestanden verwijst naar bestanden die niet bestaan.

Waarom is mijn datavolume veel groter dan de bestanden die mijn gebruikers zien?

Previews, verwijderde bestanden en oude versies bevinden zich in hetzelfde volume en deze worden niet meegeteld in het totaaloverzicht van de gebruiker. Meet dit met docker exec -it nextcloud sh -c 'du -sh /data/*'. De prullenbak bewaart verwijderde bestanden standaard 30 dagen en verwijdert ze alleen eerder als er ruimte nodig is. De Versions-app kan tot de helft van de vrije ruimte van een gebruiker in beslag nemen. Verwijder deze met occ trashbin:cleanup --all-users, occ versions:cleanup alice en occ preview:cleanup. Houd er rekening mee dat previews weer aangroeien zodra gebruikers hun bestanden openen.

Kan ik de Nextcloud-datamap verplaatsen naar een andere schijf?

Koppel de nieuwe locatie aan hetzelfde containerpad in plaats van het pad te wijzigen dat bij Nextcloud bekend is. Stop de container, kopieer de oude inhoud naar de nieuwe schijf met behoud van eigenaarschap (cp -a of rsync -aAX), wijs het volume of de bind mount in uw compose-bestand naar de nieuwe locatie en start de container opnieuw. Nextcloud ziet nog steeds /data, waardoor er geen rijen in de database hoeven te worden gewijzigd. Controleer dit met docker exec -it nextcloud occ config:system:get datadirectory en een test-upload.