abiosoft / colima

Container runtimes on macOS (and Linux) with minimal setup
MIT License
19.43k stars 391 forks source link

Attempts to mount volumes fail with permissions errors in Colima, but not Docker Desktop #1067

Open Stokestack opened 3 months ago

Stokestack commented 3 months ago

Description

I switched from Docker Desktop to Colima, but found I could no longer run my development environment. Specifically, I couldn't run Compose to build Supabase, because the process produced hundreds of errors like this:

supabase-db | chown: changing ownership of '/var/lib/postgresql/data': Permission denied

Version

colima version 0.6.9 git commit: c3a31ed05f5fab8b2cdbae835198e8fb1717fd0f

Operating System

Output of colima status

INFO[0000] colima is running using QEMU
INFO[0000] arch: aarch64
INFO[0000] runtime: docker
INFO[0000] mountType: sshfs
INFO[0000] socket: unix:///Users/me/.colima/default/docker.sock

Reproduction Steps

Install with Homebrew

brew install docker
brew install docker-credential-helper
brew install docker-compose
brew install colima

Go into ~/.docker/config.json and change the value for credsStore from desktop to osxkeychain Also add

 "cliPluginsExtraDirs": [
     "/opt/homebrew/lib/docker/cli-plugins"
 ]

Download Supabase

Get the code git clone --depth 1 https://github.com/supabase/supabase

Go to the docker folder cd supabase/docker

Copy the fake env vars cp .env.example .env

Make sure Colima is running colima start

Pull the latest images docker compose pull

Start the services (in detached mode) docker compose up -d

This will fail. Now stop Colima: colima stop

Launch Docker Desktop and retry: docker compose up -d

Expected behaviour

The container(s) is built and runs, as it does when Docker Desktop is running.

Additional context

Interestingly, it still works with Docker Desktop running even though I left the following in ~/.docker/config.json

    "credsStore": "osxkeychain",
    "currentContext": "colima",
abiosoft commented 3 months ago

Can you try running colima with macOS virtualization framework instead of qemu?

# delete existing instance
colima delete 

# create new instance with vz
colima start --vm-type=vz

I have tested and it seems to work fine.

magicgopher commented 3 months ago

83

Here is a write override.yaml configuration, it seems to solve your problem.

Stokestack commented 3 months ago

Thanks guys. Does that mean you were able to reproduce it? I have since removed Colima and installed Orbstack, and I'd rather not mess with it further if you guys don't need me to.

However, I'm happy to help if necessary.

tohn commented 3 months ago

Can you try running colima with macOS virtualization framework instead of qemu?

# delete existing instance
colima delete 

# create new instance with vz
colima start --vm-type=vz

I have tested and it seems to work fine.

Thanks for this, but I also had to set the mountType to virtiofs (at least with colima start --edit)

modkaffes commented 1 month ago

Can you try running colima with macOS virtualization framework instead of qemu?

# delete existing instance
colima delete 

# create new instance with vz
colima start --vm-type=vz

I have tested and it seems to work fine.

Using vz instead of QEMU also fixes the issue in Sequoia.

tantweiler commented 2 weeks ago

@abiosoft if vz is obviously the standard for macOS, wouldn't it make sense to add this information to the installation documentation?

nightpool commented 1 week ago

I'm still seeing this issue with vz and virtiofs:

narakaloka terraform-genius % colima status -v
INFO[0000] colima is running using macOS Virtualization.Framework 
INFO[0000] arch: x86_64                                 
INFO[0000] runtime: docker                              
INFO[0000] mountType: virtiofs                          
INFO[0000] socket: unix:///Users/nightpool/.colima/default/docker.sock 

macbook pro m3

nightpool commented 1 week ago

Ah, the issue was my architecture. If i'm using x86_64 with qemu, I get the error, even using vz and virtiofs. If I use aarch64, I don't.

EDIT: I think i misunderstood what the --arch option does. If I want to use x86_64 virtualization, then I should have arch set to aarch64, with Rosetta 2 virtualization, I think. This is confusing!