I have a web server and php running inside a container, and it is responding with 403 to all requests. Using the command docker logs php can see this line in the logs:

[Tue Sep 07 06:05:22.902860 2021] [core:error] [pid 6144] (13)Permission denied: [client 172.18.0.19:54204] AH00035: access to /foo denied (filesystem path '/var/www/html/fooapp/app') because search permissions are missing on a component of the path 172.18.0.13:80 172.18.0.19 - - [07/Sep/2021:06:05:22 +0000] "GET /foo HTTP/1.1" 403 437 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36"

This is a local development setup. The code running on the web server is volume mounted to the container from outside (ie. it is shared between the container and host):

  volumes:
    - ./app:/var/www/html/fooapp/app

This problem does not occur with Docker Desktop. I can help investigate the issue further.

Was wondering which aspect of docs you need written.

Thomas

If I cd /tmp and do the 

curl -LO https://raw.githubusercontent.com/abiosoft/colima/v0.1.10/colima && sudo install colima /usr/local/bin/colima

the result is an unusable install.  There appears to be something tied to mount paths or directories that assume the path is not /tmp  or maybe more specific not a symlink. 

The resulting behavior looks like this

nachosystem:$ colima start
[colima] 15:42:33 creating and starting VM ...
nachosystem:$ cat .colima/out.log 

/usr/local/bin/lima
/usr/local/bin/docker
time="2021-09-22T15:42:33-04:00" level=info msg="Terminal is not available, proceeding without opening an editor"
time="2021-09-22T15:42:33-04:00" level=fatal msg="field `mounts[1].location` refers to a non-directory path: \"/tmp/colima\": %!w(<nil>)

hello, thank you for the wonderful project!

My colima version is 0.2.2.

Here is the result of colima start:

$ colima start
INFO[0000] starting colima                              
INFO[0000] creating and starting ...                     context=vm
> msg="SSH Local Port: 52404"
> msg="[hostagent] Waiting for the essential requirement 1 of 5: \"ssh\""
> msg="[hostagent] QEMU has exited"
> msg="exiting, status={Running:false Degraded:false Exiting:true Errors:[] SSHLocalPort:0} (hint: see \"/Users/swyx/.lima/colima/ha.stderr.log\")"
FATA[0045] error starting vm: error at 'creating and starting': exit status 1 

$ limactl stop colima \ limactl delete colima \ colima start

FATA[0000] expected status "Running", got "Stopped" (maybe use `limactl stop -f`?) 
INFO[0000] The QEMU process seems already stopped       
INFO[0000] The host agent process seems already stopped 
INFO[0000] Removing *.pid *.sock under "/Users/swyx/.lima/colima" 
INFO[0000] Removing "/Users/swyx/.lima/colima/ha.sock"  
INFO[0000] Removing "/Users/swyx/.lima/colima/qmp.sock" 
INFO[0000] Removing "/Users/swyx/.lima/colima/serial.sock" 
INFO[0000] Deleted "colima" ("/Users/swyx/.lima/colima") 
INFO[0000] starting colima                              
INFO[0000] creating and starting ...                     context=vm
> msg="SSH Local Port: 52438"
> msg="[hostagent] Waiting for the essential requirement 1 of 5: \"ssh\""
> msg="[hostagent] QEMU has exited"
> msg="exiting, status={Running:false Degraded:false Exiting:true Errors:[] SSHLocalPort:0} (hint: see \"/Users/swyx/.lima/colima/ha.stderr.log\")"
FATA[0001] error starting vm: error at 'creating and starting': exit status 1 

$ colima delete
are you sure you want to delete colima and all settings? [y/N] y
INFO[0002] deleting colima                              
INFO[0002] deleting ...                                  context=vm
INFO[0002] done                                         

$ colima start
INFO[0000] starting colima                              
INFO[0000] creating and starting ...                     context=vm
> msg="SSH Local Port: 52450"
> msg="[hostagent] Waiting for the essential requirement 1 of 5: \"ssh\""
> msg="[hostagent] QEMU has exited"
> msg="exiting, status={Running:false Degraded:false Exiting:true Errors:[] SSHLocalPort:0} (hint: see \"/Users/swyx/.lima/colima/ha.stderr.log\")"
FATA[0001] error starting vm: error at 'creating and starting': exit status 1 

$ cat /Users/swyx/.lima/colima/ha.stderr.log
{"level":"debug","msg":"firmware candidates = [/usr/local/share/qemu/edk2-x86_64-code.fd /usr/share/OVMF/OVMF_CODE.fd /usr/share/qemu/ovmf-x
       │ 86_64-code.bin]","time":"2021-11-08T00:30:22-08:00"}
   2   │ {"level":"debug","msg":"OpenSSH version 8.1.1 detected","time":"2021-11-08T00:30:22-08:00"}
   3   │ {"level":"debug","msg":"AES accelerator seems available, prioritizing [email protected] and [email protected]","time":"2021-11-08T
       │ 00:30:22-08:00"}
   4   │ {"level":"info","msg":"Starting QEMU (hint: to watch the boot progress, see \"/Users/swyx/.lima/colima/serial.log\")","time":"2021-11-08T00:
       │ 30:22-08:00"}
   5   │ {"level":"debug","msg":"qCmd.Args: [/usr/local/bin/qemu-system-x86_64 -cpu host -machine q35,accel=hvf -smp 2,sockets=1,cores=2,threads=1 -m
       │  2048 -drive if=pflash,format=raw,readonly=on,file=/usr/local/share/qemu/edk2-x86_64-code.fd -boot order=c,splash-time=0,menu=on -drive file
       │ =/Users/swyx/.lima/colima/diffdisk,if=virtio -cdrom /Users/swyx/.lima/colima/cidata.iso -netdev user,id=net0,net=192.168.5.0/24,dhcpstart=19
       │ 2.168.5.15,hostfwd=tcp:127.0.0.1:52450-:22 -device virtio-net-pci,netdev=net0,mac=52:55:55:56:3a:79 -device virtio-rng-pci -display none -de
       │ vice virtio-vga -device virtio-keyboard-pci -device virtio-mouse-pci -parallel none -chardev socket,id=char-serial,path=/Users/swyx/.lima/co
       │ lima/serial.sock,server=on,wait=off,logfile=/Users/swyx/.lima/colima/serial.log -serial chardev:char-serial -chardev socket,id=char-qmp,path
       │ =/Users/swyx/.lima/colima/qmp.sock,server=on,wait=off -qmp chardev:char-qmp -name lima-colima -pidfile /Users/swyx/.lima/colima/qemu.pid]","
       │ time":"2021-11-08T00:30:22-08:00"}
   6   │ {"level":"info","msg":"Waiting for the essential requirement 1 of 5: \"ssh\"","time":"2021-11-08T00:30:22-08:00"}
   7   │ {"level":"debug","msg":"executing script \"ssh\"","time":"2021-11-08T00:30:22-08:00"}
   8   │ {"level":"debug","msg":"executing ssh for script \"ssh\": /usr/bin/ssh [ssh -F /dev/null -o IdentityFile=\"/Users/swyx/.lima/_config/user\" 
       │ -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o NoHostAuthenticationForLocalhost=yes -o GSSAPIAuthentication=no -o PreferredA
       │ uthentications=publickey -o Compression=no -o BatchMode=yes -o IdentitiesOnly=yes -o Ciphers=\"^[email protected],[email protected]
       │ m\" -o User=swyx -o ControlMaster=auto -o ControlPath=\"/Users/swyx/.lima/colima/ssh.sock\" -o ControlPersist=5m -p 52450 127.0.0.1 -- /bin/
       │ bash]","time":"2021-11-08T00:30:23-08:00"}
   9   │ {"level":"debug","msg":"stdout=\"\", stderr=\"ssh: connect to host 127.0.0.1 port 52450: Connection refused\\r\\n\", err=failed to execute s
       │ cript \"ssh\": stdout=\"\", stderr=\"ssh: connect to host 127.0.0.1 port 52450: Connection refused\\r\\n\": exit status 255","time":"2021-11
       │ -08T00:30:23-08:00"}
  10   │ {"level":"debug","msg":"qemu[stderr]: qemu-system-x86_64: Error: HV_ERROR","time":"2021-11-08T00:30:23-08:00"}
  11   │ {"error":"signal: abort trap","level":"info","msg":"QEMU has exited","time":"2021-11-08T00:30:23-08:00"}

I dont really know how to debug from here.. hoping for some help!

Maybe a CLI flag could be used to determine if the runtime should be run as root or as the user inside the VM.

Not sure if it's that necesarry, but could be nice to have.

I've tried to start latest available artifact and it failed.
colima-Darwin-arm64 (saved as colima_ on my machine), version: v0.3.0-ci-test

/Users/morph/dev/colima_/colima_ start 
INFO[0000] using docker runtime                         
WARN[0000] error detecting Lima config directory: error retrieving lima info, ensure lima version is >0.7.4 
WARN[0000] falling back to default '$HOME/.lima'        
INFO[0000] starting colima                              
INFO[0000] starting ...                                  context=vm
INFO[0021] provisioning ...                              context=docker
INFO[0022] starting ...                                  context=docker
> open /usr/local/colima/binfmt.tar: no such file or directory
WARN[0028] could not enable multi-arch images: exit status 1  context=docker
> Unable to find image 'colima-binfmt:latest' locally
> docker: Error response from daemon: pull access denied for colima-binfmt, repository does not exist or may require 'docker login': denied: requested access to the resource is denied.
> See 'docker run --help'.
WARN[0030] could not enable multi-arch images: exit status 125  context=docker
INFO[0030] done

docker ps
Cannot connect to the Docker daemon at unix:///Users/morph/.colima/docker.sock. Is the docker daemon running?

/Users/morph/dev/colima_/colima_ status
WARN[0000] error detecting Lima config directory: error retrieving lima info, ensure lima version is >0.7.4 
WARN[0000] falling back to default '$HOME/.lima'        
INFO[0000] colima is running                            
INFO[0000] runtime: docker                              
INFO[0000] arch: aarch64                                

Please let me know if I can somehow obtain more data.

• My environment:
  • colima: v0.1.9
  • lima: v0.6.4
  • Host OS: macOS Big Sur Version 11.4
• My host username (Takayuki.Kobayashi) is firstname.lastname form.
  • I found that, from lima v0.6.4, some problematic usernames fallback to lima.
    • Related to lima-vm/lima#214, lima-vm/lima#243
• Terminal output:

  $ colima start
  [colima] 09:42:29 creating and starting VM ...
  [colima] 09:43:24 provisioning VM ...
  [colima] 09:43:24 provisioning docker ...
  [colima] 09:43:24 provisioning docker in VM ...
  $ echo $?
  6
  $ colima status # errors related k8s is ok because I don't use it
  docker is installed VM?
  success
  
  docker is running in VM?
  success
  
  docker is installed on Host?
  success
  
  docker client on host can access the VM server?
  error
  
  kubernetes is installed in VM?
  error
  
  kubernetes is running in VM?
  error
  
  kubernetes client on host can access the VM?
  error
  
  some checks failed :(
  

• Extract from ~/.colima/out.log:

  [...]
  time="2021-09-19T09:42:29+09:00" level=warning msg="local user \"Takayuki.Kobayashi\" is not a valid Linux username (must match \"^[a-z_][a-z0-9_-]*$\"); using \"lima\" username instead"
  [...]
  usermod: user 'Takayuki.Kobayashi' does not exist
  exit status 6
  

When adding lima user to docker group, it assumes that username on lima is the same with the host username.
But, for some problematic usernames, it doesn't exist on lima.

Currently my workaround is to specify username in socket.sh (by replacing 127.0.0.1 with ${USER}@127.0.0.1) and start with overwritten USER (by USER=lima colima start), but there should be a better way...

This is more of a question I am sure people will start to ask. Is there a way to map logic to allow vscode to see this as docker running? At the moment given the base default setup I can run docker to do all the basic stuff on the CLI, however when I try to load vs code to do a remote docker dev environment, I get an error message that vscode about docker is not running. I am not sure if anyone know if there is a work around to this. It would be great if there was.

Setup

Following the README.md and, I did the following

• Stop Docker Desktop for Mac
• brew install lima docker kubectl
• curl -LO https://raw.githubusercontent.com/abiosoft/colima/v0.1.7/colima && sudo install colima /usr/local/bin/colima

Problem

As suggested in the gif for the minimal setup, I tried

docker ps => Results in Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
colima start

[colima] 11:12:52 creating and starting VM ...
[colima] 11:13:34 provisioning VM ...
[colima] 11:13:34 provisioning docker ...
[colima] 11:13:34 provisioning docker in VM ...
[colima] 11:13:56 restarting VM to complete docker setup ...
[colima] 11:14:27 VM restarted
[colima] 11:14:27 starting docker ...
[colima] 11:14:28 docker startup successful
[colima] 11:14:28 done

⚠️ docker ps => But this also results in Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

Am I missing something?

Further information

colima status

docker is installed VM?
success

docker is running in VM?
success

docker is installed on Host?
success

docker client on host can access the VM server?
error

[...]

some checks failed :(

~/.colima/out.log

Linux
/usr/bin/docker
● docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2021-09-16 09:14:17 UTC; 3min 53s ago
TriggeredBy: ● docker.socket
       Docs: https://docs.docker.com
   Main PID: 751 (dockerd)
      Tasks: 10
     Memory: 129.7M
     CGroup: /system.slice/docker.service
             └─751 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
/usr/local/bin/docker
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Client:
 Cloud integration: 1.0.17
 Version:           20.10.8
 API version:       1.41
 Go version:        go1.16.6
 Git commit:        3967b7d
 Built:             Fri Jul 30 19:55:20 2021
 OS/Arch:           darwin/amd64
 Context:           default
 Experimental:      true
exit status 1
bash: line 1: minikube: command not found
exit status 127

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
The connection to the server localhost:8080 was refused - did you specify the right host or port?

kubectl cluster-info dump

The connection to the server localhost:8080 was refused - did you specify the right host or port?

/var/run/docker.sock symlinks

ll /var/run/docker.sock

/var/run/docker.sock
lrwxr-xr-x 1 root 35 Sep 16 11:00 /var/run/docker.sock -> ~/.colima/docker.sock

ls -al ~/.colima
~/.colima
total 8
drwxr-xr-x   4 emueller  128 Sep 16 11:14 .
drwxr-xr-x+ 61 emueller 1952 Sep 16 11:13 ..
-rw-r--r--   1 emueller 1163 Sep 16 11:18 out.log
-rwxr-xr-x   1 emueller  217 Sep 16 11:14 socket.sh

⚠️ There is no ~/.colima/docker.sock

My Mac config

Problem Share

lima reads volumes as read-only by default.

To convert a volume to write, I should use the --mount option.

I applied and executed colima start --mount {directory_path}:w to apply the writable option to the volume.

After the write test I did colima stop for clean up

$ colima stop

and then I restart colima just default mode

$ colima start

Then, the volumes that did the write test were not mounted properly.

So I tried to connect to colima with ssh.

$ colima ssh

And I see that the direcotry that I have tested before mount is mounted on colima vm.

my@lima-colima:/Users/foo$ ls
apps  kube

app and kube were used to test mount with --mount app:w kube:w .

I used colima delete and tried colima start again, but it did not clean up. 🤔

How can I clean up the previously mounted settings in lima?

As I think, it doesn't seem to be initialized during clean up after modifying default.yaml of lima.

Any good solutions for this?

Hi there,

Thank you again for the project.

Would it be possible to allow passing a YAML to either completely replace the default Lima config or override (think merging with your YAML config)?

The issue is that there's no way to modify networks for example (and would not be a good idea imo to port to CLI args).

Let me know your thoughts.

Cheers

I was using docker-desktop and now planning to migrate to colima.

1. Installed lima and colima using brew
2. Uninstall docker-desktop app using appcleaner
3. Installed docker using brew install docker

now when I try to build a dockerfile it throws following error

➜ docker build -t test .
[+] Building 2.1s (3/3) FINISHED
 => [internal] load build definition from Dockerfile                                                                                                             0.0s
 => => transferring dockerfile: 125B                                                                                                                             0.0s
 => [internal] load .dockerignore                                                                                                                                0.0s
 => => transferring context: 2B                                                                                                                                  0.0s
 => ERROR [internal] load metadata for docker.io/library/node:latest                                                                                             2.0s
------
 > [internal] load metadata for docker.io/library/node:latest:
------
failed to solve with frontend dockerfile.v0: failed to create LLB definition: rpc error: code = Unknown desc = error getting credentials - err: exec: "docker-credential-desktop": executable file not found in $PATH, out: ``

Is docker-desktop required to use colima?

At the outset, let me say I'm really thankful for this awesome contribution!

I have a small issue - and a workaround which I think can benefit others if it gets fixed/incorporated into the core:

1. I start colima with the command-line invocations (colima start)
2. use it as normal to build images, etc.
3. I then shutdown colima (colima stop)
4. Subsequently, even if I start colima again (colima start), the docker commands don't work.

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

I found out that this is due to the fact that the socket file is still available, and is a broken symlink

If I delete the /var/run/docker.sock - then I am able to restart colima and continue with work:

sudo rm -rf /var/run/docker.sock

Can this issue be fixed? Or is there a better way to solve this problem?

This happens when the VM is stopped (due to colima stop or there's a restart).

❯ colima start
INFO[0000] using docker runtime
INFO[0000] starting colima
INFO[0000] already running                               context=vm
INFO[0000] provisioning ...                              context=docker
FATA[0000] error provisioning docker: error at 'provisioning': error copying deamon.json: exit status 1

I'm trying to run a dnsmasq server in docker. Example command is
docker run --rm --cap-add NET_ADMIN -p 12345:53/tcp -p 12345:53/udp andyshinn/dnsmasq:2.83 --address=/.foo.bar/123.123.123.123

The dns query dig @127.0.0.1 -p 12345 foo.bar runs fine inside the VM, but I get a connection timeout / no reply on host machine. On docker for desktop there are no such issues.

docker ps` output

CONTAINER ID   IMAGE                    COMMAND                  CREATED          STATUS          PORTS                                                                              NAMES
38b6232a2270   andyshinn/dnsmasq:2.83   "dnsmasq -k --addres…"    3 minutes ago   Up 3 minutes    0.0.0.0:12345->53/tcp, 0.0.0.0:12345->53/udp, :::12345->53/tcp, :::12345->53/udp   kind_black

I'm running colima v0.2.2 - (thanks for the great s/w btw)

Today I started on a java project, and I was trying to run the springboot application (default starter kit) from a docker container - but, I keep getting this error:

 * What went wrong:
 Gradle could not start your build.
 > Could not create service of type BuildModelController using BuildScopeServicesProvider.createBuildModelController().
    > Could not create service of type FileHasher using BuildSessionServices.createFileHasher().
       > java.io.IOException: Read-only file system

I am starting colima with colima start as normal.

The Dockerfile is quite simple (it simply mounts the current directory to /app and tries to run gradlew):

FROM docker.io/library/amazoncorretto:11 AS build

VOLUME ["/app"]

WORKDIR /app

CMD ["./gradlew", "bootRun"]

Could you please help?

Hi!

My install (v0.1.10) can't correctly create a useable VM/configure my Docker client to use the VM.

$ colima start
[colima] 13:19:42 VM is already running, config flags will be ignored (if specified).
[colima] 13:19:42 provisioning VM ...
[colima] 13:19:42 provisioning docker ...
[colima] 13:19:42 provisioning docker in VM ...
$ colima status
docker is installed VM?
error

docker is running in VM?
error

docker is installed on Host?
success

docker client on host can access the VM server?
error

kubernetes is installed in VM?
error

kubernetes is running in VM?
error

kubernetes client on host can access the VM?
error

some checks failed :(
                                                                                                                          
$ docker version                                                                                                                                    
Client: Docker Engine - Community
 Version:           20.10.8
 API version:       1.41
 Go version:        go1.16.6
 Git commit:        3967b7d28e
 Built:             Thu Jul 29 13:55:47 2021
 OS/Arch:           darwin/amd64
 Context:           default
 Experimental:      true
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
$ colima version
colima v0.1.10

Docker
Client Version: v20.10.8
Server Version: v
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

Hey @abiosoft. colima is something I find that I use on a daily basis and really want to thank the contributors for your efforts.

Is there any way people can sponsor the work in this repo?

I would like to at least buy the contributors a coffee or contribute something small every month as a thank you 😄

Currently, kubernetes 1.22 is a little new for me, so I've edited my local colima tree to use v1.21.5+k3s2

It would be nice to be able to specify the kubernetes version on the command line ... will be especially useful for desktop testing applications on different versions.

Cheers.

There is a fix in the new lima for DNS resolution:
lima-vm/lima#281

And it appears that what happens is the iptables rule for the nat redirect hits after the docker nat rule:

iptables -t nat -L -v --line-numbers
# Warning: iptables-legacy tables present, use iptables-legacy to see them
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        2    88 DOCKER     all  --  any    any     anywhere             anywhere             ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 DOCKER     all  --  any    any     anywhere            !localhost/8          ADDRTYPE match dst-type LOCAL
2       26  1963 DNAT       udp  --  any    any     anywhere             192.168.5.3          udp dpt:domain to:192.168.5.2:52464

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1       14  1073 MASQUERADE  all  --  any    !docker0  172.17.0.0/16        anywhere

Chain DOCKER (2 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 RETURN     all  --  docker0 any     anywhere             anywhere

You can test this by running dig inside a container pointed at the port in the nat rule, that works. But trying to hit 192.168.5.3.

I'm not sure where to fix this, but it probably just means that the nat rule from lima needs to run before docker installs it's rules. Trouble is I can't figure out where that is happening.

Definitely not sure if this would go here or in lima but I'm unable to do multi-arch builds using buildx. Here is an example error that I get

docker buildx build . -t base-php --platform linux/amd64,linux/arm64
...
#12 36.47 E: Sub-process /usr/bin/dpkg returned an error code (1)
------
Dockerfile:9
--------------------
   8 |
   9 | >>> RUN \
  10 | >>>   apt update && \
  11 | >>>   apt dist-upgrade -y && \
  12 | >>>   apt install gnupg -y && \
  13 | >>>   apt clean
  14 |
--------------------
error: failed to solve: process "/dev/.buildkit_qemu_emulator /bin/bash -c apt update &&   apt dist-upgrade -y &&   apt install gnupg -y &&   apt clean" did not complete successfully: exit code: 100

I get this same error on both my 2018 i7 Mac mini and my 2020 M1 MBA.

This is my config

vm:
    cpu: 6
    disk: 60
    memory: 6
    mounts:
        - /Users/dustin/wp-local-docker-sites:w
        - /Users/dustin/.wplocaldocker:w
runtime: docker
kubernetes:
    enabled: false
    version: v1.22.2

Suggestion

When we create a new VM using colima start, then the client displays the log about the commands executed but only a few lines are displayed and rotation take place after x lines.

Would it be possible to have an option to see all the commands executed when the VM is created ?

colima start --runtime containerd --mount $HOME/temp:w
INFO[0000] starting colima
INFO[0000] creating and starting ...                     context=vm
> msg="[hostagent] time=\"2021-10-19T13:11:45+02:00\" level=info msg=\"Using cache \\\"/Users/cmoullia/Library/Caches/lima/download/by-url-sha256/a1ebbffd3dcb629755d3f6bINFO[0053] starting ...                                  context=containerd
INFO[0054] done

That would make it easier to clone this into some place like ~/.colima and adding that to the PATH so we can keep it up to date.

Hi 👋

I just came across this project and it seems very promising, thanks for your work!

I have a little issue while setup a docker container with writable volume (it's a database).

I start Colima and I mount the local directory:

colima start --mount /Users/matthieugouel/Documents/Code:rw

Then, I try to create the docker container:

 docker run  --name clickhouse -v $(pwd)/volumes/clickhouse:/var/lib/clickhouse -p 9000:9000 yandex/clickhouse-server:latest

But the issue is:

chown: changing ownership of '/var/lib/clickhouse/': Read-only file system

It's strange because when I ssh inside the VM I have these rights for the volume directory:

drwxr-xr-x 1 matthieugouel dialout  352 Nov  7 13:45 volumes

Would you have an idea of why this issue is happening?

Best,
Matthieu.

The VM does not use the same nameservers. This is necessary to pull images from an internal-only Docker repository.

I fixed this by copying the contents of the host's /etc/resolv.conf into the VM's /etc/resolv.conf.

Default /etc/resolv.conf

nameserver 127.0.0.53
options edns0 trust-ad
search .

Modified /etc/resolv.conf (values modified for example)

search internal.stuff
nameserver 1.2.3.4
nameserver 5.6.7.8

This will make installation a bit easier for homebrew users.

Thanks for this very useful project.
I am looking for primary information about Lima's support for writable volumes that exists in README.md.

https://github.com/abiosoft/colima/blob/305d01fa83e0024738dfd028920cf72858f6a600/README.md#faq
Colima uses Lima for the VM and Lima's support for writable volumes is still experimental.

I've explored the lima's repository and guessed that the following text is primary information about it.
Am I correct in this understanding?

https://github.com/lima-vm/lima/blob/544d15d5af3ff3eb144148a36c17bc8f62f92a9c/pkg/limayaml/default.yaml#L43
Setting writable to true is possible, but untested and dangerous.

Question)

If I use this, will I be able to fully use what the docker engine provides?

Question Details

Currently, I am a user who uses engines such as docker and docker compose on a mac using docker for mac.

Recently, I found out that docker for desktop is paid for, so I was looking for other alternatives.

Then I got to know colima.

Ideally, colima configures docker server on lima and it seems that docker server can be accessed from docker client on host (mac).

So, it can be considered that it is compatible with all docker features without any problems.

Contrary to my thoughts, is there any incompatibility when replacing colima without using docker for desktop ?

Thanks for reading the question :)

Official apt source is slow in some network environments, maybe configurable apt source is better.

I have removed the ~/.docker folder completely. I have also installed v0.2.0 of colima.

When I run colima start, this is the error that I get:

error provisioning docker: error at 'provisioning': error copying deamon.json: exit status 1

Employ the use of docker context released since Docker 19.03.

This will enable the avoidance of clashes with other docker servers (especially Docker for Mac) and will allow users to try out Colima without affecting their current setups.

I am trying to use colima instead of Docker Desktop. When trying to cross-compile a rust project to aarch64 (via https://github.com/rust-embedded/cross, which is CLI that calls docker in the end) it somehow does not work.

cross build --release --target aarch64-unknown-linux-gnu
error: DEPRECATED: future versions of rustup will require --force-non-host to install a non-host toolchain as the default.
warning: toolchain 'stable-x86_64-unknown-linux-gnu' may not be able to run on this system.
warning: If you meant to build software to target that platform, perhaps try `rustup target add x86_64-unknown-linux-gnu` instead?
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: latest update on 2021-11-01, rust version 1.56.1 (59eed8a2a 2021-11-01)
info: downloading component 'cargo'
info: downloading component 'clippy'
info: downloading component 'rust-docs'
 17.3 MiB /  17.3 MiB (100 %)  12.8 MiB/s in  1s ETA:  0s
info: downloading component 'rust-std'
 23.5 MiB /  23.5 MiB (100 %)  12.8 MiB/s in  1s ETA:  0s
info: downloading component 'rustc'
 52.9 MiB /  52.9 MiB (100 %)  12.8 MiB/s in  4s ETA:  0s
info: downloading component 'rustfmt'
info: installing component 'cargo'
info: installing component 'clippy'
info: installing component 'rust-docs'
 17.3 MiB /  17.3 MiB (100 %)   5.7 MiB/s in  2s ETA:  0s
info: installing component 'rust-std'
 23.5 MiB /  23.5 MiB (100 %)  14.3 MiB/s in  1s ETA:  0s
info: installing component 'rustc'
 52.9 MiB /  52.9 MiB (100 %)  14.0 MiB/s in  3s ETA:  0s
info: installing component 'rustfmt'

  stable-x86_64-unknown-linux-gnu installed - (error reading rustc version)

info: checking for self-updates
info: downloading component 'rust-std' for 'aarch64-unknown-linux-gnu'
info: installing component 'rust-std' for 'aarch64-unknown-linux-gnu'
 28.8 MiB /  28.8 MiB (100 %)  13.4 MiB/s in  2s ETA:  0s
Unable to find image 'rustembedded/cross:aarch64-unknown-linux-gnu-0.2.1' locally
aarch64-unknown-linux-gnu-0.2.1: Pulling from rustembedded/cross
b5e173e44934: Pull complete
29047100b040: Pull complete
15743a713c2a: Pull complete
4b6bc9e29877: Pull complete
45653be35864: Pull complete
190d82667f73: Pull complete
0999ab463a86: Pull complete
1abcae387ca7: Pull complete
dddd453e4629: Pull complete
1316155995d7: Pull complete
e4b709d5b7af: Pull complete
0aebb58bbbd6: Pull complete
ca33887788d7: Pull complete
01194c4c0f93: Pull complete
27b9ee115194: Pull complete
ae083dc71cb1: Pull complete
37a2a10584c8: Pull complete
b6bb12e7d793: Pull complete
Digest: sha256:fe732b95ef5ce292cb49087a2f8c09547334e1a4118ac1fc3bae8ea794b8984b
Status: Downloaded newer image for rustembedded/cross:aarch64-unknown-linux-gnu-0.2.1
sh: 1: cargo: not found
make: *** [build] Error 127

When doing the same with Docker Desktop, it gives this

cross build --release --target aarch64-unknown-linux-gnu
Unable to find image 'rustembedded/cross:aarch64-unknown-linux-gnu-0.2.1' locally
aarch64-unknown-linux-gnu-0.2.1: Pulling from rustembedded/cross
b5e173e44934: Pull complete 
29047100b040: Pull complete 
15743a713c2a: Pull complete 
4b6bc9e29877: Pull complete 
45653be35864: Pull complete 
190d82667f73: Pull complete 
0999ab463a86: Pull complete 
1abcae387ca7: Pull complete 
dddd453e4629: Pull complete 
1316155995d7: Pull complete 
e4b709d5b7af: Pull complete 
0aebb58bbbd6: Pull complete 
ca33887788d7: Pull complete 
01194c4c0f93: Pull complete 
27b9ee115194: Pull complete 
ae083dc71cb1: Pull complete 
37a2a10584c8: Pull complete 
b6bb12e7d793: Pull complete 
Digest: sha256:fe732b95ef5ce292cb49087a2f8c09547334e1a4118ac1fc3bae8ea794b8984b
Status: Downloaded newer image for rustembedded/cross:aarch64-unknown-linux-gnu-0.2.1
    Updating crates.io index
... from here on it compiles.

Not sure, if this is a supported colima usecase at all. Testing this on a Intel Mac with macOS, 11.6 latest, if that helps.

Hi everyone,

first of all, many thanks for all the work put into this awesome project!

I have the following setup:

1. Colima is running with a directory mounted into the VM as writable using colima start --mount <dir>:w.
2. I have a docker container running with a subdirectory <subdir> of <dir> mounted via a bind mount.
3. Inside the container, I run a node process which is supposed to write a modest amount (~ 400) of generated text files into yet another subdirectory of <subdir>.

Unfortunately, the process fails with EPERM: operation not permitted, open <file>. The <file> is different each time, but the number of files written before the error is always 233 or 234. I made sure that everyone (the actual computer, the VM and the container) sees the folder as writable to rule out that it is an actual problem of permissions. With Docker Desktop, no such error occurs. ulimit -n returns 256 on the computer, 1024 on the VM and 1048576 in the container.

Once again, many thanks for your efforts!

Best,
Jakub

I installed colima and docker through HomeBrew. I started colima, pulled an image and started a container. When I connect to that container, I see Could not open a connection to your authentication agent. when running ssh-add -L.
I then edited ~/.lima/colima/lima.yaml and added forwardAgent: true.

Even after killing the container and starting a new one, I still get no connection to the agent inside the container.

Am I doing something wrong?

First of all, thanks for making this, it's super great!

I wonder if it's possible to add something similar to host.docker.internal what Docker Desktop does,
so that containers can easily talk to the ports on the host OS.

Support the ability to run multiple instances of Colima.

This is already possible via an undocumented --profile flag but currently half-baked and only utilised for development purposes.

This will open up a range of possibilities including.

• Running multiple container runtimes simultaneously. e.g. containerd and docker side by side for comparison.
• Trying out new Colima versions in an isolated profile

Hi,

when running colima with kubernetes, the kubectl port-forward command doesn't work and throws the following error:
unable to do port forwarding: socat not found

I was able to fix the issue by running the following commands:

colima ssh
sudo apt-get install socat

thank you for releasing this project, it has successfully replaced docker-desktop in my workflow.

Hi there,

Thank you a lot for the project!

What would be the best approach to be able to talk to Docker inside the VM from the host? The idea is to use something like docker-compose from the host machine.

Currently, I'm forwarding the socket in Lima through lima.yaml:

portForwards:
  - guestSocket: "/var/run/docker.sock"
    hostSocket: "{{.Home}}/.lima/colima/docker.sock"

The issue right now is that colima delete will nuke the colima folder within ~/.lima and I can't seem to find a way to pass a specific YAML when creating the VM (colima start/stop will revert the YAML as well).

Let me know if there's a manual way. Currently docker ps and anything else will work but I'm not quite sure what's the magic.

Thank you in advance!

I'd like to suggest using https://goreleaser.com/ to cut releases, this will allow you to easily create cross-compiled versions for Intel and ARM macs.

Hi, thanks for colima! I've been using it for a month or so with Nix on an M1 Mac: https://github.com/hackworthltd/hacknix/blob/main/nix/pkgs/colima/default.nix

It's been working great with 519a372, both for aarch64 and x86_64 images.

Today I bumped to 57469b9, and now I get this:

 colima start --with-kubernetes --arch x86_64 --cpu 2 --memory 8                                                                                                
INFO[0000] using docker runtime                         
INFO[0000] starting colima                              
INFO[0000] starting ...                                  context=vm
INFO[0023] provisioning ...                              context=docker
INFO[0026] starting ...                                  context=docker
> command-line line 0: Unsupported option "gssapiauthentication"
> open /usr/local/colima/binfmt.tar: no such file or directory
WARN[0034] could not enable multi-arch images: exit status 1  context=docker
> command-line line 0: Unsupported option "gssapiauthentication"
> Unable to find image 'colima-binfmt:latest' locally
> docker: Error response from daemon: pull access denied for colima-binfmt, repository does not exist or may require 'docker login': denied: requested access to the resource
> See 'docker run --help'.
WARN[0035] could not enable multi-arch images: exit status 125  context=docker
INFO[0036] downloading and installing ...                context=kubernetes
INFO[0088] loading oci images ...                        context=kubernetes
INFO[0091] starting ...                                  context=kubernetes
INFO[0116] updating config ...                           context=kubernetes
INFO[0116] Switched to context "colima".                 context=kubernetes
INFO[0116] done                                         
(sagan) ~  colima status                                                                                                                                                  ~
INFO[0000] colima is running                            
INFO[0000] runtime: docker                              
INFO[0000] arch: aarch64                                
INFO[0000] kubernetes: enabled                          

~  colima list                                                                                                                                                    ~
PROFILE    STATUS     ARCH       CPUS    MEMORY    DISK
default    Running    aarch64    2       8GiB      60GiB

Oddly, I get similar warnings without Kubernetes support, but it does create an x86_64 image:

 colima start --arch x86_64 --cpu 2 --memory 8                                                                                                                  ~
INFO[0000] starting colima                              
INFO[0000] creating and starting ...                     context=vm
INFO[0123] provisioning ...                              context=docker
INFO[0124] restarting VM to complete setup ...           context=docker
INFO[0124] stopping ...                                  context=vm
INFO[0134] starting ...                                  context=vm
INFO[0222] starting ...                                  context=docker
> command-line line 0: Unsupported option "gssapiauthentication"
> Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
WARN[0230] could not enable multi-arch images: exit status 1  context=docker
> command-line line 0: Unsupported option "gssapiauthentication"
> docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?.
> See 'docker run --help'.
WARN[0231] could not enable multi-arch images: exit status 125  context=docker
> command-line line 0: Unsupported option "gssapiauthentication"
> Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
WARN[0233] could not clear image cache for multi-arch images: exit status 1  context=docker
INFO[0233] done                                         

 colima status                                                                                                                                                  ~
INFO[0000] colima is running                            
INFO[0000] runtime: docker                              
INFO[0000] arch: x86_64         

Edit #1

Now, after running the previous command, deleting the cluster, and then trying again with Kubernetes, I get this:

 colima start --with-kubernetes --arch x86_64 --cpu 2 --memory 8                                                                                                ~
INFO[0000] starting colima                              
INFO[0000] creating and starting ...                     context=vm
INFO[0090] provisioning ...                              context=docker
INFO[0090] restarting VM to complete setup ...           context=docker
INFO[0090] stopping ...                                  context=vm
INFO[0101] starting ...                                  context=vm
INFO[0180] starting ...                                  context=docker
> command-line line 0: Unsupported option "gssapiauthentication"
> Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
WARN[0187] could not enable multi-arch images: exit status 1  context=docker
> command-line line 0: Unsupported option "gssapiauthentication"
> docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?.
> See 'docker run --help'.
WARN[0190] could not enable multi-arch images: exit status 125  context=docker
> command-line line 0: Unsupported option "gssapiauthentication"
> Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
WARN[0193] could not clear image cache for multi-arch images: exit status 1  context=docker
INFO[0194] downloading and installing ...                context=kubernetes
INFO[0246] loading oci images ...                        context=kubernetes
INFO[0325] starting ...                                  context=kubernetes
INFO[0332] updating config ...                           context=kubernetes
FATA[0332] error starting kubernetes: error at 'updating config': error fetching kubeconfig on guest: exit status 1 

 colima status                                                                                                                                                  ~
INFO[0000] colima is running                            
INFO[0000] runtime: docker                              
INFO[0000] arch: x86_64                                 
INFO[0001] kubernetes: enabled           

I can't reproduce the original error anymore.

FYI, I'm not running Docker, and the versions that I'm using are as follows:

 docker version
Client:
 Version:           20.10.9
 API version:       1.41
 Go version:        go1.16.9
 Git commit:        v20.10.9
 Built:             Thu Jan  1 00:00:00 1970
 OS/Arch:           darwin/arm64
 Context:           colima
 Experimental:      true

Server:
 Engine:
  Version:          20.10.11
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.10
  Git commit:       847da184ad5048b27f5bdf9d53d070f731b43180
  Built:            Fri Nov 19 03:41:34 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.5.8
  GitCommit:        1e5ef943eb76627a6d3b6de8cd1ef6537f393a71
 runc:
  Version:          1.0.0-rc95
  GitCommit:        b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
 docker-init:
  Version:          0.19.0
  GitCommit:        

 kubectl version
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.3", GitCommit:"c92036820499fedefec0f847e2054d824aea6cd1", GitTreeState:"archive", BuildDate:"1980-01-01T00:00:00Z", GoVersion:"go1.16.9", Compiler:"gc", Platform:"darwin/arm64"}

There is a problem with migration from Docker Desktop to Colima docker environment.
When the container is just started, it's mapped port is not available immediately.
I'm not quite sure about all what happens underneath (is it an issue of Lima/Colima/jna/docker-java), but let me give my assumption, the demo is provided as well.

We use testcontainers, a popular framework that bootstraps docker containers for test purposes, in our case it's Postgres. We use image postgres:11.6-alpine.
When the container starts, it allows to retrieve mapped port and right after that the connection is set up.
With Docker desktop it works just fine, but with colima the retry-with-interval workaround is required. Default logic was not expecting this, it was just working fine for years.

My assumption is that the logic that retrieves mapped port is not blocked by startup await, while in Docker desktop there is a strong guarantee about it.

I've created a demo project that shows the issue.
If you start with Docker Desktop, you will see log:

...testcontainers initialization without issues...
...
jdbc:postgresql://localhost:55001/test?loggerLevel=OFF
>>>> Successfully first time

If you start the same test with Colima, you will see log:

...testcontainers initialization with many retry failures (bootstraps service Ryuk container first)
...
jdbc:postgresql://localhost:49154/test?loggerLevel=OFF
>>>> First exception: org.postgresql.util.PSQLException: Connection to localhost:49154 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.
...sleep here...
>>>> Successfully second time

The mapped port is obtained in internal logic in this line:

String jdbcUrl = container.getJdbcUrl();

Worth to mention, that on Apple M1 this failure is more explicit (probably because it's faster), with Intel I see only testcontainers Ryuk failures (most probably they added this retry policy to cover the described issue), but still there is an obvious problem.

Let me know if I can provide more details or more convenient example (not sure that Java example is good enough for you).

@abiosoft

Hello. I found that in README there's notice that help wanted with testing on M1 Macs. I have MacBook Air M1 and just letting you know I'm happy to help with that! 😉

The colima stuff is working great as a Docker Desktop replacement with one minor exception for me. I've been unable to get it to autostart via launchd. I think that it is likely because the "start" command forks the hypervisor and then eventually exits. My understanding is that launchd expects the command to run indefinitely. I took a look at the code, but not conversant enough in Go to figure out how to "fix" this. Is this something that is on the roadmap?

Running a container image such as :

$ docker run -p 8081:8081 --name nexus3  sonatype/nexus3

Whilst I can connect to http://localhost:8081 I can't connect to http://192.168.175.10:8081. I noticed ssh is only bound to localhost -

$ lsof -i
ssh       43345 plord   36u  IPv4 0xcd9d306c9577097      0t0  TCP localhost:sunproxyadmin (LISTEN)

I would have expected that ssh is bound to all interfaces.

Using the docker.io apt package has the drawback that it is slower to update.

The official documentation describes how to install using the apt repository maintained by Docker. This repository is also updated with new releases as soon as they are published.

I can create a PR but I have very limited opportunity to test any changes to the code :-(

Suggestion

Add a parameter to specify the Linux distro (Centos, Fedora, Debian, ...) to be used as the default used is ubuntu and it seems that we cannot change it

Hi,

First, want to say this is an absolutely awesome project! I ran into this while looking for alternatives to Docker Desktop (like many others) and this has been very seamless to use after tweaking some of the mount options for the generated vm.

During the docker setup part of the start command, it looks like the VM is restarted after docker is installed, however at least on my setup, it looks like the VM is not actually stopped after the stop command returns, meaning the subsequent start command fails. That leaves the install in a weird state since the launch config/docker socket is not setup.

To fix this, I introduced the following bit of code. Happy to make a PR if you feel this would be useful.

	log waiting for VM to stop

	while [[ "$(limactl ls | tail -n +2 | grep "^$NAME " | awk '{print $2}')" != "Stopped" ]]; do
          sleep 1s
	done;

	log vm has stopped, restarting

That ensures that the VM has stopped prior to calling start. Everything worked great after I modified that.

Docker Desktop provides this to allow containers to connect to a service on the host.

lima provides host.lima.internal. It would be great to have colima maintain this compatibility.

In case if custom LIMA_HOME env variable is set up, the colima starting fails:

maxbook:~(:|✔) % echo $LIMA_HOME
/Users/morph/dev/lima
maxbook:~(:|✔) % colima start
INFO[0000] using docker runtime                         
INFO[0000] starting colima                              
INFO[0000] creating and starting ...                     context=vm
> msg="instance \"colima\" already exists (\"/Users/morph/dev/lima/colima\")"
FATA[0000] error starting vm: error at 'creating and starting': exit status 1 

a bit more details may be found here: #60

Reason to customize the variable: faster filesystem on non-default path

When we mount a directory under the user directory to the docker container, and at the same time set the container to start automatically; the second time colima starts up, a mount error will occur.

Error log:

~ ❯❯❯ colima start
INFO[0000] using docker runtime
INFO[0000] starting colima
INFO[0000] starting ...                                  context=vm
> msg="[hostagent] The essential requirement 4 of 5 is satisfied"
> msg="[hostagent] Waiting for the essential requirement 5 of 5: \"the guest agent to be running\""
> msg="[hostagent] The essential requirement 5 of 5 is satisfied"
> msg="[hostagent] Mounting \"/Users/xxxxx\""
> msg="[hostagent] fuse: mountpoint is not empty"
> msg="[hostagent] fuse: if you are sure this is safe, use the 'nonempty' mount option"

INFO[0063] provisioning ...                              context=docker
FATA[0063] error provisioning docker: error at 'provisioning': error copying deamon.json: exit status 1

Analysis of the cause of the error:

• 1. Use docker compose to run a container with local dir mounts
• 2. Restart colima (colima stop && colima start)
• 3. The docker in the VM is automatically started by default, and then the container in compose is started
• 4. Docker Compose will automatically create a mount directory that does not exist
• 5. Lima tries to mount via sshfs, and the mount fails because the directory is not empty(Compose has created the mount directory)
• 6. colima tried to copy daemon.json in the mount directory, but the copy failed

docker-compose.yaml

version: '3.8'
services:
  caddy:
    image: mritd/caddy
    container_name: caddy
    restart: always
    volumes:
      - ./conf:/etc/caddy
    ports:
      - "1234:1234"

I'm not sure if I describe it clearly. I temporarily turn off the VM internal docker to automatically start to solve this problem (systemctl disable docker); does anyone else have a better solution?