Mount using -v does not work

[lukas-hofstaetter]

Description

I am running Colima in this way:

brew install --HEAD lima
git clone https://github.com/abiosoft/colima.git && cd colima
git checkout support-vz
make build
sudo make install
colima start

And then I tried this one:

cd /User/edeviser/
docker run -it --rm -v /User/edeviser:/edeviser -w /edeviser ubuntu 
#inside container
ls

But the folder is empty. No Error Messages or warnings on screen.

Version

colima version v0.4.6-19-gf959232
git commit: f959232
limactl version HEAD-57beb9f
Qemu Version: Using Rosetta instead of qemu

Operating System

• macOS Intel
• macOS M1
• Linux

Reproduction Steps

See description.

Expected behaviour

The mounted folder inside the container should show the files.
When using docker desktop instead the mount using -v works pretty fine.

Additional context

No response

[abiosoft]

Is that not supposed to be /Users and not /User?

[jclausen]

I am seeing the same issue with volume mounting directories - both using docker run and compose. In this case all of the subdirectories are mounted but no files exist inside of the container - only the directories and nested directories.

[gpanders]

Having the same issue when trying the 0.5.0 release this morning. I'm mounting a directory with -v $HOME/src/my-project:/my-project, but /my-project in the container is empty. docker inspect confirms that the mount is created:

"Mounts": [
            {
                "Type": "bind",
                "Source": "/Users/ganders/src/my-project",
                "Destination": "/my-project",
                "Mode": "",
                "RW": true,
                "Propagation": "rprivate"
            },

This only happens when using -t vz. Using QEMU works as expected.

[sergeybe2]

Also exactly the same problem happens with macOS Intel.

[abiosoft]

Do you get same behaviour when you use a separate profile?

# create a separate instance named 'test'
colima start test

[sergeybe2]

I tried to delete ~/.colima and ~/.lima directories and I ran again colima start with my images I got correct mounted volumes.

[jclausen]

I was able to resolve the issue by using a different mount provider:

colima start --mount-type virtiofs --cpu 12 --memory 20 --disk 256

[gpanders]

Like @sergeybe2, I deleted ~/.colima and ~/.lima and I also manually specified --mount-type virtiofs in the start command per @jclausen's suggestion, and it appears to be working now. I'm not sure what fixed it.

[jclausen]

It's probably be because the default mount type on Colima is sshfs. Now that virtiofs is stable and available on the latest version of Docker for Mac, it should probably be made the default.

[abiosoft]

If it does not default to virtiofs when vz is used then it is a bug that should be fixed.

Did any of you set some defaults with colima template ?

[gpanders]

If it does not default to virtiofs when vz is used then it is a bug that should be fixed.

I just tried colima start test -t vz and colima status test does show mountType: virtiofs. So it was probably not necessary to manually specify --mount-type virtiofs.

[lukas-hofstaetter]

Did any of you set some defaults with colima template ?

Yeah, I tried setting the mount type in the template to virtio and now its working pretty fine.

Nevertheless at least a error message would be awesome

[tyage]

Like others, delete ~/.colima and colima delete works for me.

[ultimike]

I think the issue described above is due to an empty mountType in the colima.yaml profile.

I ran into the same issue on Mac OS X Monterey (12.6) while upgrading from a previous version of Colima (not exactly sure which one, but older than 0.5.0) to 0.5.1.

It seems that a previous version of Colima would assign a default mount type when the mountType parameter in the colima.yaml file was empty. With 0.5.1 (and possibly earlier), an empty mountType fails. This can be shown as follows:

1. Set your ~/.colima/default/colima.yaml file's mountType to "".

2. From a non-empty directory (create a temp directory with a dummy file or two), spin up a fresh container with: docker run -it --rm -v $PWD:/mnt/junk busybox sh

3. See that no files from the temp directory were mounted into the container.

4. Now, set your ~/.colima/default/colima.yaml file's mountType to sshfs.

5. From the same non-empty directory, again run: docker run -it --rm -v $PWD:/mnt/junk busybox sh

6. See that all the files from the temp directory were mounted into the container.

Therefore, a workaround for some of the comments in this issue might be to set the mountType to a non-empty value. A long-term solution might be for an empty mountType parameter to utilize a default value automatically.

Thanks, @rfay, for helping me figure this out.

-mike

[lukas-hofstaetter]

Hey, I just changed the mountType to virtiofs in the template. Now it works like a charm.

[ymin1103]

@ultimike 's guide with restarting colima works really well!

[tewfik-ghariani]

Thanks a lot @ultimike!!

[rfay]

@abiosoft I know you're working on a release; I hope a fix for this can get in there. It's affecting lots of people, not just the ones in this issue.

[abiosoft]

@abiosoft I know you're working on a release; I hope a fix for this can get in there. It's affecting lots of people, not just the ones in this issue.

I suspect this should already be fixed alongside #515 in v0.5.1 release.

[rfay]

This has been a constant problem for people running 0.5.1, sad to say. It's all folks who upgraded; new instances don't have the problem. It seems to be that previously an empty value for mountType meant "use the default", and now it seems to mean "Don't mount anything" :)

[rfmarcelino]

I also had this issue with colima version 0.5.2.
Restarting did the job but took some time until then.
Would it be possible to force the restart automatically or at least warn that a restart is required?

[rfay]

Working on a recreation scenario for this.
colima start junk --vm-type=qemu --mount-type="" - should that even be allowed?

It results in mountType: "" and

$ colima status -p junk
INFO[0000] colima [profile=junk] is running using QEMU
INFO[0000] arch: aarch64
INFO[0000] runtime: docker
INFO[0000] socket: unix:///Users/rfay/.colima/junk/docker.sock

(Note that the mountType is not reported there)

But the mountType ends up being 9p, so 9p seems to be the default still on 0.5.2?

But... Unable to recreate the problem described here using this technique.

Edit: I note that colima start j2 --mount-type="xxx" --vm-type=qemu does not raise an error, nor does colima start j3 --mount-type="xxx" --vm-type=xxx so I sure recommend that we validate those options to prevent unnecessary havoc.

[rfay]

Spun the validation issues off into

• Colima should validate vm-type and mount-type flags #548

[icepic]

I also ran into this "silent do nothing" with -v, the dir appears in the container, but it is not populated. Very frustrating since I thought it was docker acting up and not colima. 8-(
Same empty "" mount-type in the template / configs as others here.
MacOS Ventura 13.2

[abiosoft]

@icepic were you trying to mount a directory outside of $HOME?

[icepic]

No, it is a subdirectory of my home dir, with -v $PWD:/path-inside:z

[abiosoft]

No, it is a subdirectory of my home dir, with -v $PWD:/path-inside:z

I think this may happen if you changed mounts or mount type after the VM has been created.
Part of the reasons that ability to change mounts without resetting the VM may be removed in the next release.

[rfay]

@abiosoft I can't tell you how many DDEV users have been broken upgrading colima and resulting in a non-mounting project because mountType was empty from an earlier version. Many, many issues, many, many Discord sessions. I don't know what happened in upgrading to v0.5.* where and empty mountType used to work and now it results in just not mounting. But I wanted you to know that this has been a huge problem for many, many people.

[icepic]

Yes, having it silently not-mount is the issue here, not that config defaults have changed or whatever, people can handle it, but if it would print out:
"mount-type is currently empty so -w will not perform any mount, please set the mount-type in the config (filename used here) to one of the supported types x,y or z"
then people would know which file to look in, and what to look for.

[rfay]

@icepic the commit is already in there to complain about empty mountType.

[icepic]

And to be clear, I did as rfay above mentioned, "upgraded myself into this problem", and did an extra "brew upgrade colima" before reporting the "me too" on this issue, so if the next release has fixed this issue then it is good. Hopefully a new release can come out quickly so that not many more casual colima users like me fall into this trap.

[jansimak]

I had the same issue running the latest version of colima (0.5.2) and lima (0.14.2) available via homebrew and the only thing I had to do to fix the issue was to run the colima with --mount-type virtiofs. No deletion needed.

[Allsimon]

Same issue but not caused by upgrade, it worked fine then stopped without any obvious reasons: (MacOS 13.2.1)

colima version 0.5.4
git commit: feef4176f56a7dea487d43689317a9d7fe9de27e

runtime: docker
arch: aarch64
client: v23.0.1
server: v20.10.20

rm -rf ~/.colima && colima delete && brew uninstall colima && brew install colima doesn't fix it

mountType is not empty:

➜ cat ~/.colima/default/colima.yaml | grep 'mountType:'
mountType: virtiofs

I tried to start colima with either:

colima start --cpu 4 --memory 4 --disk 10 --mount-type virtiofs --vm-type vz
colima start --cpu 4 --memory 4 --disk 10
colima start --cpu 4 --memory 4 --disk 10 --mount-type 9p

[Yanson]

I am facing the same issue on macOS 13.4.1 (Intel).

I switched to virtiofs with colima start --mount-type virtiofs --vm-type vz but it didn't help.

❯ colima status
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/me/.colima/default/docker.sock 

However, I have found this only affects mounts outside my home directory, specifically for me on a different volume.

E.g. Works:

docker run --rm -v $HOME:/stuff:ro busybox sh -c 'ls -lh /stuff'

Doesn't work:

docker run --rm -v /Applications:/stuff:ro busybox sh -c 'ls -lh /stuff'
docker run --rm -v /Volumes/space:/stuff:ro busybox sh -c 'ls -lh /stuff'

I suspect this is a macOS sandboxing issue of some kind, but not sure how to resolve.

[rfay]

If you read the colima.yaml you'll see that nothing but your home directory is mounted by default, but you can add other mounts. See also

• Give error on attempt to mount non-mounted mount #530

[Yanson]

If you read the colima.yaml you'll see that nothing but your home directory is mounted by default, but you can add other mounts. See also

• Give error on attempt to mount non-mounted mount #530

Resolved this by running colima delete and creating a new one with colima start --edit and adding the settings detailed in this comment: #515 (comment)

[rfay]

You actually didn't have to delete, but glad you have it working.

[Yanson]

You actually didn't have to delete, but glad you have it working.

I tried without the delete first and that didn't work. When I ran colima ssh and looked at mount and /etc/fstab (as suggested by the linked comment) the new /Volumes/space entry was not there.

I tried stopping, editing the file and starting. Then I tried starting with colima start --edit (in case that, in some way forced a reload of the config). Finally I tried delete and colima start --edit, and that worked.

[igor-petrik-invitae]

You actually didn't have to delete, but glad you have it working.

I tried without the delete first and that didn't work. When I ran colima ssh and looked at mount and /etc/fstab (as suggested by the linked comment) the new /Volumes/space entry was not there.

I tried stopping, editing the file and starting. Then I tried starting with colima start --edit (in case that, in some way forced a reload of the config). Finally I tried delete and colima start --edit, and that worked.

For whatever it's worth, I also can't change mounts after the VM is created without deleting the VM. I'm using virtiofs mount type.

[malthe]

I have gone through all of these comments, trying various options and remedies to no avail.

With virtiofs for example, what are the debugging steps to try in order to understand where things break? I'm trying to mount a folder within my home directory but the directory just shows up empty in the container.

[rovo79]

@malthe it's probably not necessary to uninstall Colima, but I did just to make sure I had a fresh start. That, combined with a few other comments throughout the issue que got it working for me. I wanted to mount a networked samba shared to my local Mac M1, "archive".

brew uninstall colima
rm -rf ~/.colima
rm -rf ~/.lima
brew install colima

colima start --vm-type vz --mount /Volumes/archive:w

Then when starting docker container, make sure PUID/PGID match the user and group on the mounted (ie archive):

docker run -ti \
  -v /Volumes/archive:/archive \
  --network="bridge" \
  -e PUID=1000 \
  -e PGID=1000 \

[EddieEldridge]

Simply adding

mounts:
  - location: /Users/eeldridge/src
    writable: true

To my config file was sufficient for me