-
-
Notifications
You must be signed in to change notification settings - Fork 378
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mount using -v does not work #503
Comments
Is that not supposed to be |
I am seeing the same issue with volume mounting directories - both using |
Having the same issue when trying the 0.5.0 release this morning. I'm mounting a directory with
This only happens when using |
Also exactly the same problem happens with macOS Intel. |
Do you get same behaviour when you use a separate profile? # create a separate instance named 'test'
colima start test |
I tried to delete |
I was able to resolve the issue by using a different mount provider:
|
Like @sergeybe2, I deleted |
It's probably be because the default mount type on Colima is |
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 |
I just tried |
Yeah, I tried setting the mount type in the template to Nevertheless at least a error message would be awesome |
Like others, delete |
I think the issue described above is due to an empty 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
Therefore, a workaround for some of the comments in this issue might be to set the Thanks, @rfay, for helping me figure this out. -mike |
Hey, I just changed the mountType to |
@ultimike 's guide with restarting colima works really well! |
Thanks a lot @ultimike!! |
@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. |
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" :) |
I also had this issue with colima version 0.5.2. |
Working on a recreation scenario for this. It results in
(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 |
Spun the validation issues off into |
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-( |
@icepic were you trying to mount a directory outside of |
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. |
@abiosoft I can't tell you how many DDEV users have been broken upgrading colima and resulting in a non-mounting project because |
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: |
@icepic the commit is already in there to complain about empty mountType. |
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. |
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 |
Same issue but not caused by upgrade, it worked fine then stopped without any obvious reasons: (MacOS 13.2.1)
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 |
I am facing the same issue on macOS 13.4.1 (Intel). I switched to
However, I have found this only affects mounts outside my home directory, specifically for me on a different volume. E.g. Works:
Doesn't work:
I suspect this is a macOS sandboxing issue of some kind, but not sure how to resolve. |
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 |
Resolved this by running |
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 I tried stopping, editing the file and starting. Then I tried starting with |
For whatever it's worth, I also can't change mounts after the VM is created without deleting the VM. I'm using |
I have gone through all of these comments, trying various options and remedies to no avail. With |
@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".
Then when starting docker container, make sure PUID/PGID match the user and group on the mounted (ie archive):
|
Simply adding
To my config file was sufficient for me |
Description
I am running Colima in this way:
And then I tried this one:
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
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
The text was updated successfully, but these errors were encountered: