Description
Premise: my workspace makes use of symlinks to make available the (below mentioned) Projects directory; it has something like ln -s /Users/Shared/Projects /Users/myuser/Projects/
Steps to reproduce the issue:
0. there's already a service deployed
1. minikube start (performs automatically the minikube mount)
😄 minikube v1.15.1 on Darwin 10.14.6 ▪ MINIKUBE_ACTIVE_DOCKERD=minikube ✨ Using the virtualbox driver based on existing profile 👍 Starting control plane node minikube in cluster minikube 🔄 Restarting existing virtualbox VM for "minikube" ... 🐳 Preparing Kubernetes v1.19.4 on Docker 19.03.13 ... 🔎 Verifying Kubernetes components... 🌟 Enabled addons: storage-provisioner, default-storageclass, dashboard 🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default
2. minikube ssh -- ls -la /Users/myuser/Projects returns
lrwxr-xr-x 1 docker docker 18 Aug 30 2019 /Users/myuser/Projects -> ../Shared/Projects
👍 The symlink was followed correctly.
Unfortunately, by default, minikube mounts the hosthome (/Users on macOS) using ownership from the minikube's docker user, while my service needs a user app.
This causes broken file permissions (in the pod's container of the running service) when trying to kubectl exec commands that need to execute & write inside the containers (this because the project folder is mounted as docker:docker instead of app:app).
3. minikube mount /Users:/Users --uid 61234 --gid 61234 should solve the above issue, allowing to specify UID and GID of the mounting user (the numbers correspond to app:app).
BUT
after performing the fix to the mount..
4. minikube ssh -- ls -la /Users/myuser/Projects/ returns
ls: cannot access '/Users/myuser/Projects/': Not a directory
5. minikube ssh -- ls -la /Users/myuser/Projects returns
-rwxr-xr-x 1 61234 61234 18 Aug 30 2019 /Users/myuser/Projects
😖 The symlink functionality has been lost.
It says that it is not a directory, while it should follow the symlink and allow the mount to access its content.
Even more unfortunate is that, after terminating the manual minikube mount command, the mount is not being restored to the default automatic mount.
Off-Topic, but maybe --uid and --gid should be supported directly on the minikube start command, so that the correct user is handled automatically.
Workaround: it is possible to mount directly my project folder, executing from it, with
minikube mount $(pwd):$(pwd) --uid 61234 --gid 61234
to skip the need of the symlink.
However I repute this a bug and I thought it made sense to report it in an issue, to get that fixed. Even though there's a workaround, this is not ideal because it requires the user to always remember to manually mount and because it makes the automatic behaviour inconsistent (hence unpredictable) and buggy (when closing the manual mount).