Si des fichiers qui devraient provenir de votre image disparaissent après un docker compose up sur macOS, vérifiez si un montage lié recouvre leur répertoire dans le conteneur. Un montage lié rend le contenu du dossier hôte visible au niveau de la cible de montage, masquant les fichiers déjà présents dans l’image. Identifiez le mappage concerné, corrigez son chemin sur l’hôte ou dans le conteneur — ou supprimez-le s’il est inutile — et recréez le service affecté. La documentation de Docker indique que recréer le conteneur sans le montage est la méthode pour faire réapparaître les fichiers d’origine de l’image. (Bind mounts)

Pourquoi un montage lié masque des fichiers

Un montage lié connecte un chemin sur l’hôte à un chemin dans le conteneur. Par exemple, monter ./app:/usr/src/app fait apparaître le dossier app de l’hôte dans /usr/src/app. Si l’image contient déjà des fichiers à cet endroit, ils font toujours partie de l’image mais restent masqués tant que le montage est actif. Cela peut donner l’impression qu’une image pourtant fonctionnelle est vide ou provoquer des erreurs au démarrage lorsque le programme attendu est recouvert. Le même comportement s’applique sur Mac ; Docker Desktop gère l’accès aux fichiers de l’hôte par l’intermédiaire de sa machine virtuelle Linux. (Bind mounts)

Cela diffère d’un problème d’autorisations de fichiers : le conteneur peut tout à fait lire correctement le répertoire monté, mais il lit un ensemble de fichiers différent de celui du répertoire de l’image. Vérifiez le mappage avant de modifier les permissions ou de reconstruire l’image.

Trouver le mappage dans votre fichier Compose

Ouvrez le fichier Compose utilisé pour lancer le projet et repérez les entrées volumes: du service concerné. Une entrée au format court telle que ./app:/usr/src/app est un montage lié lorsque sa source est un chemin hôte. Dans Compose en local, un chemin source relatif est résolu à partir du répertoire parent du fichier Compose. Cela signifie que ./app peut faire référence à un dossier différent de celui attendu si le fichier Compose se trouve dans un sous-répertoire. (Compose services reference)

Pour visualiser la configuration résolue et l’état du service, exécutez ces commandes depuis le répertoire du projet dans le Terminal macOS :

docker compose config
docker compose ps

Dans la configuration générée, comparez la source de chaque montage (le chemin sur Mac) avec sa target (le chemin dans le conteneur). Comparez ensuite la cible avec le répertoire de travail de l’image et le répertoire dans lequel ses fichiers d’application sont attendus. Un montage large comme .:/usr/src/app peut recouvrir l’intégralité du répertoire de l’application ; un mappage plus restreint tel que ./config:/usr/src/app/config laisse le reste du répertoire de l’image visible.

Choisir la bonne solution

Si le service a besoin d’un accès en direct au code source, conservez un montage lié mais faites-le pointer vers le bon dossier hôte et le sous-répertoire prévu dans le conteneur. Vérifiez que le répertoire hôte contient bien les fichiers attendus. La syntaxe courte de Compose crée automatiquement un répertoire si la source du montage est manquante, de sorte qu’une faute de frappe peut discrètement fournir un dossier vide au conteneur. Pour un contrôle explicite, utilisez la syntaxe longue avec create_host_path: false ; Compose signalera alors une source manquante au lieu de créer un répertoire. (Compose services reference)

services:
  app:
    volumes:
      - type: bind
        source: ./app
        target: /usr/src/app
        bind:
          create_host_path: false

Si l’image doit fournir les fichiers de l’application, supprimez le montage qui cible ce répertoire. Si seule la configuration ou un dossier généré a besoin d’un accès depuis l’hôte, montez uniquement ce sous-répertoire. Pour les données persistantes du conteneur, comme une base de données, privilégiez un volume nommé : Docker gère son stockage, ce qui évite de lier ces données à un dossier Mac particulier. (Volumes)

Recréer le service et vérifier

Après avoir modifié le fichier Compose, recréez le service concerné afin qu’il utilise les montages mis à jour. Remplacez app ci-dessous par le nom du service dans votre fichier :

docker compose up -d --force-recreate app
docker compose exec app sh -c 'ls -la /usr/src/app'

La commande ls permet de vérifier ce que le conteneur peut voir au niveau de la cible ; modifiez le chemin si votre service en utilise un autre. Si l’image ne dispose pas de shell ou de la commande ls, inspectez ses journaux de démarrage avec docker compose logs app et utilisez une commande de diagnostic disponible dans cette image. Docker documente également l’utilisation de docker inspect pour vérifier la source et la destination de montage d’un conteneur ; avec Compose, récupérez d’abord le nom de son conteneur via docker compose ps, puis exécutez docker inspect CONTAINER_NAME. (Bind mounts)

Si la source se situe en dehors des dossiers partagés de Docker Desktop, ou si vous observez les erreurs Mounts denied ou file is not shared from the host, rendez-vous dans Paramètres > Ressources > Partage de fichiers (Settings > Resources > File sharing) de Docker Desktop et ajoutez le répertoire Mac spécifique. Docker liste /Users, /Volumes, /private, /tmp et /var/folders comme partagés par défaut, mais les répertoires situés en dehors de ces emplacements peuvent nécessiter d’être ajoutés. Docker VMM ne prenant pas en charge le partage automatique des montages liés, l’ajout manuel du répertoire est nécessaire avec ce backend. (Docker Desktop settings, Virtual Machine Manager)

Un montage qui masque les fichiers de l’image se corrige généralement en rectifiant sa source ou sa cible, en restreignant sa portée, ou en le supprimant puis en recréant le service. Conservez un montage lié lorsque le conteneur a besoin d’un dossier hôte spécifique ; sinon, laissez l’image fournir ses propres fichiers ou stockez les données persistantes dans un volume géré par Docker.

Sources