Se arquivos que deveriam vir da sua imagem desaparecerem após docker compose up no macOS, verifique se um bind mount cobre o diretório do contêiner. Um bind mount torna o conteúdo da pasta do host visível no destino da montagem, ocultando arquivos já presentes na imagem. Encontre o mapeamento específico, corrija o caminho do host ou do contêiner — ou remova-o se for desnecessário — e recrie o serviço afetado. O Docker documenta que recriar o contêiner sem a montagem é a forma de revelar os arquivos originais da imagem novamente. (Bind mounts)

Por que um bind mount oculta arquivos

Um bind mount conecta um caminho no host a um caminho no contêiner. Por exemplo, montar ./app:/usr/src/app faz com que a pasta app do host apareça em /usr/src/app. Se a imagem já contiver arquivos ali, eles continuam fazendo parte da imagem, mas ficam ocultos enquanto a montagem estiver ativa. Isso pode fazer com que uma imagem funcional pareça vazia ou causar erros de inicialização quando o programa esperado for encoberto. O mesmo comportamento se aplica no Mac; o Docker Desktop intermedeia o acesso aos arquivos do host por meio de sua máquina virtual Linux. (Bind mounts)

Isso é diferente de um problema de permissão de arquivo: o contêiner pode estar lendo o diretório montado corretamente, mas está lendo um conjunto de arquivos diferente daquele contido no diretório da imagem. Verifique o mapeamento antes de alterar propriedades ou reconstruir a imagem.

Encontre o mapeamento no seu arquivo Compose

Abra o arquivo Compose usado para iniciar o projeto e localize as entradas volumes: do serviço afetado. Uma entrada em formato curto, como ./app:/usr/src/app, é um bind mount quando sua origem for um caminho do host. No Compose local, um caminho de origem relativo é resolvido a partir do diretório pai do arquivo Compose. Isso significa que ./app pode se referir a uma pasta diferente do esperado caso o arquivo Compose esteja em um subdiretório. (Compose services reference)

Para ver a configuração resolvida e o estado do serviço, execute estes comandos a partir do diretório do projeto no Terminal do macOS:

docker compose config
docker compose ps

Na configuração gerada, compare a source de cada montagem (o caminho no Mac) com o seu target (o caminho no contêiner). Em seguida, compare o destino com o diretório de trabalho da imagem e o diretório onde os arquivos da sua aplicação são esperados. Uma montagem ampla, como .:/usr/src/app, pode cobrir todo o diretório da aplicação; um mapeamento mais restrito, como ./config:/usr/src/app/config, deixa o restante do diretório da imagem visível.

Escolha a correção correta

Se o serviço precisar de acesso em tempo real ao código-fonte, mantenha o bind mount, mas aponte-o para a pasta correta no host e o subdiretório pretendido no contêiner. Confirme que o diretório do host contém os arquivos esperados. A sintaxe curta do Compose cria um diretório caso a origem do bind não exista, de modo que um erro de digitação pode silenciosamente fornecer ao contêiner uma pasta vazia. Para um controle explícito, use a sintaxe longa com create_host_path: false; o Compose reportará uma origem ausente em vez de criar um diretório. (Compose services reference)

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

Se a imagem deve fornecer os arquivos da aplicação, remova a montagem direcionada a esse diretório. Se apenas configurações ou uma pasta gerada precisarem de acesso ao host, monte apenas esse subdiretório. Para dados persistentes do contêiner, como um banco de dados, considere usar um named volume: o Docker gerencia o armazenamento e isso evita vincular esses dados a um diretório específico do Mac. (Volumes)

Recrie o serviço e verifique

Após editar o arquivo Compose, recrie o serviço afetado para que ele utilize as montagens atualizadas. Substitua app abaixo pelo nome do serviço do seu arquivo:

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

O comando ls verifica o que o contêiner consegue ver no destino; altere o caminho se o seu serviço usar um diferente. Se a imagem não tiver shell ou não possuir ls, inspecione os logs de inicialização com docker compose logs app e use um comando de diagnóstico disponível nessa imagem. O Docker também documenta docker inspect para verificar a origem e o destino da montagem de um contêiner; com o Compose, primeiro obtenha o nome do contêiner com docker compose ps e, em seguida, execute docker inspect CONTAINER_NAME. (Bind mounts)

Se a origem estiver fora das pastas compartilhadas do Docker Desktop, ou se você vir Mounts denied ou file is not shared from the host, verifique Settings > Resources > File sharing no Docker Desktop e adicione o diretório específico do Mac. O Docker lista /Users, /Volumes, /private, /tmp e /var/folders como compartilhados por padrão, mas diretórios fora desses locais podem precisar ser adicionados. O Docker VMM não oferece suporte a compartilhamentos automáticos de bind mount, portanto, adicionar o diretório manualmente é obrigatório para esse backend. (Docker Desktop settings, Virtual Machine Manager)

Uma montagem que oculta arquivos de imagem geralmente é corrigida ajustando sua origem ou destino, reduzindo seu escopo ou removendo-a e recriando o serviço. Mantenha um bind mount quando o contêiner precisar de uma pasta específica do host; caso contrário, deixe que a imagem forneça seus próprios arquivos ou armazene dados persistentes em um volume gerenciado pelo Docker.

Fontes