Minikube: Minikube 0.28.0 uses 9p instead of vboxfs for mounts

[jim-barber-he]

Is this a BUG REPORT or FEATURE REQUEST?: BUG REPORT

Environment:

Minikube version: v0.28.0

• OS: Debian GNU/Linux
• VM Driver: virtualbox
• ISO version: minikube-v0.28.0.iso

The virtualbox package installed is: 5.2.10-dfsg-6 amd64

What happened:

I set up a new cluster using Minikube 0.28.0
We rely on the OS home area to be mounted into the Minikube VM so that we can present mounts to the containers that map to directories on the developer's local PCs.

This works as expected when using Minikube version 0.27.0

Unfortunately I can't use the --mount --mount-string options for the minikube start command as an alternative because that mount uses the 9p file system which has been unreliable/buggy for us.
The vboxfs filesystem that used to be mounted by default worked flawlessly.

What you expected to happen:

The /hosthome path in the Minikube VM should exist and have /home on the local Linux PC mounted into it.

How to reproduce it (as minimally and precisely as possible):

You'll see there is no /hosthome directory or mount when running the following commands on a Linux system:

Run: minikube start
Run: minikube ssh 'ls -l /'
Run: minikube ssh 'mount | grep vboxfs'

[jim-barber-he]

This also happens for Mac.
The /Users directory is no longer mounted to /Users on the Minikube VM in version 0.28.0

[kbernst30]

I just noticed this as well. This has broken some of our local development environments as we can no longer mount source code for some development.

I can mitigate the problem temporarily by using --mount but this seems like breaking behaviour to me as the documentation still says that /Users on OS X should be mounted when using VirtualBox

https://kubernetes.io/docs/setup/minikube/#mounted-host-folders

[dlorenc]

Hey,

It looks like there's probably an issue with the vboxfs support in the new ISO build (there were some kernel changes). We'll take a look at this.

[ye]

Confirmed that this also affects Mac build. Last minikube version v0.27.0 works fine, switch the binary without any other changes will make my environment work again.

[yujiorama]

Same situation was happened for Windows build since v0.27.0.
The minikube-iso didn't contain vboxsf kernel module.

[dlorenc]

Yeah it looks like in the new version of the linux kernel this module is supposed to be included directly as a driver/module. I've been debugging but haven't been able to get anything working with 4.16 yet.

[Marlinc]

I'm also running into this issue, filesystem access using the 9p is way too slow for my use case

[ijl]

It appears different mount args are needed, from https://github.com/hashicorp/vagrant/issues/9709.

diff --git a/deploy/iso/minikube-iso/package/automount/minikube-automount b/deploy/iso/minikube-iso/package/automount/minikube-automount
index 7d1d4103e..7380aeaa9 100755
--- a/deploy/iso/minikube-iso/package/automount/minikube-automount
+++ b/deploy/iso/minikube-iso/package/automount/minikube-automount
@@ -215,7 +215,7 @@ if modprobe vboxguest &> /dev/null && modprobe vboxsf &> /dev/null; then
                dir="/${dir#/}"
                mkdir -p "$dir" 2>/dev/null
-               if ! mount -t vboxsf -o "$mountOptions" "$name" "$dir" 2>/dev/null; then
+               if ! mount -cit vboxsf -o "$mountOptions" "$name" "$dir" 2>/dev/null; then
                        rmdir "$dir" 2>/dev/null || true
                        while [ "$(dirname "$dir")" != "$dir" ]; do
                                dir="$(dirname "$dir")"

[tstromberg]

I believe this was fixed in 0.28.1. Please re-open if you are still experiencing it.