Page MenuHomePhabricator

Permission denied upon `minikube start` as non-root user
Closed, InvalidPublic

Description

After installing our packaged version of minikube on a new labs instance, I tried minikube start as a non-root user and got:

dduvall@ci-staging-pipelinebuilder-1001:~$ minikube start
Starting local Kubernetes v1.9.0 cluster...
Starting VM...
Getting VM IP address...
Moving files into cluster...
E0329 18:07:13.042451   31614 start.go:234] Error updating cluster:  downloading binaries: transferring kubeadm file: &{BaseAsset:{data:[] reader:0xc42000e310 Length:0 AssetName:/home/dduvall/.minikube/cache/v1.9.0/kubeadm TargetDir:/usr/bin TargetName:kubeadm Permissions:0641}}: error removing file /usr/bin/kubeadm: remove /usr/bin/kubeadm: permission denied

It appears that the cluster update process in minikube tries to install downloaded kubeadm and kubelet binaries into /usr/bin regardless of whether they already exist. Installing these binaries in the first place is problematic with our package as it requires a full minikube start as root—there is no separate "update cluster" command.

We need to suss these issues out before proceeding with minikube on CI instances. The best apparent options would seem to be to package kubeadm and kubelet separately and create a Debian patch for minikube which skips these binary installations. Perhaps there is a better/easy way?

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 2 2018, 4:14 PM
dduvall triaged this task as High priority.Apr 2 2018, 4:24 PM
dduvall closed this task as Invalid.Apr 3 2018, 5:21 PM

After chatting with @thcipriani it's clear that minikube --vm-driver=none is not really meant to work when run as a non-root user. We'll continue on with this on labs instances only and limit our use to the test-only version of the pipeline job (w/o registry push).