Où Docker stocke ses images, et comment les déplacer

La réponse courte

Où Docker stocke-t-il les images ? Sur une installation neuve de Docker Engine 29.0 ou plus récent, les images et les couches des conteneurs vont dans /var/lib/containerd. Les volumes nommés et le reste de l'état de Docker restent dans /var/lib/docker. Sur une machine mise à jour depuis une version plus ancienne, tout reste dans /var/lib/docker, avec le pilote de stockage overlay2, tant que personne n'active le containerd image store.

Docker Desktop fonctionne autrement. Sur Mac et sur Windows, les conteneurs Linux tournent dans une machine virtuelle, et tout ce que Docker stocke pour eux tient dans un seul gros fichier disque. Les conteneurs Windows natifs, eux, gardent leurs couches sur le disque de Windows. Ce guide montre comment savoir quelle disposition votre machine utilise et où vivent les volumes, les journaux et le cache de build. Il montre ensuite comment tout déplacer sur un second disque quand le disque système est trop petit.

Pourquoi la réponse a changé avec Docker Engine 29

Docker Engine 29.0 est sorti en novembre 2025. Ses notes de version annoncent que le containerd image store devient le stockage par défaut des nouvelles installations. containerd est le moteur de bas niveau qui exécute les conteneurs sous Docker. Dans ce mode, c'est containerd qui garde les images et les snapshots (les systèmes de fichiers des conteneurs) dans son propre dossier.

Une machine mise à jour ne bascule pas toute seule. La documentation Docker indique que le démon garde les anciens pilotes de stockage, overlay2 en pratique, tant que vous n'activez pas le containerd image store. Il existe aussi une exception : selon les notes de version de la 29, un démon configuré avec userns-remap ne peut pas utiliser ce stockage pour l'instant.

Le résultat est simple à retenir. Deux VPS sous la même version de Docker peuvent ranger leurs images à deux endroits différents, selon la façon dont Docker a été installé. Ne devinez pas. Vérifiez.

Comment savoir quelle disposition votre machine utilise

La documentation Docker donne une commande pour lire le type de stockage :

docker info -f '{{ .DriverStatus }}'

Avec le containerd image store, la documentation montre cette sortie :

[[driver-type io.containerd.snapshotter.v1]]

Si vous voyez autre chose, en général une liste qui parle de overlay2 et du système de fichiers sous-jacent, votre machine utilise l'ancien stockage. Dans ce cas, tout est dans /var/lib/docker.

Deux lignes de docker info complètent le tableau :

docker info | grep -E 'Storage Driver|Docker Root Dir'

Docker Root Dir donne le dossier de données de Docker, /var/lib/docker par défaut. Storage Driver donne le pilote. L'exemple Linux de la page de référence de docker info affiche Storage Driver: overlayfs, qui correspond au containerd image store.

Mesurez ensuite ce que chaque dossier occupe vraiment :

sudo du -sh /var/lib/docker /var/lib/containerd
df -h /

Si du et df ne donnent pas le même total, la cause est souvent un fichier supprimé mais encore ouvert, ou un point de montage qui cache des fichiers. Le guide pourquoi df et du ne donnent pas la même taille de disque explique comment trouver la différence.

Pourquoi /var/lib/containerd grossit plus vite que prévu

La documentation Docker est claire sur ce point : le containerd image store utilise plus d'espace disque que les anciens pilotes pour les mêmes images. La raison est que containerd garde chaque image deux fois. Il garde une copie compressée (les couches telles qu'elles ont été téléchargées) et une copie décompressée (les fichiers prêts à être montés dans un conteneur).

Sur un VPS avec un petit disque système, cette différence se voit vite. Quelques images lourdes, une base de données et un modèle d'IA peuvent remplir la partition racine alors que le même travail tenait avant. Si vous faites tourner des modèles locaux, lisez aussi où Ollama range les modèles téléchargés, car ces fichiers s'ajoutent aux images.

Le second piège est plus difficile à voir. La documentation Docker le dit sur deux pages : l'option data-root de Docker ne déplace pas les données stockées dans /var/lib/containerd. Vous changez data-root, vous redémarrez, les volumes partent bien sur le nouveau disque, et la partition racine continue de se remplir. C'est normal, parce que les images ne dépendent plus de data-root. Il faut configurer containerd séparément.

Où vont les volumes, les journaux et le cache de build

Les images ne sont qu'une partie de l'espace utilisé. Voici les autres.

Les volumes nommés vivent sous le dossier de données de Docker. La documentation donne l'exemple d'un volume my-vol monté depuis /var/lib/docker/volumes/my-vol/_data. Un bind mount, au contraire, vit exactement là où vous l'avez pointé sur l'hôte, et Docker ne le déplace jamais. La différence est détaillée dans volumes nommés et bind mounts dans Docker Compose.

Les journaux des conteneurs sont écrits par le pilote json-file, le pilote par défaut. Par défaut, il ne fait aucune rotation : max-size vaut -1, c'est-à-dire illimité. Un conteneur qui écrit beaucoup peut donc remplir un disque à lui seul. Pour trouver le fichier de journal d'un conteneur, la référence de docker inspect donne cette commande :

docker inspect --format='{{.LogPath}}' nom_du_conteneur

Pour limiter la taille, mettez ceci dans /etc/docker/daemon.json, puis redémarrez Docker :

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Attention : la documentation précise que ce réglage ne s'applique qu'aux conteneurs créés après le redémarrage. Les conteneurs existants gardent l'ancienne configuration tant que vous ne les recréez pas.

Le cache de build vit dans le stockage du démon. Pour le constructeur intégré, son nettoyage automatique est réglé par defaultKeepStorage, qui vaut 20 Go sur Docker Desktop selon la documentation de Docker Build. Pour une vue d'ensemble, docker system df affiche l'espace pris par les images, les conteneurs et les volumes locaux.

Déplacer les données Docker sur un second disque

Le plan : arrêter les services, copier les données, déclarer les nouveaux chemins, puis redémarrer et vérifier. Les exemples supposent un second disque déjà formaté et monté de façon permanente (avec une ligne dans /etc/fstab). Ils utilisent deux dossiers sur ce disque : /mnt/docker-data pour Docker et /mnt/containerd-data pour containerd. Ce sont les chemins des exemples de la documentation Docker. Adaptez-les à votre point de montage.

La documentation Docker insiste sur un point : chaque démon doit avoir son propre dossier. Ne partagez pas un dossier entre deux machines, sur un partage NFS par exemple. Les erreurs qui en sortent sont difficiles à diagnostiquer.

Étape 1 : savoir si Docker utilise le containerd du système

Sur une installation par paquets, Docker peut se connecter au service containerd du système au lieu de lancer le sien. Regardez la ligne de démarrage du service :

systemctl cat docker | grep ExecStart
systemctl status containerd --no-pager
containerd --version

Si la ligne ExecStart contient --containerd=/run/containerd/containerd.sock et que le service containerd est actif, c'est ce service qui garde les images. C'est donc lui qu'il faut configurer. Notez aussi la version affichée par containerd --version. Vous en aurez besoin plus bas.

Étape 2 : arrêter les services

sudo systemctl stop docker docker.socket
sudo systemctl stop containerd
systemctl is-active docker containerd

Arrêtez aussi docker.socket. Sinon, le socket reste actif, et le premier appel à docker relance le démon pendant votre copie. La dernière commande doit répondre inactive deux fois.

Étape 3 : copier les données

sudo apt install -y rsync
sudo mkdir -p /mnt/docker-data /mnt/containerd-data
sudo rsync -aHAX /var/lib/docker/ /mnt/docker-data/
sudo rsync -aHAX /var/lib/containerd/ /mnt/containerd-data/

Le / final sur la source compte : il copie le contenu du dossier, pas le dossier lui-même. Les options gardent les liens physiques (-H), les ACL (-A) et les attributs étendus (-X). Une copie qui les perd peut produire des couches d'images incomplètes.

Étape 4 : déclarer le nouveau dossier de Docker

Le fichier de configuration du démon est /etc/docker/daemon.json (ou ~/.config/docker/daemon.json en mode rootless). S'il n'existe pas, créez-le avec ce contenu, qui reprend l'exemple de la documentation :

{
  "data-root": "/mnt/docker-data"
}

S'il existe déjà, par exemple avec la rotation des journaux vue plus haut, ajoutez la clé data-root dans le même objet JSON. Le fichier doit rester du JSON valide, sinon Docker refuse de démarrer. Vérifiez la syntaxe avant de redémarrer :

python3 -m json.tool /etc/docker/daemon.json

La commande réaffiche le fichier s'il est valide. Sinon, elle donne le numéro de ligne de l'erreur.

Étape 5 : déclarer le nouveau dossier de containerd

containerd lit /etc/containerd/config.toml. Son option root, au niveau le plus haut du fichier, fixe le dossier des données. Sa valeur par défaut est /var/lib/containerd. Ouvrez le fichier :

sudo nano /etc/containerd/config.toml

Ajoutez la ligne root en haut du fichier, avant toute ligne qui commence par [ :

root = "/mnt/containerd-data"

L'emplacement compte, à cause d'une règle du format TOML : une clé écrite après un en-tête comme [plugins.xxx] appartient à cette section. Une ligne root ajoutée à la fin du fichier n'est donc plus une option de premier niveau, et containerd continue d'écrire dans /var/lib/containerd.

Si le fichier n'existe pas, créez-le comme dans l'exemple de la documentation Docker :

version = 2
root = "/mnt/containerd-data"

La section suivante explique quoi faire de cette ligne version quand le fichier existe déjà.

Étape 6 : redémarrer et vérifier

sudo systemctl start containerd
sudo systemctl start docker
systemctl status containerd docker --no-pager

Démarrez containerd d'abord, car Docker se connecte à lui au démarrage. Puis vérifiez que les nouveaux chemins sont pris en compte :

docker info | grep 'Docker Root Dir'
sudo containerd config dump | grep '^root'
docker images

La première commande doit afficher /mnt/docker-data, la deuxième /mnt/containerd-data. docker images doit lister les mêmes images qu'avant. Lancez ensuite un docker pull et regardez df -h / /mnt/docker-data : c'est le second disque qui doit grossir, pas la partition racine.

Gardez les anciens dossiers quelques jours sous un autre nom au lieu de les effacer tout de suite. Faites-le avec les services arrêtés :

sudo systemctl stop docker docker.socket containerd
sudo mv /var/lib/docker /var/lib/docker.old
sudo mv /var/lib/containerd /var/lib/containerd.old
sudo systemctl start containerd docker

Quand tout fonctionne après un redémarrage complet du serveur, supprimez-les avec sudo rm -rf. Pensez aussi au nouveau disque : un second disque plein ou en train de lâcher casse Docker de la même façon. La surveillance de la santé des disques sur un VPS se met en place en quelques minutes.

Faut-il écrire version = 2 dans config.toml ?

La ligne version en tête de /etc/containerd/config.toml n'a pas une réponse unique. Elle dépend de la version de containerd installée. C'est la raison du containerd --version de l'étape 1.

Voici ce que disent les sources de containerd. La version 2 du format demande containerd 1.3 ou plus, la version 3 demande containerd 2.0, et la version 4 demande containerd 2.3. Un fichier qui annonce une version plus récente que le binaire est refusé au démarrage, avec une erreur qui contient expected containerd config version equal to or less than. Dans l'autre sens, containerd 2.x accepte toujours un fichier version = 2 et le migre au démarrage. Un fichier sans ligne version est lu comme un fichier de version 1, et le code de containerd 2.4.2 sait encore le migrer.

Les notes de version de Docker 29 montrent que les binaires statiques livrés avec Docker vont de containerd 2.1.5 (Docker 29.0.0) à containerd 2.4.2 (Docker 29.9.1). Les paquets apt ou dnf peuvent installer une autre version. Votre containerd --version est donc la seule réponse fiable.

Les règles pratiques :

1. Le fichier existe déjà avec une ligne version : gardez-la telle quelle et ajoutez seulement root. Le numéro de version change la façon dont containerd lit les sections de plugins du reste du fichier. L'option root n'est pas une option de plugin, donc elle ne dépend pas de ce numéro.
2. Le fichier existe déjà sans ligne version : n'en ajoutez pas, car vous changeriez la lecture des sections de plugins déjà présentes. Ajoutez seulement root en haut.
3. N'écrivez jamais version = 4 sur une machine en containerd 2.1 ou 2.2. Le service refusera de démarrer.
4. Après chaque modification, vérifiez que le service a bien démarré avec systemctl status containerd.

Si containerd refuse de démarrer après votre modification, ne retirez pas des lignes au hasard. Lisez la raison exacte :

sudo journalctl -u containerd -n 50 --no-pager

Le journal nomme l'option ou la ligne qui pose problème. Corrigez celle-là, et seulement celle-là.

Où Docker Desktop stocke les images sur Mac et Windows

Docker Desktop ne range rien dans /var/lib/docker sur votre ordinateur. Les images, les conteneurs et les volumes des conteneurs Linux vivent dans le disque virtuel de la machine virtuelle Linux de Desktop. Les chemins ci-dessous viennent du guide de sauvegarde de Docker Desktop.

Sur Mac, le fichier s'appelle Docker.raw :

~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

La FAQ Mac de Docker prévient que certains outils affichent la taille maximale de ce fichier, et non l'espace qu'il occupe vraiment sur le disque. Un chiffre énorme dans un explorateur de fichiers ne veut donc pas dire que le disque est plein.

Sur Docker Desktop pour Linux, le fichier est ~/.docker/desktop/vms/0/data/Docker.raw.

Sur Windows, le chemin dépend du moteur de virtualisation. Il est affiché dans Settings, onglet General, sous Choose Virtual Machine Manager (VMM) :

• WSL 2 : %LOCALAPPDATA%\Docker\wsl\disk\docker_data.vhdx
• Hyper-V : %ProgramData%\DockerDesktop\vm-data\DockerDesktop.vhdx
• Docker VMM (bêta) : %LOCALAPPDATA%\Docker\vm-data\DockerDesktop.vhdx

Ces noms ont changé au fil des versions. D'anciens articles et des messages de forum citent d'autres fichiers ou d'autres dossiers. Fiez-vous à la documentation actuelle et à l'écran de votre propre version.

Ces fichiers ne concernent que les conteneurs Linux. Sur Windows Pro ou Enterprise, avec une installation pour tous les utilisateurs, Docker Desktop peut aussi passer en conteneurs Windows natifs, avec Switch to Windows containers dans son menu. Ces conteneurs n'utilisent pas la machine virtuelle Linux. Pour le moteur Docker sous Windows, la documentation de Docker et celle de Microsoft placent par défaut leurs couches dans C:\ProgramData\docker, dans les sous-dossiers image et windowsfilter. La documentation de Desktop ne donne pas de chemin par défaut pour ses conteneurs Windows, mais son installeur accepte l'option --windows-containers-default-data-root=<path> pour choisir leur emplacement.

Desktop a aussi son propre réglage containerd : la case Use containerd for pulling and storing images, dans l'onglet General. La documentation de Desktop indique qu'elle est activée par défaut. La décocher revient à l'ancien stockage.

Déplacer le disque de Docker Desktop

Le réglage se trouve dans Settings, Resources, Advanced, sous Disk image location. La documentation le décrit comme l'emplacement du volume Linux où sont stockés les conteneurs et les images. Il ne déplace donc pas les données des conteneurs Windows natifs. Elle le liste pour Mac, Linux et Windows avec Hyper-V. Pour WSL 2, la page WSL de Docker indique que le dossier par défaut est C:\Users\[USERNAME]\AppData\Local\Docker\wsl et qu'il se change dans Settings, Resources, Advanced. Vérifiez ce que votre version propose avant de compter dessus.

Les notes de version récentes de Docker Desktop montrent que ce déplacement a eu des bugs sérieux. La 4.91.0 (14 septembre 2026) corrige un cas où changer l'emplacement vers un autre volume pouvait supprimer l'image disque existante. La 4.92.0 (21 septembre 2026) corrige les déplacements vers un autre lecteur sous Windows, qui échouaient toujours. La 4.95.0 (12 octobre 2026) empêche de choisir un emplacement dans le dossier d'installation de Desktop. Elle corrige aussi une mise à jour sous Windows qui pouvait effacer le disque de données WSL. Au 24 octobre 2026, la dernière version listée est la 4.96.3.

D'où la procédure prudente :

1. Mettez Docker Desktop à jour avant de toucher à quoi que ce soit.
2. Quittez Docker Desktop complètement. Le guide de sauvegarde exige que Desktop soit totalement arrêté avant de copier ces fichiers.
3. Copiez le fichier disque ailleurs, comme sauvegarde.
4. Choisissez le nouvel emplacement dans Settings, jamais dans le dossier d'installation de Docker Desktop.

Si le dossier cible contient déjà une image disque, Desktop demande s'il faut l'utiliser ou la remplacer. Lisez bien la question avant de cliquer. Dans le même écran, la limite d'utilisation du disque fixe l'espace maximum que le moteur peut prendre. Pour savoir si Desktop vous convient ou si Docker Engine seul suffit, voyez ce qui est gratuit entre Docker Engine et Docker Desktop.

Supprimer avant de déplacer

Déplacer les données règle le manque de place pour de bon. Supprimer ce qui ne sert plus le règle souvent tout de suite, sans arrêter les services. Les images orphelines, les conteneurs arrêtés et un cache de build oublié pèsent souvent plusieurs gigaoctets. Le guide nettoyer l'espace disque de Docker avec prune sur un VPS explique quelle commande supprime quoi, et ce qu'il ne faut jamais lancer sur un serveur de production.

FAQ

J'ai changé data-root mais la partition racine se remplit toujours. Pourquoi ?

Votre Docker utilise sans doute le containerd image store, le stockage par défaut des nouvelles installations depuis Docker Engine 29.0. Dans ce mode, les images et les snapshots des conteneurs sont dans /var/lib/containerd, et data-root ne déplace pas ce dossier. Vérifiez avec docker info -f '{{ .DriverStatus }}'. Si la sortie mentionne io.containerd.snapshotter.v1, ajoutez une ligne root en haut de /etc/containerd/config.toml, copiez les données, puis redémarrez containerd et Docker.

Comment savoir si Docker utilise containerd ou overlay2 ?

Lancez docker info -f '{{ .DriverStatus }}'. Pour le containerd image store, la documentation Docker montre driver-type io.containerd.snapshotter.v1 entre doubles crochets. Une sortie qui parle d'overlay2 signifie l'ancien stockage, avec tout dans /var/lib/docker. Une machine mise à jour depuis une version antérieure à la 29 garde overlay2 tant que personne n'active le containerd image store.

Faut-il mettre version = 2 dans /etc/containerd/config.toml ?

Pour un fichier neuf qui ne contient que root, version = 2 suit l'exemple de la documentation Docker, et containerd 2.x l'accepte en le migrant au démarrage. Pour un fichier existant, ne changez pas la ligne version, car elle décide comment containerd lit les sections de plugins du reste du fichier. N'écrivez jamais version = 4 si containerd --version affiche 2.1 ou 2.2 : le service refuse un fichier plus récent que lui. En cas d'échec, lisez sudo journalctl -u containerd -n 50.

Où est le fichier disque de Docker Desktop sous Windows ?

Avec le moteur WSL 2, la documentation actuelle de Docker donne %LOCALAPPDATA%\Docker\wsl\disk\docker_data.vhdx. Avec Hyper-V, c'est %ProgramData%\DockerDesktop\vm-data\DockerDesktop.vhdx. Le moteur utilisé est affiché dans Settings, onglet General. Si vous avez changé Disk image location dans Settings, Resources, Advanced, le fichier est à l'emplacement que vous avez choisi. Ce fichier ne contient que les données des conteneurs Linux. Les conteneurs Windows natifs gardent leurs couches hors de ce fichier, par défaut dans C:\ProgramData\docker pour le moteur Docker sous Windows.

Mes images ont disparu après avoir changé de stockage. Sont-elles perdues ?

Pas forcément. La documentation Docker explique qu'activer le containerd image store sur une machine qui utilisait overlay2 masque les images et les conteneurs existants. Ils réapparaissent si vous revenez à l'ancien stockage. Après un déplacement de dossier, vérifiez d'abord que docker info et sudo containerd config dump affichent bien les nouveaux chemins, puis que la copie rsync s'est terminée sans erreur.