To change a Compose bind mount safely on macOS, first identify the existing host folder and the container path it serves. Copy the files to the new Mac folder before editing Compose, then verify the resolved mount and recreate the affected service. A bind mount points to a host path; changing that path does not move or delete the original files. Docker’s bind mount documentation also explains that a mount can hide files already present at its container destination.

Know which files the mount controls

A Compose bind mount connects a path on your Mac to a path inside a container. For example, ./data:/var/lib/example makes the data directory beside the Compose file available inside the container at /var/lib/example. Writes made by the container to that mount can change Mac files, because bind mounts are read-write by default. The Mac folder is the data you need to preserve; the container destination is where the application expects to see it.

This is different from a named volume such as db-data:/var/lib/example. A named volume is stored and managed by Docker, while a bind mount uses a host directory. Changing one to the other is a storage migration, not just a path edit. Do not assume that recreating a container copies files between them. Docker’s storage documentation describes this distinction.

Copy the existing files to the new Mac folder

Before changing the Compose file, stop the service if it may write to the data. From Terminal, run docker compose stop app, replacing app with the Compose service name. This reduces the chance that the old and new folders diverge while you copy. Check the Compose file and any overrides to confirm the exact current source and target; avoid guessing from a container’s visible directory alone.

For example, if the current source is ~/Projects/Old App/data and the new source should be ~/Projects/New App/data, create the destination and copy the contents with macOS’s standard rsync command:

mkdir -p "$HOME/Projects/New App/data"
rsync -a "$HOME/Projects/Old App/data/" "$HOME/Projects/New App/data/"

The trailing slashes mean “copy the contents of this directory.” The quotes protect the spaces in these example paths from the default macOS shell, zsh. This command merges files into the destination and does not delete destination-only files. Inspect the destination before proceeding. If the data is important, keep an independent backup as well; a copy is not a substitute for one.

Update the bind mount and guard against a typo

Prefer Compose long syntax for a directory mount when you want a missing source path to stop startup instead of silently becoming an empty folder:

services:
  app:
    volumes:
      - type: bind
        source: ./data
        target: /var/lib/example
        bind:
          create_host_path: false

Here, ./data is resolved relative to the Compose file’s parent directory for a local Compose runtime. Change it to the intended relative or absolute Mac path, but keep target the same if the application should continue using /var/lib/example. Compose’s short syntax creates a host directory when its source is missing; long syntax with create_host_path: false avoids that fallback. See the Compose service reference.

If you choose an absolute path with spaces, quote the YAML string, for example source: "/Users/sam/Projects/New App/data". Replace sam with your Mac account’s actual home-directory name. Keep the source path in YAML as a literal path; shell quoting rules apply to Terminal commands, not to YAML values.

Check the resolved path, then recreate the service

From the directory containing the Compose file, inspect the configuration Compose will use:

docker compose config

Check that the app service’s bind source resolves to the new folder and that its target is still /var/lib/example. If you use multiple Compose files, remember that paths are based on the first file specified; the Compose CLI reference documents this behavior. If the resolved source is unexpected, stop and correct the file before starting containers.

Recreate the service so the running container receives the changed mount:

docker compose up -d --force-recreate app
docker compose ps app

Compose documents that up recreates containers when configuration changes, and --force-recreate makes that explicit. Confirm the service is running, then check the application’s expected files or data before removing or renaming the old folder. The old directory remains on your Mac unless you delete it yourself. Keep it until you have confirmed the new source is correct and the application behaves as expected.

If the mount fails on Docker Desktop for Mac

Docker Desktop runs containers in a Linux VM and mediates access to Mac files. Its default shared directories include /Users, /Volumes, /private, /tmp, and /var/folders; a source outside the available shared locations may need to be added in Docker Desktop’s Settings > Resources > File sharing. Docker’s Desktop settings documentation describes this control and notes that file permissions still matter.

A failed mount should prompt a path and sharing check, not deletion of the old copy. If the new directory is empty, verify the resolved source, whether the copy placed files at the intended directory level, and whether Docker Desktop can access that Mac location. Do not use docker compose down -v as a bind-mount repair step: it is unnecessary for changing a bind source and can remove named volumes used by the project.

The safe finish is simple: verify the new Mac folder contains the required files, confirm Compose resolves to that folder and expected container target, then test the recreated service before retiring the original copy.

Sources