Minikube: 9p2000.L mount breaks symbolic link creation: Operation not permitted

Created on 27 Jun 2019  ·  13Comments  ·  Source: kubernetes/minikube

Minikube version: v1.2.0

Environment:

OS : MacOS v10.15.5
VM Driver: hyperkit
Docker version (e.g. docker -v): 18.09.2, build 6247962
Install tools: brew
What happened:
I received an error "ln: failed to create symbolic link '/test/bar': Operation not permitted"

What you expected to happen:
Create a successful symbolic link

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

cd $HOME
touch foo
minikube start --vm-driver hyperkit --mount --mount-string $HOME:/test
minikube ssh -- ln -s /test/foo /test/bar

Anything else do we need to know:
This is important to me because I try and do things like npm install inside the container (for local development), and I'll get errors about it not being able to make symbolic links.

This reopens issue #890

This is happening with the Hyperkit driver but I suspect may happen with other drivers as well.

aremount causgo9p-limitation help wanted kinbug lifecyclfrozen prioritimportant-longterm

Most helpful comment

Yeah I would love to see an alternative. Unfortunately the work around above doesn't really help very much because the 9p2000.u version has issues with permissions, so it introduces a host of other problems.

All 13 comments

Very interesting find seems to relate to:
https://github.com/kubernetes/minikube/pull/3796

The following works:

cd $HOME
touch foo
minikube start --vm-driver hyperkit
minikube mount --9p-version 9p2000.u $HOME:/test &
minikube ssh -- sudo ln -s /test/foo /test/bar

This means that there was some defect introduced with the switch to version L that prevents symbolic links from functioning.

I can confirm this on kvm2 & Linux. The current mount interface is driver agnostic.

Thanks for discovering a workaround! I'll add this to the long list of bugs related to go9p. We really need an alternative approach for mounting files.

Yeah I would love to see an alternative. Unfortunately the work around above doesn't really help very much because the 9p2000.u version has issues with permissions, so it introduces a host of other problems.

Still an issue in v1.4.

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

/remove-lifecycle stale

still a problem AFAIK

Also experiencing this on Linux (kvm2, none and virtualbox) :cry:

kubectl version: 1.17.0
minikube version: 1.6.2

@hadrien-toma do you mind trying with our latest release > 1.7.3 ?

@hadrien-toma were you able to upgrade and test this out?

Sorry for the delay, so from the test I just ran today:

Status

  • kvm2 and virtualbox, issue is still there:
ln: failed to create symbolic link '/test/bar': Operation not permitted
ssh: exit status 1
  • none, not tested because of:
  minikube v1.9.2 on Ubuntu 18.04
✨  Using the none driver based on user configuration

❗  'none' driver reported an issue: the 'none' driver must be run as the root user
💡  Suggestion: For non-root usage, try the newer 'docker' driver

💣  Sorry, Kubernetes v1.18.0 requires conntrack to be installed in root's path

Context

>  cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.4 LTS"

> docker --version
Docker version 19.03.8, build afacb8b7f0

> minikube version
minikube version: v1.9.2
commit: 93af9c1e43cab9618e301bc9fa720c63d5efa393

> kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"52c56ce7a8272c798dbc29846288d7cd9fbae032", GitTreeState:"clean", BuildDate:"2020-04-16T11:56:40Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-25T14:50:46Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}

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

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

I suspect this is still an issue, I'm going to freeze this so it doesn't get closed.

Was this page helpful?
0 / 5 - 0 ratings