Introduction

When you run Minikube in a VM-based or container-based local cluster, the Kubernetes node does not automatically see your host filesystem. The usual solution is to mount a host directory into Minikube and then expose that mounted path to pods with a hostPath volume.

Use minikube mount

The most direct command is:

minikube mount /path/on/host:/mnt/data

This tells Minikube to make the host directory available inside the Minikube node at /mnt/data.

A few practical points matter immediately:

• the command usually stays running while the mount is active
• the host path must exist before mounting
• after a Minikube restart, you typically need to start the mount again

So this is convenient for local development, but it is not a persistent cluster storage strategy.

Verify the Mount Inside Minikube

After starting the mount, check the node directly:

minikube ssh
ls /mnt/data

If the files are visible here, Minikube sees the host folder correctly. That is the right place to debug first before involving Kubernetes manifests.

Expose the Mounted Path to a Pod

Once the directory exists inside the Minikube node, a pod can consume it through a hostPath volume:

1apiVersion: v1
2kind: Pod
3metadata:
4  name: demo
5spec:
6  containers:
7    - name: app
8      image: busybox
9      command: ["sh", "-c", "ls /data && sleep 3600"]
10      volumeMounts:
11        - name: host-data
12          mountPath: /data
13  volumes:
14    - name: host-data
15      hostPath:
16        path: /mnt/data
17        type: Directory

Apply it with:

kubectl apply -f demo.yaml
kubectl logs demo

Now the pod sees the data through /data, but the actual files still originate from your host machine through the Minikube mount.

Driver and Development Workflow Notes

The exact mount behavior depends on the Minikube driver. With VM drivers, you are literally mounting into the VM. With some container-based setups, the path mapping behavior can feel different because the node itself is containerized.

That is why the two-step mental model helps:

1. host path into Minikube node
2. Minikube node path into pod

If step one fails, Kubernetes manifests will not rescue it.

It is also worth remembering that mount performance can differ from native filesystem access. Large live-reload workflows, databases, or file-heavy build caches may feel slower through a host mount than through ordinary local disk inside the node.

For quick experiments that need live host files, the tradeoff is usually worth it. For heavier local state, a normal persistent volume workflow inside Minikube can be more predictable and faster overall. Measure both approaches.

Common Pitfalls

One common mistake is trying to mount the host path directly into the pod manifest. The pod only sees node paths, so the host directory must first be visible inside Minikube.

Another issue is forgetting that minikube mount is often an active foreground process. If you stop the terminal or restart Minikube, the mount may disappear.

It is also easy to use this setup as if it were production-grade storage. hostPath plus minikube mount is mainly a local development convenience, not a portable persistent-volume strategy.

Summary

• Use minikube mount host_path:node_path to expose a host folder inside the Minikube node.
• Verify the node-side path with minikube ssh before debugging pod manifests.
• Use a hostPath volume to make the mounted node directory visible inside pods.
• Remember that the mount usually needs to be restarted after Minikube restarts.
• Treat this approach as a local development workflow, not a production storage design.