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: f959232a2322e4b61217ecba0b92ef4618783cbf limactl version HEAD-57beb9f Qemu Version: Using Rosetta instead of qemu

Operating System

• [ ] macOS Intel
• [X] 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 https://github.com/abiosoft/colima/issues/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

• #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.