Docker compose bind volumes are empty on MacOS Ventura (13.1), but work on 12.x

Hello, I wonder if anyone could help?

I’m running into an issue with MacOS Ventura where by all bind volumes - where I link a directory on my host machine to one on the container - created with docker-compose are empty. I’ve tested the same scripts on MacOS 12.4 and 12.6 and they work as expected giving me the same directory contents on the container as on the host, so it seems v13 changed some permission.

OS Version/build: MacOS 13.1, Docker Desktop & Docker via Homebrew
Docker Version: Docker version 20.10.22, build 3a2c30b
Docker Compose version: v2.15.1

The docker-compose.yml file:

version: "3"

services:
  bash:
    image: ubuntu:latest
    stdin_open: true
    tty: true
    volumes:
      - ./:/app
    command: "/bin/bash"

So this should be creating a directory on the container called /app and linking that to the host directory the compose file is in.

But when I start the container:

❯ docker-compose up --build
[+] Running 1/0
 ⠿ Container ruby-docker-bash-1  Created                                                             0.0s
Attaching to ruby-docker-bash-1

And login, the /app directory is empty:

❯ docker exec -it ruby-docker-bash-1 /bin/bash
root@9644de175d48:/# cd app/
root@9644de175d48:/app# ls -la
total 4
drwxr-xr-x 2 root root   40 Feb  1 09:59 .
drwxr-xr-x 1 root root 4096 Feb  1 09:39 ..

The total 4 is really weird here as there are 4 files supposed to be there, but not accessible:

root@9644de175d48:/app# cat Gemfile
cat: Gemfile: No such file or directory

This is the directory contents on the host are:

❯ ls -la
.rw-r--r-- 2.7k paul  1 Feb 09:31 Dockerfile
.rw-r--r-- 3.9k paul  1 Feb 09:32 Gemfile
.rw-r--r--  27k paul  1 Feb 09:32 Gemfile.lock
.rw-r--r--  149 paul  1 Feb 10:00 docker-compose.yml

If anyone has any experience with what might be going wrong or how I can get past this absolute time-sink of an issue, I’d really appreciate it.

Thank you!

Before investigating it further, are you using “virtiofs” for file sharing (general settings) or other legacy solutions?

Thank you so much for replying.

I currently only have docker/docker-compose CLI installed via Homebrew. I did have Docker Desktop installed, but removed it as the cli versions are the same.

I’m not 100% sure how to check if “virtiofs” is enable. My docker .config looks like this:

~/.docker
❯ cat config.json
      {
          "currentContext": "colima"
      }

My docker system info is as follows:

❯ docker info
Client:
 Context:    colima
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.10.0)
  compose: Docker Compose (Docker Inc., v2.15.1)
  dev: Docker Dev Environments (Docker Inc., v0.0.5)
  extension: Manages Docker extensions (Docker Inc., v0.2.17)
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc., 0.6.0)
  scan: Docker Scan (Docker Inc., v0.23.0)

Server:
 Containers: 2
  Running: 2
  Paused: 0
  Stopped: 0
 Images: 8
 Server Version: 20.10.11
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 1e5ef943eb76627a6d3b6de8cd1ef6537f393a71
 runc version: b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
 init version:
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.10.93-0-virt
 Operating System: Alpine Linux v3.14
 OSType: linux
 Architecture: aarch64
 CPUs: 4
 Total Memory: 3.833GiB
 Name: colima
 ID: 5V5V:ABYA:3IWZ:ZHJN:2MKQ:GSEV:PPDI:3ISO:SAIZ:QO25:77E4:D7XD
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

There is no native macOS container so if you can run Docker containers, there is a virtual machine behind it. Based on the docker context I guess it is colima

You should probably open an issue in that repository. I have no experience with colima.

I also had the same issue with Docker Desktop, which makes me wonder if Colima might not be at fault?

Maybe. But I can’t give you advice related to Colima :slight_smile: The last time I saw a question about missing files virtiofs solved it.

I’ve just checked out their issues and I believe this issue has fixed my issue.

Thank you so much for your help, have a great day. :slight_smile: