colima icon indicating copy to clipboard operation
colima copied to clipboard

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

Open Stokestack opened this issue 1 year ago • 5 comments

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

  • [ ] macOS Intel <= 13 (Ventura)
  • [ ] macOS Intel >= 14 (Sonoma)
  • [ ] Apple Silicon <= 13 (Ventura)
  • [X] Apple Silicon >= 14 (Sonoma)
  • [ ] Linux

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",

Stokestack avatar Jul 16 '24 00:07 Stokestack

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.

abiosoft avatar Jul 16 '24 17:07 abiosoft

#83

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

magicgopher avatar Jul 17 '24 09:07 magicgopher

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.

Stokestack avatar Jul 17 '24 19:07 Stokestack

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)

tohn avatar Aug 05 '24 09:08 tohn

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.

modkaffes avatar Oct 08 '24 09:10 modkaffes

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

tantweiler avatar Oct 21 '24 13:10 tantweiler

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 avatar Nov 01 '24 18:11 nightpool

~~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!

nightpool avatar Nov 01 '24 18:11 nightpool