Note

Due to the numerous changes, it is recommended to delete existing VMs before upgrading.

Updates

Application

• Configuration folder structure has been changed to reduce clutter in user's home directory. All config now resides at ~/.colima with subfolders for different profiles.
• Support for changing container runtimes of existing VMs.
• Support for configuration file as an alternative to cli flags.
• Added runtime and ip address to output of list command.
• New --cpu-type flag for custom qemu cpu type. Fixes #248
• New --edit flag to customize configuration on startup.
• New template command for default configurations. Fixes #242

Kubernetes (k3s)

• Update to v1.23.6+k3s1
• New --kubernetes-ingress flag to toggle traefik. Fixes #133
• Support for configurable k3s version. Fixes #46
• Support for changing k3s version and container runtime without losing workload.
• Ensure successful startup before updating kubeconfig. Fixes #188

Network

• New --network-address and --network-driver flags to enable reachable IP address and configurable network driver respectively. Fixes #239
• Added gvproxy as a network driver option. colima start --network-driver gvproxy.
• Use of CoreDNS for more flexibility.

Docker

• Restart is no longer required during provision. Fixes #224, #196
• Docker daemon configuration moved to config file. Fixes #225
• Docker socket path is now included in the output of colima status for docker runtimes.

Containerd

• Update to v0.19.0

Volumes

• Support for 9p volumes (requires Lima v0.10.0). Fixes #192, #102, #83, #65, #54.
• New --mount-type flag for specifying volume driver. Defaults to 9p for Lima v0.10.0 and above.

Network breaks in containers when they start multiple network connections at the same time.

I noticed this behaviour e.g. during downloading Python dependencies. When multiple packages are downloaded at the same time I start getting Network is unreachable error. Then when I login to the underlying QEMU machine (limactl shell colima) I can see that it can't reach any network address. I cannot even ping 8.8.8.8. My host computer doesn't have any connection issues.

It gets better after few moments of inactivity. Restarting QEMU machine (colima stop && colima start) fixes the network, but the problem comes back when I increase the network load.

This is a problem that I can consistently reproduce. I created a minimum setup to demonstrate it: https://github.com/mjkonarski-b/colima-poc

I experience that problem on multiple Macbooks, so it doesn't seem to be related to any particular processor or macOS version:

• MBP 2021 M1 Pro with 12.1 Monterey
• MBP 2019 i7 with 12.1 Monterey
• MBP 2019 i7 with 11.5.2 BigSur

$ colima version
colima version 0.3.2
git commit: 272db4732b90390232ed9bdba955877f46a50552

runtime: docker
arch: aarch64
client: v20.10.11
server: v20.10.11


$ limactl --version
limactl version 0.8.1


$ qemu-img --version
qemu-img version 6.2.0
Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers

Device: M1 Macbook 2020 OS: Monterey Colima info:

colima version 0.3.4
git commit: 5a4a70481ca8d1e794677f22524e3c1b79a9b4ae

runtime: docker
arch: aarch64
client: v20.10.13
server: v20.10.11

Colima setup steps taken:

1) brew install colima
2) brew install docker
3) colima start

I am unable to access/resolve external IPs from inside any docker container built with colima. This prevents me from building images properly as required files cannot be installed. A simple example I did to carry verify networking wasn't working correctly:

1) docker run -ti ubuntu:latest /bin/bash
2) apt install iputils-ping
3) ping google.com

PING google.com (216.58.212.238) 56(84) bytes of data.
^C
--- google.com ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8027ms

Error I am seeing when building one of our actual images that requires installation of some files from a remote IP address:

#17 13.84       connect ENETUNREACH [redacted IP address] : 443

Is there something I am missing / not doing correctly? I tried running the docker build command with --network=host, but didn't help either?

Describe the Issue

The DNS resolver inside the Colima VM does not work and I thus have no internet connection at all.

Everything works with Colima 0.3.4 / limactl 0.11.0 / qemu 7.0.0.

Version

Colima Version:

What is the output of colima version 0.4.2

Lima Version:

What is the output of limactl --version 0.11.0

Qemu Version

What is the output of qemu-img --version 7.0.0

Operating System

• [ ] macOS Intel
• [x] macOS m1 12.4
• [ ] Linux

To Reproduce

Steps to reproduce the behavior:

1. docker pull node:16-alpine -> Error response from daemon: Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io on 192.168.107.1:53: read udp 192.168.5.15:40660->192.168.107.1:53: i/o timeout
2. colima ssh
3. ping google.com -> bad address 'google.com'

Expected behavior

DNS resolver and internet connections work.

Additional context

Edit: I use the nix package manager to install colima.

Content of /etc/resolv.conf: nameserver 192.168.107.1

Starting Colima with colima start --dns 1.1.1.1 solves the dns resolution problem and connections work again but VPN does not. On 0.3.4 VPN connections work perfectly.

Updated colima from 0.3.4 to 0.4.1. Did colima delete and colima start (colima start --arch amd --cpu 4 --memory 4 to be precise). Got

FATA[0642] error starting vm: error at 'creating and starting': exit status 1

Here is log after starting: serial.log

macOS version 12.3.1 CPU Apple M1 Max colima version 0.4.1 lima version 0.10.0 qemu version 6.2.0_1

@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! 😉

Is it possible to skip ssl check? We are using antivirus with MITM ssl certificate.

colima start --cpu 6 --memory 8 --disk 60 | more
INFO[0000] starting colima                              
INFO[0000] starting ...                                  context=vm
time="2022-01-18T13:17:29+01:00" level=info msg="Using the existing instance \"colima\""
time="2022-01-18T13:17:29+01:00" level=info msg="Attempting to download the image from \"https://github.com/abiosoft/alpine-lima/releases/download/colima-v0.3.2/alpine-lima-clm-3.14.3-x86_64.iso\"" digest="sha512:875482176ff2f43bf9472f84137d8b9a56d692ae19243436079c7f2f78cb6b13576601eef9102aaea796629215fc60308e69b590c81fe4139e9e84f1ec4a57f5"
time="2022-01-18T13:17:29+01:00" level=fatal msg="failed to download the image, attempted 2 candidates, errors=[unsupported arch: \"aarch64\" failed to download \"https://github.com/abiosoft/alpine-lima/releases/download/colima-v0.3.2/alpine-lima-clm-3.14.3-x86_64.iso\": Get \"https://objects.githubusercontent.com/github-production-release-asset-2e65be/422815134/912100a2-63cc-4bb2-ac99-e0940a5af5f5?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20220118%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20220118T121636Z&X-Amz-Expires=300&X-Amz-Signature=3d7b0a81026ed973ff0a64b8d9141f6104dcc775c35d2300dffc4c1283379e6d&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=422815134&response-content-disposition=attachment%3B%20filename%3Dalpine-lima-clm-3.14.3-x86_64.iso&response-content-type=application%2Foctet-stream\": x509: certificate signed by unknown authority]"
FATA[0000] error starting vm: error at 'starting': exit status 1 

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.

Description

Running colima start on a fresh install fails with the following log:

INFO[0000] starting colima
INFO[0000] runtime: docker
INFO[0000] preparing network ...                         context=vm
INFO[0000] creating and starting ...                     context=vm
INFO[0023] provisioning ...                              context=docker
FATA[0024] error provisioning docker: signal: killed

Version

Colima Version: 0.4.4 Lima Version: 0.11.2 Qemu Version: 7.0.0

Operating System

• [ ] macOS Intel
• [X] macOS M1
• [ ] Linux

Reproduction Steps

1. Install colima
2. Run colima start

Expected behaviour

colima should start without errors

Additional context

colima starts correctly when using the containerd runtime and works as expected. It seems to be an issue only with the docker runtime

From serial.log it seems to have stopped at

Welcome to Alpine Linux 3.14
^MKernel 5.10.109-0-virt on an aarch64 (/dev/ttyAMA0)

^Mcolima login:

PHP code running inside a container in some cases fails to access files from outside the container.

This is a local development setup with a volume mounted to the php container from outside (ie. it is shared between the container and host).

Steps to reproduce

Save the following as test.php:

<?php
$dir = new RecursiveDirectoryIterator(__DIR__);
$iterator = new RecursiveIteratorIterator($dir);
$iterator->setMaxDepth(0);
$files = iterator_to_array($iterator);
echo "Number of files: ".count($files).PHP_EOL;

Running php test.php outside Docker correctly prints out the number of files in the directory: e.g. Number of files: 12 Running it inside a container (ie. with docker exec) prints out Number of files: 0

Here is a one-liner to test it with (after creating test.php)

docker run -it --rm --name my-running-script -v "$PWD":/usr/src/myapp -w /usr/src/myapp php:7.4-cli php test.php

(Should never print Number of files: 0 because the directory contains at least the test.php file itself)

Description

Few days ago Lima 0.14 was released. since no extra steps were required in the changelog (except the support of virtiofs) i was adventurous and update lima to 0.14. i am using colima with the docker runtime to run DDEV in. I am using homebrew and therefore did a brew upgrade lima. colima started without a complaint after that. the odd part when starting a project in ddev the first time i got.

$> ddev start
Network ddev_default created 
Starting projectbrowser... 
v1.21.4: Pulling from drud/ddev-webserver
1ef0eb6dda52: Pull complete 
Digest: sha256:6a2e66d09a166e36179311f92a8ae0e8baa4fbed43fadf31be3c62995ead98cb
Status: Downloaded newer image for drud/ddev-webserver:v1.21.4
docker.io/drud/ddev-webserver:v1.21.4
stable: Pulling from library/busybox
b2bcf7a3443b: Pull complete 
Digest: sha256:3b3128d9df6bbbcc92e2358e596c9fbd722a437a62bafbc51607970e9e3b8869
Status: Downloaded newer image for busybox:stable
docker.io/library/busybox:stable
v1.21.4: Pulling from drud/ddev-ssh-agent
6064e7e5b6af: Pull complete 
bf273825688f: Pull complete 
7c56dd07c5c1: Pull complete 
4f4fb700ef54: Pull complete 
0e79da486cab: Pull complete 
b9227daed8ed: Pull complete 

all images got downloaded again. and that part in the startup output struck my eye:

Your docker install has only 2136836 available disk space, less than 5000000 warning level (48% used). Please increase disk image size. 
Volume "ddev-ssh-agent_dot_ssh"  Created 
Volume "ddev-ssh-agent_socket_dir"  Created 
Container ddev-ssh-agent  Started 

i've checked if there is a new docker context created maybe but no:

$> docker context ls
NAME       DESCRIPTION                               DOCKER ENDPOINT                                     KUBERNETES ENDPOINT   ORCHESTRATOR
colima *   colima                                    unix:///Users/rkoller/.colima/default/docker.sock                         
default    Current DOCKER_HOST based configuration   unix:///var/run/docker.sock                                               swarm

so all the containers, images and volumes are gone. but the odd detail is the following. according to:

$> docker system df   
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          10        5         2.433GB   1.996GB (82%)
Containers      5         5         54.38MB   0B (0%)
Local Volumes   7         5         420.2MB   0B (0%)
Build Cache     52        0         2.116kB   2.116kB

all the images, containers, volumes and caches have approximately 5gb all together. powered off ddev and restarted a project and the available disk space warning still exists:

$> ddev start
Network ddev_default created 
Starting projectbrowser... 
Your docker install has only 544552 available disk space, less than 5000000 warning level (87% used). Please increase disk image size. 

so not sure if the old containers/images and so on are still in place but unavailable or if something else went wrong as well.

Version

Colima Version:

$> colima version
colima version 0.4.6
git commit: 10377f3a20c2b0f7196ad5944264b69f048a3d40

runtime: docker
arch: aarch64
client: v20.10.21
server: v20.10.11

Lima Version:

$> limactl --version
limactl version 0.14.0

Qemu Version: $> qemu-img --version qemu-img version 7.1.0 Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers

I've installed colima via homebrew on a mbp (m1pro)

Operating System

• [ ] macOS Intel
• [X] macOS M1
• [ ] Linux

Reproduction Steps

1. upgrade lima to 0.14

p.s. @rfay tested upgrading to lima 0.14 with colima HEAD and he confirms, same outcome.

Expected behaviour

No response

Additional context

No response

Description

I installed latest Colima with Brew. When ever I start Colima and then run some containers listening :80 and :443 ports all domains which point to 12.7.0.0.1 (example foobar.traefik.me) will fail. Also when switching back to Docker Desktop.

Currently only way I get current active system (Colima or Docker) working is rebooting macOS.

Version

Colima Version: 0.5.2 Lima Version: 0.14.2 Qemu Version: 7.2.0

Operating System

• [ ] macOS Intel <= 12 (Monterrey)
• [ ] macOS Intel >= 13 (Ventura)
• [ ] macOS M1 <= 12 (Monterrey)
• [X] macOS M1 >= 13 (Ventura)
• [ ] Linux

Output of colima status

I tried vm-types: vz and qemu Add dnsses --dns=8.8.8.8 --dns=1.1.1.1 Tried mount types: virtiofs and sshfs

Reproduction Steps

1. Install Colima
2. Start colima
3. Run containers which listen 80 and 443 port
4. Have some domain pointing to 127.0.0.1
5. Switch back to Docker Desktop
6. Repeat steps 3 and 4

Expected behaviour

Container responsing to e.g. http://foobar.traefik.me or https://foobar.traefik.me should give response.

Additional context

No response

Description

I've spent a lot of time to understand that to make it work with ports I need to run:

colima start --network-address   # to enable ports visibility
colima list    # to see the vm host ip

I understand that it's partially my fault. But there's also a capacity to make a tool more intuitive and save lots of time as humanity has other things to do right now.

I suggest we make it to display huge red banner saying something like that

.-----------------------------------------------------------------------------.
| Please be aware that you'll need to access this IP _________, not locahost! |
'-----------------------------------------------------------------------------'

And if it's not being run with --network-address, I suggest displaying:

.-------------------------------------------------------------------------------------------------.
| Attention! Ports are not visible from your PC!. Use "colima start --network-address" to enable. |
'-------------------------------------------------------------------------------------------------'

Description

Running colima start --vm-type=vz fails to start:

$ colima start --vm-type=vz --very-verbose
TRAC[0000] cmd ["limactl" "info"]                       
TRAC[0000] cmd ["limactl" "list" "colima" "--json"]     
INFO[0000] starting colima                              
INFO[0000] runtime: docker                              
TRAC[0000] cmd ["limactl" "list" "colima" "--json"]     
TRAC[0000] cmd ["pgrep" "oahd"]                         
INFO[0000] starting ...                                  context=vm
TRAC[0000] cmd ["limactl" "start" "colima"]             
> "Non-strict YAML is deprecated and will be unsupported in a future version of Lima" comment="main file \"/Users/jonathan/.lima/colima/lima.yaml\"" error="[80:1] unknown field \"rosetta\"\n      77 |       script: readlink /sbin/fstrim || fstrim -a\n      78 |     - mode: system\n      79 |       script: stat /sys/class/block/vda/queue/write_cache && echo 'write through' > /sys/class/block/vda/queue/write_cache\n    > 80 | rosetta:\n           ^\n      81 |     enabled: true\n      82 |     binfmt: true"
> Using the existing instance "colima"
> errors inspecting instance: [field `mountType` must be "reverse-sshfs" or "9p" , got "virtiofs"]
FATA[0000] error starting vm: error at 'starting': exit status 1 

However colima start works as expected. When installed through Homebrew it works (see additional context).

Version

Colima Version:

colima version 0.5.2
git commit: 6b5b6fe

Lima Version: limactl version 0.13.0 Qemu Version: qemu-img version 7.2.0

Nixpkgs: https://github.com/NixOS/nixpkgs/blob/2d1dee4f6a6dac81b3bc4a3e7bdf76c9e5ec4008/pkgs/applications/virtualization/colima/default.nix

Operating System

• [ ] macOS Intel <= 12 (Monterrey)
• [ ] macOS Intel >= 13 (Ventura)
• [ ] macOS M1 <= 12 (Monterrey)
• [X] macOS M1 >= 13 (Ventura)
• [ ] Linux

Output of colima status

FATA[0000] colima is not running

Reproduction Steps

1. nix-shell -p colima -p qemu -p lima -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/2d1dee4f6a6dac81b3bc4a3e7bdf76c9e5ec4008.tar.gz
2. colima delete (only if you've already run colima before with different settings)
3. colima start --vm-type=vz

Expected behaviour

VM should start.

Additional context

When installed with Homebrew:

Colima Version:

colima version 0.5.2
git commit: 6b5b6fe0540e708f0c9d6e8919fab292c671fc72

Lima Version: limactl version 0.14.2 Qemu Version: qemu-img version 7.2.0

$ colima start --vm-type=vz --verbose
INFO[0000] starting colima                              
INFO[0000] runtime: docker                              
INFO[0000] creating and starting ...                     context=vm
> Terminal is not available, proceeding without opening an editor
> "Attempting to download the image from \"https://github.com/abiosoft/alpine-lima/releases/download/colima-v0.5.0-2/alpine-lima-clm-3.16.2-aarch64.iso\"" digest="sha512:06abfa8c9fd954f8bfe4ce226bf282dd06e9dfbcd09f57566bf6c20809beb5a3367415b515e0a65d6a1638ecfd3a3bb3fb6d654dee3d72164bd0279370448507"
> Using cache "/Users/jonathan/Library/Caches/lima/download/by-url-sha256/c37acb6308026b2fe12f6c0ef3371f690b3e33ee6b5d37d5dc68684f8fd5ee52/data"
> [hostagent] Starting VZ (hint: to watch the boot progress, see "/Users/jonathan/.lima/colima/serial.log")
> [hostagent] Setting up Rosetta share
> SSH Local Port: 58153
> [hostagent] new connection from  to 
> [hostagent] Waiting for the essential requirement 1 of 3: "ssh"
> [hostagent] [VZ] - vm state change: running
> [hostagent] 2023/01/03 14:31:22 tcpproxy: for incoming conn 127.0.0.1:58155, error dialing "192.168.5.15:22": connect tcp 192.168.5.15:22: no route
> [hostagent] Waiting for the essential requirement 1 of 3: "ssh"
> [hostagent] The essential requirement 1 of 3 is satisfied
> [hostagent] Waiting for the essential requirement 2 of 3: "user session is ready for ssh"
> [hostagent] The essential requirement 2 of 3 is satisfied
> [hostagent] Waiting for the essential requirement 3 of 3: "the guest agent to be running"
> [hostagent] The essential requirement 3 of 3 is satisfied
> [hostagent] Waiting for the final requirement 1 of 1: "boot scripts must have finished"
> [hostagent] Forwarding "/var/run/docker.sock" (guest) to "/Users/jonathan/.colima/default/docker.sock" (host)
> [hostagent] Forwarding "/var/run/docker.sock" (guest) to "/Users/jonathan/.colima/docker.sock" (host)
> [hostagent] The final requirement 1 of 1 is satisfied
> READY. Run `limactl shell colima` to open the shell.
> stat: can't stat '/proc/sys/fs/binfmt_misc/rosetta': No such file or directory
>   File: /proc/sys/fs/binfmt_misc/qemu-x86_64
>   Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
> Device: 31h/49d	Inode: 9550        Links: 1
> Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
> Access: 2023-01-03 14:31:30.300000001 +0000
> Modify: 2023-01-03 14:31:30.300000001 +0000
> Change: 2023-01-03 14:31:30.300000001 +0000
INFO[0014] provisioning ...                              context=docker
> colima
> Successfully created context "colima"
> colima
INFO[0014] starting ...                                  context=docker
>  * /var/log/docker.log: creating file
>  * /var/log/docker.log: correcting owner
>  * Starting Docker Daemon ... [ ok ]
INFO[0019] done

Description

Shortly after starting a colima instance it seem to hang, and I’m unable to ssh into the session

% colima -v start -t vz -c 8 -m 8 --mount /Volumes/Void:w --mount-type virtiofs --mount /Volumes/Stash:w --mount-type virtiofs --mount /Volumes/Vacuum:w --mount-type virtiofs

% colima list
PROFILE    STATUS     ARCH       CPUS    MEMORY    DISK     RUNTIME    ADDRESS
default    Running    aarch64    8       8GiB      60GiB    docker     

# Roughly 5~10 minutes later
% colima ssh
FATA[0006] exit status 255

From ~/.lima/colima/ha.stderr.log I see:

{"level":"error","msg":"write unixgram -\u003e: write: no buffer space available","time":"2022-12-30T11:24:42-08:00"}
{"level":"error","msg":"cannot receive packets from , disconnecting: cannot read size from socket: read unixgram -\u003e: use of closed network connection","time":"2022-12-30T11:24:42-08:00"}{"level":"error","msg":"virtual network error: \"cannot read size from socket: read unixgram -\u003e: use of closed network connection\"","time":"2022-12-30T11:24:42-08:00"}

• [ ]

Version

Colima Version:

colima version HEAD-88390f5
git commit: 88390f54bceb72e248044aa3b452b64c676d99d1

Lima Version: limactl version 0.14.2 Qemu Version: qemu-img version 7.2.0 macOS Version: 13.1 22C65

Operating System

• [ ] macOS Intel <= 12 (Monterrey)
• [ ] macOS Intel >= 13 (Ventura)
• [ ] macOS M1 <= 12 (Monterrey)
• [X] macOS M1 >= 13 (Ventura)
• [ ] Linux

Output of colima status

% colima status
FATA[0003] error retrieving current runtime: empty value

vm-type: vz mount type: virtiofs

Reproduction Steps

1. Start Colima
2. 3 Docker containers start
3. Wait about 5-10 minutes

Expected behaviour

No response

Additional context

No response

Description

Running Colima 0.5.1/0.5.2 with vz/VirtioFS I've seen a number of SEGFAULTS in these situations:

• Running ddev start:

+ cp -r /mnt/ddev_config/nginx_full /etc/nginx/sites-enabled/
/start.sh: line 43:    13 Segmentation fault      cp -r /mnt/ddev_config/nginx_full /etc/nginx/sites-enabled/

• Attempting to colima ssh and sudo -s

Version

Colima Version: 0.5.2 Lima Version: 0.14.2 Qemu Version:

Operating System

• [ ] macOS Intel <= 12 (Monterrey)
• [ ] macOS Intel >= 13 (Ventura)
• [ ] macOS M1 <= 12 (Monterrey)
• [X] macOS M1 >= 13 (Ventura)
• [ ] Linux

Output of colima status

$ colima status -p vz-virt INFO[0000] colima [profile=vz-virt] is running using macOS Virtualization.Framework INFO[0000] arch: aarch64 INFO[0000] runtime: docker INFO[0000] mountType: virtiofs INFO[0000] socket: unix:///Users/rfay/.colima/vz-virt/docker.sock

Reproduction Steps

I don't think I've been able to get consistent results

Expected behaviour

No SEGV

Additional context

No response

Description

Hey, We have couple of usages for running colima, for example:

1. starting colima without mounts - exact command: colima start --memory 6 --cpu 4
2. starting colima with mounts - exact command: colima start --memory 6 --cpu 4 --mount $HOME/a_project_directory:/a_path_in_container:w --mount-type 9p

The bug: Cant set a mount if sometime previously I started colima without a mount. Must use colima delete which clear a lot of cached resources.

An ls command output after the second start (with mount): colima:/$ ls -la

total 16 drwxr-xr-x 21 root root 420 Dec 28 08:03 . drwxr-xr-x 21 root root 420 Dec 28 08:03 .. drwxr-xr-x 3 root root 30 Dec 14 18:17 .modloop drwxr-xr-x 3 root root 60 Dec 28 08:03 Users drwxr-xr-x 2 root root 1840 Dec 28 08:03 bin drwxr-xr-x 14 root root 2800 Dec 28 08:03 dev drwxr-xr-x 31 root root 4096 Dec 28 08:03 etc drwxr-xr-x 3 root root 4096 Dec 28 08:02 home drwxr-xr-x 10 root root 1040 Dec 28 08:03 lib drwxr-xr-x 6 root root 120 Dec 28 08:03 media drwxr-xr-x 4 root root 80 Dec 28 08:03 mnt drwxr-xr-x 3 root root 60 Dec 28 08:03 opt dr-xr-xr-x 170 root root 0 Dec 28 08:03 proc drwx------ 2 root root 4096 Dec 28 08:01 root drwxr-xr-x 7 root root 500 Dec 28 08:03 run drwxr-xr-x 2 root root 3320 Dec 28 08:03 sbin drwxr-xr-x 2 root root 40 Dec 28 08:03 srv dr-xr-xr-x 13 root root 0 Dec 28 08:03 sys drwxrwxrwt 5 root root 4096 Dec 28 08:02 tmp drwxr-xr-x 8 root root 160 Dec 28 08:03 usr drwxr-xr-x 13 root root 300 Dec 28 08:03 var

Version

Colima Version: 0.5.1 Lima Version: 0.14.2 Qemu Version: 7.2.0

Operating System

• [X] macOS Intel <= 12 (Monterrey)
• [ ] macOS Intel >= 13 (Ventura)
• [ ] macOS M1 <= 12 (Monterrey)
• [ ] macOS M1 >= 13 (Ventura)
• [ ] Linux

Output of colima status

First run - colima start --memory 6 --cpu 4:

INFO[0000] colima is running using QEMU INFO[0000] arch: x86_64 INFO[0000] runtime: docker INFO[0000] socket: unix:///Users/royno/.colima/default/docker.sock

Second run (after colima stop, without delete):

INFO[0000] colima is running using QEMU INFO[0000] arch: x86_64 INFO[0000] runtime: docker INFO[0000] mountType: 9p INFO[0000] socket: unix:///Users/royno/.colima/default/docker.sock

Reproduction Steps

1. start without mount (colima start --memory 6 --cpu 4)
2. stop colima - colima stop
3. start with mount colima start --memory 6 --cpu 4 --mount $HOME/a_project_directory:/a_path_in_container:w --mount-type 9p

Expected behaviour

The expected behavior is having the new mounted directory instead of the default (/Users/)

Additional context

This can only be solved by running colima delete.

One more thing that might be related: Its true to any 2 different mounts (here the first one is just the default one)