Closed evilhamsterman closed 1 year ago
This appears to be the same issue in #12537 and #11475. I'm not sure why the reporters closed those tickets when they found a workaround because this appears to still be an issue in the code. A workaround should not be required
Thank you @evilhamsterman for creating this issue, I agree with you this seems to be a bug that we should fix in the minikube code. do u verify that work arround works for you too ?
I am curious what makes your Mac OS different than others, that would require this work arround ?
I accept any PR that would fix this for everyone
CC: @spowelljr who recently touched the mount code and have more context than me
The workaround does work if I find the cluster ip range with minikube ip
for instance mine returns 172.16.48.4 so if I run the command minikube mount <mount> --ip 172.16.48.1
it will succeed. Without specifying IP it seems to default to 192.168.64.1 which appears to be the problem.
Just reporting that I have the same issue on MacOS Monterey with the beta release of minikube v1.24.0-beta.0
. I though at first this was related to https://github.com/kubernetes/minikube/issues/12675, but since this happens even with the default profile, this is not the case.
I mounted a volume /tmp/minikube-mount-test
using hyperkit driver to /test
, the target folder /test
exists but its empty. Interestingly, I see no error logs.
Also interestingly, every minikube mount
command fails. I've also tried setting the --ip
manually with both minikube ip
and my macOS IP (which is supposedly returned by ifconfig en0 | grep "inet\b" | awk '{ print $2 }'
according to https://github.com/kubernetes/minikube/issues/11475#issuecomment-924121462, but both fail.
The one below, using minikube ip
, fails almost immediately.
Hi @fernandrone, the reason the mount on start didn't output any errors is because errors are suppressed for mount on start unless -v=1
is passed. I tried using minikube v1.24.0-beta.0 on my machine and the mount worked fine. Are you using a firewall perhaps, or something that would block the port?
@spowelljr does it work for you if try also changing the IP as mentioned by @evilhamsterman in their comment?
With colima
, podman
, multipass
and a whole lot of hyperkit-based solutions around (to replace Docker Desktop, of course), it's happening to many to have multiple bridgeXXX
interfaces on macOS. minikube
either needs to start supporting a user-supplied CIDR for the VM created via hyperkit, or become smart enough to figure out which CIDR is on and fix all the defaults.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
this issue must be fixed by this PR https://github.com/kubernetes/minikube/pull/15720 could anyone who has this problem try this binary and confirm it is fixed ? https://storage.googleapis.com/minikube-builds/15720/minikube-darwin-amd64
Steps to reproduce the issue:
brew install hyperkit && brew install minikube
minikube start
minikube mount /folder:/folder
Run
minikube logs --file=logs.txt
and drag and drop the log file into this issueFull output of failed command if not
minikube start
:logs.txt minikube_mount_90d1df7cf73d2307a9c342b14ba42d70e548606c_0.log
This appears to be the same issue in #12537 and #11475. I'm not sure why the reporters closed those tickets when they found a workaround because this appears to still be an issue in the code. A workaround should not be required