Si los archivos que deberían provenir de su imagen desaparecen después de docker compose up en macOS, compruebe si un bind mount cubre el directorio de su contenedor. Un bind mount hace que el contenido de la carpeta del host sea visible en el destino del montaje, ocultando los archivos que ya se encuentran en la imagen. Encuentre la asignación específica, corrija la ruta de su host o contenedor (o elimínela si no es necesaria) y vuelva a crear el servicio afectado. Docker documenta que volver a crear el contenedor sin el montaje es la manera de hacer visibles los archivos originales de la imagen de nuevo. (Bind mounts)

Por qué un bind mount oculta archivos

Un bind mount conecta una ruta del host con una ruta dentro del contenedor. Por ejemplo, montar ./app:/usr/src/app hace que la carpeta app del host aparezca en /usr/src/app. Si la imagen ya contenía archivos allí, estos siguen formando parte de la imagen pero quedan ocultos mientras el montaje esté activo. Esto puede hacer que una imagen funcional parezca vacía o provocar errores de inicio cuando el programa esperado queda cubierto. El mismo comportamiento ocurre en Mac; Docker Desktop gestiona el acceso a los archivos del host mediante su máquina virtual Linux. (Bind mounts)

Esto no es un problema de permisos de archivos: el contenedor puede estar leyendo el directorio montado de forma correcta, pero está leyendo un conjunto de archivos diferente al del directorio de la imagen. Compruebe la asignación antes de cambiar los permisos de propiedad o reconstruir la imagen.

Localice la asignación en su archivo Compose

Abra el archivo Compose utilizado para iniciar el proyecto y localice las entradas volumes: del servicio afectado. Una entrada en formato corto como ./app:/usr/src/app es un bind mount cuando su origen es una ruta del host. En Compose local, una ruta de origen relativa se resuelve a partir del directorio primario del archivo Compose. Eso significa que ./app puede apuntar a una carpeta distinta a la esperada si el archivo Compose se encuentra en un subdirectorio. (Compose services reference)

Para ver la configuración resuelta y el estado del servicio, ejecute estos comandos desde el directorio del proyecto en la Terminal de macOS:

docker compose config
docker compose ps

En la configuración resultante, compare el source de cada montaje (la ruta en Mac) con su target (la ruta en el contenedor). Luego, compare el destino con el directorio de trabajo de la imagen y el directorio donde se esperan los archivos de su aplicación. Un montaje amplio como .:/usr/src/app puede cubrir todo el directorio de la aplicación; una asignación más específica como ./config:/usr/src/app/config deja visible el resto del directorio de la imagen.

Elija la solución adecuada

Si el servicio necesita acceso en tiempo real al código fuente, mantenga el bind mount pero apúntelo a la carpeta del host correcta y al subdirectorio del contenedor deseado. Confirme que el directorio del host contenga los archivos que espera. La sintaxis corta de Compose crea un directorio si el origen del bind mount no existe, por lo que un error tipográfico puede proporcionar silenciosamente una carpeta vacía al contenedor. Para un control explícito, utilice la sintaxis larga con create_host_path: false; de este modo, Compose notificará que falta el origen en lugar de crear un directorio. (Compose services reference)

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

Si la imagen es la que debe proporcionar los archivos de la aplicación, elimine el montaje que apunta a ese directorio. Si solo la configuración o una sola carpeta generada necesitan acceso al host, monte únicamente ese subdirectorio. Para datos persistentes del contenedor, como una base de datos, considere usar un volumen con nombre (named volume) en su lugar: Docker administra su almacenamiento y evita vincular esos datos a un directorio específico de Mac. (Volumes)

Vuelva a crear el servicio y verifique

Después de editar el archivo Compose, vuelva a crear el servicio afectado para que utilice los montajes actualizados. Reemplace app a continuación con el nombre del servicio de su archivo:

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

El comando ls comprueba lo que el contenedor puede ver en el destino; cambie la ruta si su servicio utiliza una diferente. Si la imagen no tiene una shell o carece de ls, inspeccione sus registros de inicio con docker compose logs app y use un comando de diagnóstico disponible en esa imagen. Docker también documenta docker inspect para comprobar el origen y destino del montaje de un contenedor; con Compose, primero obtenga el nombre del contenedor con docker compose ps, luego ejecute docker inspect CONTAINER_NAME. (Bind mounts)

Si el origen está fuera de las carpetas compartidas de Docker Desktop, o ve Mounts denied o file is not shared from the host, revise Settings > Resources > File sharing en Docker Desktop y agregue el directorio de Mac correspondiente. Docker enumera /Users, /Volumes, /private, /tmp y /var/folders como compartidos de forma predeterminada, pero es posible que deba agregar los directorios ubicados fuera de esas rutas. Docker VMM no admite el uso compartido automático de bind mounts, por lo que para ese backend es obligatorio añadir el directorio manualmente. (Docker Desktop settings, Virtual Machine Manager)

Un montaje que oculta archivos de la imagen suele solucionarse corrigiendo su origen o destino, reduciendo su alcance o eliminándolo y volviendo a crear el servicio. Mantenga un bind mount cuando el contenedor necesite una carpeta específica del host; de lo contrario, deje que la imagen proporcione sus propios archivos o guarde los datos persistentes en un volumen administrado por Docker.

Fuentes