If files that should come from your image disappear after docker compose up on macOS, check whether a bind mount covers their container directory. A bind mount makes the host folder’s contents visible at the mount target, obscuring files already in the image. Find the specific mapping, correct its host or container path—or remove it if it is unnecessary—and recreate the affected service. Docker documents that recreating the container without the mount is the way to reveal the image’s original files again. (Bind mounts)

Why a bind mount hides files

A bind mount connects a path on the host to a path in the container. For example, mounting ./app:/usr/src/app makes the host’s app folder appear at /usr/src/app. If the image already contains files there, they are still part of the image but hidden while the mount is active. This can make a working image look empty or cause startup errors when its expected program is covered. The same behavior applies on Mac; Docker Desktop mediates host file access through its Linux virtual machine. (Bind mounts)

This is different from a file permission problem: the container can be reading the mounted directory correctly, but it is reading a different set of files than the image’s directory. Check the mapping before changing ownership or rebuilding the image.

Find the mapping in your Compose file

Open the Compose file used to start the project and locate the affected service’s volumes: entries. A short-form entry such as ./app:/usr/src/app is a bind mount when its source is a host path. In local Compose, a relative source path is resolved from the Compose file’s parent directory. That means ./app may refer to a different folder than you expect if the Compose file is in a subdirectory. (Compose services reference)

To see the resolved configuration and service state, run these commands from the project directory in the macOS Terminal:

docker compose config
docker compose ps

In the rendered configuration, compare each mount’s source (the Mac path) with its target (the container path). Then compare the target with the image’s working directory and the directory where its application files are expected. A broad mount such as .:/usr/src/app can cover the entire application directory; a narrower mapping such as ./config:/usr/src/app/config leaves the rest of the image directory visible.

Choose the right fix

If the service needs live access to source code, keep a bind mount but point it at the correct host folder and the intended container subdirectory. Confirm that the host directory contains the files you expect. Compose short syntax creates a directory at a missing bind source, so a typo can silently give the container an empty folder. For explicit control, use long syntax with create_host_path: false; Compose will then report a missing source instead of creating a directory. (Compose services reference)

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

If the image should supply the application files, remove the mount that targets that directory. If only configuration or one generated folder needs host access, mount just that subdirectory. For persistent container data such as a database, consider a named volume instead: Docker manages its storage, and it avoids tying that data to a particular Mac directory. (Volumes)

Recreate the service and verify

After editing the Compose file, recreate the affected service so it uses the updated mounts. Replace app below with the service name from your file:

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

The ls command checks what the container can see at the target; change the path if your service uses a different one. If the image has no shell or lacks ls, inspect its startup logs with docker compose logs app and use a diagnostic command available in that image. Docker also documents docker inspect for checking a container’s mount source and destination; with Compose, first get its container name from docker compose ps, then run docker inspect CONTAINER_NAME. (Bind mounts)

If the source is outside Docker Desktop’s shared folders, or you see Mounts denied or file is not shared from the host, check Docker Desktop’s Settings > Resources > File sharing and add the specific Mac directory. Docker lists /Users, /Volumes, /private, /tmp, and /var/folders as shared by default, but directories outside those locations may need to be added. Docker VMM does not support bind mount auto-shares, so adding the directory manually is required for that backend. (Docker Desktop settings, Virtual Machine Manager)

A mount hiding image files is usually fixed by correcting its source or target, narrowing its scope, or removing it and recreating the service. Keep a bind mount when the container needs a specific host folder; otherwise, let the image provide its own files or store persistent data in a Docker-managed volume.

Sources