Skip to content
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

minikube --mount is broken on OS X #2661

Closed
MadWombat opened this issue Mar 29, 2018 · 9 comments · Fixed by #2671
Closed

minikube --mount is broken on OS X #2661

MadWombat opened this issue Mar 29, 2018 · 9 comments · Fixed by #2671
Labels
lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed.

Comments

@MadWombat
Copy link

Is this a BUG REPORT or FEATURE REQUEST? (choose one):

bug report

Please provide the following details:

Environment:

Minikube version (use minikube version): v0.25.2

  • OS (e.g. from /etc/os-release): OS X 10.13.3
  • VM Driver (e.g. cat ~/.minikube/machines/minikube/config.json | grep DriverName): hyperkit
  • ISO version (e.g. cat ~/.minikube/machines/minikube/config.json | grep -i ISO or minikube ssh cat /etc/VERSION): minikube-v0.25.1.iso
  • Install tools: None, manually downloaded and installed latest minikube and driver
  • Others:
    The above can be generated in one go with the following commands (can be copied and pasted directly into your terminal):
minikube version
echo "";
echo "OS:";
cat /etc/os-release
echo "";
echo "VM driver": 
grep DriverName ~/.minikube/machines/minikube/config.json
echo "";
echo "ISO version";
grep -i ISO ~/.minikube/machines/minikube/config.json

What happened:

The xhyve VM driver used to mount /Users in /Users in minikube VM. Since it is deprecated, I switched to hyperkit driver that does not provide the same default mount. So I tried to use minikube's --mount flag to simulate the same thing. I started minikube as minikube start --mount --mount-string /Users:/Users. When the cluster has started, I tried minikube ssh ls /Users and got ls: cannot access '/Users': Input/output error.

What you expected to happen:

/Users to be accessible to minikube VM

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

Same way I did. Start minikube as a regular "Admin" user on OS X with --mount and --mount-string /Users:/Users flags (I think just --mount should suffice, but I am not sure) and use minikube ssh to verify that the mount is not really accessible.

@MadWombat MadWombat changed the title minikube --mount and --mount-string is broken on OS X minikube --mount is broken on OS X Mar 29, 2018
@NsLib
Copy link
Contributor

NsLib commented Apr 2, 2018

It probably caused by wrong file permission, since /Users directory is owned by root:admin, minikube cannot access it in a vm.

@MadWombat
Copy link
Author

Well, those permissions are a default on OS X, so it should be handled with a bit more grace than throwing an I/O error on access. A message saying mount on OS X is not supported, a suggestion on permission adjustment or something.

@NsLib
Copy link
Contributor

NsLib commented Apr 3, 2018

I've submitted a PR #2671

@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jul 2, 2018
@fejta-bot
Copy link

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

@k8s-ci-robot k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Aug 1, 2018
@fejta-bot
Copy link

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

@k8s-ci-robot
Copy link
Contributor

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@haf
Copy link

haf commented Dec 9, 2018

Was this ever fixed?

How are the permissions supposed to be set?

@jondkelley
Copy link

jondkelley commented Dec 22, 2020

Was this ever fixed?
How are the permissions supposed to be set?

Agreed, this issue is still an apparent bug to me and seems like the maintainers had the bot silently close this one without remarks...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants