Où sont stockés les fichiers Nextcloud dans Docker ?

Où Nextcloud dans Docker stocke les fichiers

Nextcloud dans Docker stocke les fichiers dans un répertoire de données à l’intérieur du conteneur. L’emplacement réel sur votre serveur dépend du volume ou du bind mount que vous lui avez associé. Avec l’image linuxserver.io, lscr.io/linuxserver/nextcloud, les fichiers des utilisateurs se trouvent dans /data, tandis que l’installation de Nextcloud et son config.php se trouvent dans /config. Ces deux chemins sont des chemins du conteneur. Une commande affiche le chemin correspondant sur l’hôte. La suite de ce guide traite de la partie la plus complexe de la question : tout ce que le répertoire de données ne contient pas.

Figez le tag de l’image. Les chemins dépendent de l’image, pas de Nextcloud, et un tag flottant peut changer sans préavis. En août 2026, le tag stable actuel de cette image est 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:

Les deux mots de passe proviennent d’un fichier .env placé à côté du fichier Compose. Ils restent ainsi en dehors du fichier Compose. La réponse comporte donc trois volumes, dont un seul contient les fichiers des utilisateurs.

Ces chemins du conteneur proviennent de la documentation de cette image précise. Une autre image Nextcloud peut organiser son système de fichiers différemment et placer l’installation sous son propre web root. Un chemin copié depuis un forum n’est donc qu’une supposition. Vérifiez la configuration réelle dans le conteneur que vous exécutez.

docker inspect nextcloud

La section Mounts de cette sortie répertorie tous les mounts, avec Source du côté de l’hôte et Destination du côté du conteneur. Cette liste répond à la question pour votre configuration, quelle que soit l’image choisie.

Comment trouver le chemin réel sur l’hôte derrière le volume ?

Un volume nommé est géré par Docker. Vous ne choisissez donc pas son chemin. Vous le demandez à Docker.

docker volume ls
docker volume inspect nextcloud_nextcloud_data

Le nom est important. Docker Compose préfixe les noms des volumes avec le nom du projet. Par défaut, celui-ci correspond au nom du répertoire qui contient votre fichier Compose. Ainsi, un volume écrit comme nextcloud_data dans le fichier existe généralement sous le nom nextcloud_nextcloud_data sur le disque. docker volume ls affiche les noms réels. La sortie de la commande inspect ressemble à ceci, après simplification :

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

Mountpoint est la réponse. Lisez cette valeur avec la commande au lieu de la supposer, car elle peut changer. Avec Docker rootless, l’ensemble de la racine de données Docker se trouve dans le répertoire personnel de l’utilisateur qui exécute le daemon. Le chemin commence donc ailleurs.

Un bind mount élimine cette question. Écrivez - /srv/nextcloud/data:/data dans le fichier Compose : le chemin sur l’hôte est alors celui que vous avez indiqué. docker inspect le signale comme Source. Ce choix modifie davantage que le chemin, car les volumes nommés et les bind mounts se comportent différemment concernant la propriété des fichiers et les sauvegardes.

Pourquoi le répertoire de données n’est pas une sauvegarde

Le manuel Nextcloud indique qu’une sauvegarde doit conserver cinq éléments : le répertoire de configuration, le répertoire des applications personnalisées, le répertoire de données, le répertoire du thème et la base de données. Avec cette image, les répertoires de configuration, des applications et du thème se trouvent tous sous /config, tandis que la base de données s’exécute dans son propre conteneur avec son propre volume. Si vous copiez uniquement /data, vous ne sauvegardez que la partie la moins intéressante du problème.

La base de données est essentielle, car l’interface web n’affiche jamais directement le contenu d’un répertoire. Elle affiche les lignes du file cache. C’est pourquoi le manuel demande d’exécuter un scan après avoir copié manuellement des fichiers dans le répertoire de données. Si vous restaurez /data à côté d’une base de données vide, vous obtenez des octets sans index : aucun utilisateur, aucun partage, rien dans la liste des fichiers. Si vous restaurez la base de données à côté d’un /data vide, chaque ligne pointe vers un fichier qui n’existe plus.

config.php contient les identifiants de la base de données et les domaines de confiance. Il contient également l’identifiant de l’instance, qui correspond au nom du répertoire de données de l’application dans le répertoire de données. Interrogez l’instance en cours d’exécution au lieu de vous fier à une valeur mémorisée.

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

La première commande affiche le répertoire de données réellement utilisé par cette instance, qui est /data ici. Cette image fournit un wrapper occ dans le PATH. Exécutez-le donc directement via docker exec. Ne copiez pas la forme plus longue sudo et php occ du manuel Nextcloud, car elle concerne une installation exécutée hors d’un conteneur.

Qu’est-ce qui remplit discrètement le volume de données ?

Les aperçus et l’historique propre à chaque utilisateur se trouvent dans le même volume que les fichiers. Aucun des deux n’apparaît dans l’indicateur de stockage affiché à l’utilisateur dans l’interface web.

• Les aperçus sont des miniatures générées automatiquement. Ils se trouvent dans le dossier de données de l’application, à l’intérieur du répertoire de données, sous un nom commençant par appdata_ suivi de l’identifiant de l’instance.
• Les fichiers supprimés restent dans la corbeille. trashbin_retention_obligation vaut par défaut auto. Cette valeur les conserve pendant 30 jours, puis les supprime uniquement lorsque de l’espace est nécessaire. Les fichiers supprimés sont toujours comptabilisés dans le quota de l’utilisateur. Lorsque le quota est dépassé, le paramètre de conservation est ignoré et la corbeille est vidée jusqu’à ce que le quota soit à nouveau respecté.
• Les anciennes versions sont également conservées. versions_retention_obligation vaut par défaut auto. L’application Versions n’utilise jamais plus de 50% de l’espace actuellement libre pour un utilisateur. Lors du nettoyage, elle supprime d’abord les versions les plus anciennes et conserve les deux plus récentes. Une version nommée manuellement par un utilisateur n’est jamais supprimée.

Mesurez avant de supprimer quoi que ce soit.

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

La première ligne indique un nombre pour chaque dossier utilisateur, ainsi que pour le dossier de données de l’application. Si ce nombre est élevé pour les données de l’application, les aperçus en sont la cause. Les commandes de nettoyage ci-dessous sont documentées. Chacune supprime volontairement des données.

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 supprime tous les aperçus générés. Nextcloud les génère à nouveau lorsque les utilisateurs ouvrent ces fichiers. L’espace est donc progressivement à nouveau occupé et le CPU doit effectuer ce travail. Si le volume ne représente qu’une partie d’un problème plus général sur le disque, les anciennes images et le cache de build obsolète en sont généralement l’autre cause.

Pourquoi les fichiers copiés sur l’hôte n’apparaissent-ils pas dans Nextcloud ?

Parce que Nextcloud lit son cache de fichiers dans la base de données, et non dans le répertoire. Votre copie a créé un fichier sur le disque sans ligne correspondante dans la base. L’interface web n’a donc rien à afficher. La documentation décrit précisément ce cas : après avoir copié des fichiers directement dans le répertoire de données, il faut lancer un scan.

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

L’argument --path montre également l’organisation du répertoire de données : chaque utilisateur dispose d’un dossier portant son nom d’utilisateur, et files contient ce que l’utilisateur voit dans l’interface web. Lancez le scan sur un seul chemin lorsque vous savez où les fichiers ont été copiés. --all parcourt tous les utilisateurs et peut prendre beaucoup de temps sur une grande instance. --unscanned ne traite que les fichiers qui ne sont pas encore entièrement scannés. -v affiche chaque fichier pendant son traitement. Cela permet de distinguer une commande qui semble bloquée d’une commande dont vous pouvez suivre l’exécution.

Les permissions déterminent si le scan suffit. Un fichier sur lequel l’utilisateur du conteneur ne peut pas écrire est indexé, puis ne peut pas être déplacé. La liste semble alors correcte, mais le renommage ou la suppression depuis l’interface web échoue.

Pourquoi les écritures échouent-elles après la définition de PUID et PGID ?

Parce que le noyau compare des nombres, pas des noms. PUID et PGID définissent respectivement l’identifiant numérique de l’utilisateur (uid) et du groupe (gid) utilisés par le processus du conteneur. Chaque fichier sur l’hôte possède également un propriétaire numérique. Lorsque ces deux nombres diffèrent, l’écriture est refusée, quels que soient les noms affichés de part et d’autre.

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

id abc affiche les uid et gid réellement utilisés par le conteneur, c’est-à-dire les valeurs que vous avez définies avec PUID et PGID. ls -ln affiche les propriétaires numériques, et -n est important : ls -l classique traduit ces nombres à partir de la liste des utilisateurs de l’hôte et affiche un nom qui n’a aucune signification dans le conteneur. Comparez les deux nombres.

Testez ensuite l’écriture au lieu de vous fier aux suppositions.

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

Un Permission denied qui nomme correctement /data confirme le problème. Corrigez le propriétaire depuis l’intérieur du conteneur, puis exécutez à nouveau le même test.

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

Cette opération doit être effectuée depuis l’intérieur du conteneur pour une raison précise. Avec Docker rootless, les identifiants utilisateur du conteneur sont mappés à travers la plage subordinate indiquée dans /etc/subuid. Ainsi, l’uid 1000 dans le conteneur correspond à un uid beaucoup plus élevé sur l’hôte. Un chown 1000:1000 exécuté sur l’hôte définit alors un propriétaire que le conteneur ne peut pas utiliser, et l’écriture échoue toujours. L’exécution de chown dans le conteneur utilise le même mapping que le processus Nextcloud lui-même. Les nombres correspondent donc nécessairement. C’est également pourquoi PUID et PGID doivent correspondre au propriétaire sur le disque avant de chercher une autre cause.

Comment effectuer une sauvegarde pour que la restauration fonctionne réellement ?

Sauvegardez la base de données et les dossiers au même moment. Le mode maintenance bloque les connexions, afin qu’aucun fichier ne soit téléversé entre l’export et la copie.

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

Remarquez ce qui manque dans la commande d’export : l’option -t. Un TTY réécrit les fins de ligne. Un dump SQL qui est passé par un TTY est corrompu, mais vous ne le découvrirez qu’au moment de la restauration. Remarquez également qu’un mot de passe placé sur la ligne de commande apparaît dans la sortie de ps pendant l’exécution. Lisez-le donc depuis votre fichier .env dans le shell au lieu de le saisir. Les anciennes images de base de données utilisent mysqldump à la place de mariadb-dump. Le manuel documente les deux.

Pour restaurer, chargez le dump dans une base de données vide, décompressez les deux archives dans de nouveaux volumes, démarrez les conteneurs, puis désactivez le mode maintenance. Si les dossiers et le dump proviennent de moments différents, le cache de fichiers et le contenu du disque ne correspondent pas. occ files:scan --all ne répare que dans un seul sens. Il trouve les fichiers qui existent sans ligne correspondante. Il ne peut pas restaurer un fichier référencé par une ligne.

Conservez le résultat hors du serveur. Une copie stockée dans le même VPS est perdue avec le VPS. C’est pourquoi restic vers un dépôt hors serveur fait partie de cette procédure, et pourquoi un snapshot du fournisseur est un outil différent d’une sauvegarde. Si vous êtes encore en train de mettre en place la stack, une installation complète de Nextcloud sur un VPS couvre le reverse proxy et le certificat TLS (transport layer security) que ce guide ne traite pas.

FAQ

Où se trouve le répertoire de données Nextcloud dans un conteneur Docker ?

Avec l’image linuxserver.io, il se trouve dans /data à l’intérieur du conteneur, et l’installation avec config.php se trouve sous /config. Il s’agit de chemins dans le conteneur. Pour connaître le chemin sur l’hôte, exécutez docker inspect nextcloud et lisez la valeur Source dans la section Mounts, ou exécutez docker volume inspect sur le volume et lisez Mountpoint. Les autres images Nextcloud utilisent des chemins différents dans le conteneur. Consultez donc la documentation du tag que vous avez épinglé et vérifiez avec docker exec -it nextcloud occ config:system:get datadirectory.

Pourquoi les fichiers que je copie dans le volume n’apparaissent-ils pas dans Nextcloud ?

Nextcloud liste les entrées du cache des fichiers dans sa base de données au lieu de lire le répertoire. Un fichier ajouté sans passer par Nextcloud n’a donc aucune entrée et reste invisible. Exécutez docker exec -it nextcloud occ files:scan --path="/alice/files/Photos" pour un répertoire, ou occ files:scan --all pour tous les utilisateurs. Si les fichiers apparaissent, mais qu’il est ensuite impossible de les déplacer ou de les supprimer, le problème vient des propriétaires : l’utilisateur du conteneur doit pouvoir y écrire.

Une copie du volume de données suffit-elle pour restaurer Nextcloud ?

Non. Le volume de données contient le contenu des fichiers. La base de données contient l’index des fichiers, ainsi que les utilisateurs et les partages. config.php contient les identifiants de la base de données et l’identifiant de l’instance. Pour restaurer correctement l’instance, vous avez besoin du répertoire de données, du répertoire de configuration, de la base de données et des répertoires des applications et du thème personnalisés si vous les utilisez. Sauvegardez-les tous au même moment, car une base de données plus récente que les fichiers peut référencer des fichiers qui n’existent pas.

Pourquoi mon volume de données est-il beaucoup plus volumineux que les fichiers visibles par les utilisateurs ?

Les prévisualisations, les fichiers supprimés et les anciennes versions se trouvent dans le même volume. Aucun de ces éléments n’apparaît dans le chiffre affiché à un utilisateur. Mesurez l’espace utilisé avec docker exec -it nextcloud sh -c 'du -sh /data/*'. La corbeille conserve les fichiers supprimés pendant 30 jours par défaut et ne les supprime plus tôt que lorsque l’espace vient à manquer. L’application Versions peut utiliser jusqu’à la moitié de l’espace libre dont dispose actuellement un utilisateur. Supprimez ces données avec occ trashbin:cleanup --all-users, occ versions:cleanup alice et occ preview:cleanup, et prévoyez que les prévisualisations grossissent à nouveau lorsque les utilisateurs ouvrent leurs fichiers.

Puis-je déplacer le répertoire de données Nextcloud vers un autre disque ?

Montez le nouvel emplacement sur le même chemin dans le conteneur au lieu de modifier le chemin connu de Nextcloud. Arrêtez le conteneur, copiez l’ancien contenu vers le nouveau disque en conservant les propriétaires (cp -a ou rsync -aAX), modifiez le volume ou le bind mount pour pointer vers le nouvel emplacement dans votre fichier compose, puis redémarrez le conteneur. Nextcloud voit toujours /data, et aucune entrée de la base de données ne doit donc être modifiée. Vérifiez avec docker exec -it nextcloud occ config:system:get datadirectory et effectuez un upload de test.