Minikube: Enabling 'default-storageclass' returned an error: running callbacks: [Error making standard the default storage class: Error listing StorageClasses: Unauthorized]

[ScottFred]

Steps to reproduce the issue:
MacOS: 10.15.5
Hypervisor: Virtualbox 6.1.12

1. Upgrading from an old version of Minikube:
$ minikube version
minikube version: v0.25.0

2. Download newest version
$ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \
&& chmod +x minikube

3. Move executable
$ sudo mv ./minikube /usr/local/bin/

4. Verify newly installed minikube version
$ minikube version
minikube version: v1.12.1

5. Minikube unable to start (possibly because of original installed version?)
$ minikube start --driver=virtualbox
minikube v1.12.1 on Darwin 10.15.5
💥 The existing "minikube" VM was created using the "" driver, and is incompatible with the "virtualbox" driver.
👉 To proceed, either:

1) Delete the existing "minikube" cluster using: 'minikube delete'

• or *

2) Start the existing "minikube" cluster using: 'minikube start --driver='

💣 Exiting.

6. "minikube delete" then fails because of permission issues
$ minikube delete
🔥 Removing /Users/Scott/.minikube/machines/minikube ...

💣 Unable to remove machine directory: unlinkat /Users/Scott/.minikube/machines/minikube/root-volume.sparsebundle/bands/909: permission denied

7. Removed all minikube machines to clear up permission error
sudo rm -rf ~/.minikube/machines

8. Ran "minikube delete again
minikube delete
💀 Removed all traces of the "minikube" cluster.

9. Again, try to restart minikube:
$ minikube start --driver=virtualbox
😄 minikube v1.12.1 on Darwin 10.15.5
✨ Using the virtualbox driver based on user configuration
💿 Downloading VM boot image ...

minikube-v1.12.0.iso.sha256: 65 B / 65 B [-------------] 100.00% ? p/s 0s
minikube-v1.12.0.iso: 173.57 MiB / 173.57 MiB [ 100.00% 10.65 MiB p/s 16s
👍 Starting control plane node minikube in cluster minikube
💾 Downloading Kubernetes v1.18.3 preload ...
preloaded-images-k8s-v4-v1.18.3-docker-overlay2-amd64.tar.lz4: 526.27 MiB
🔥 Creating virtualbox VM (CPUs=2, Memory=4000MB, Disk=20000MB) ...

🐳 Preparing Kubernetes v1.18.3 on Docker 19.03.12 ...
🔎 Verifying Kubernetes components...
❗ Enabling 'default-storageclass' returned an error: running callbacks: [Error making standard the default storage class: Error listing StorageClasses: Unauthorized]
🌟 Enabled addons: default-storageclass, storage-provisioner

💣 failed to start node: startup failed: wait 6m0s for node: wait for healthy API server: controlPlane never updated to v1.18.3

😿 minikube is exiting due to an error. If the above message is not useful, open an issue:
👉 https://github.com/kubernetes/minikube/issues/new/choose

1. BUT, even though the error message above says "failed to start node"... and "minikube is exiting due to an error", minikube appears to be running:
   $ minikube status
   minikube
   type: Control Plane
   host: Running
   kubelet: Running
   apiserver: Running
   kubeconfig: Configured

2. I became impatient because I wanted to work on learning Kubernetes, so I deleted ~/.minikube
   $ sudo rm -rf ~/.minikube

3. Finally, I restarted minikube without error... So, I may have solved my own problem, but I thought I would leave this here to let others know about the solution... and or to hear from the maintainers if this was the right thing to do.
   $ minikube start --driver=virtualbox
   😄 minikube v1.12.1 on Darwin 10.15.5
   ✨ Using the virtualbox driver based on user configuration
   💿 Downloading VM boot image ...

   minikube-v1.12.0.iso.sha256: 65 B / 65 B [-------------] 100.00% ? p/s 0s
   minikube-v1.12.0.iso: 173.57 MiB / 173.57 MiB [ 100.00% 12.88 MiB p/s 14s
   👍 Starting control plane node minikube in cluster minikube
   💾 Downloading Kubernetes v1.18.3 preload ...
   preloaded-images-k8s-v4-v1.18.3-docker-overlay2-amd64.tar.lz4: 526.27 MiB
   🔥 Creating virtualbox VM (CPUs=2, Memory=4000MB, Disk=20000MB) ...
   🐳 Preparing Kubernetes v1.18.3 on Docker 19.03.12 ...
   🔎 Verifying Kubernetes components...
   🌟 Enabled addons: default-storageclass, storage-provisioner
   🏄 Done! kubectl is now configured to use "minikube"

$ minikube status
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

[naikajah]

Hi @ScottFred
I too bumped into this issue today while doing some chaos testing inside minikube. The solution you mentioned worked for me as well. Thank you for posting.

[sharifelgamal]

Yeah, upgrading from a super old version of minikube like 0.25 up to 1.12 is unlikely to work. Deleting your .minikube folder (which can also be done with minikube delete --all --purge) is the best move here.

[sharifelgamal]

I'll leave this open for a little while for discoverability.

[priyawadhwa]

Hey @ScottFred glad this works for you now! I'm going to go ahead and close this issue as it seems upgrading and purging the home directory fixed it.

[tomp61]

I ran into this issue, too, trying to start minikube after not having used it for more than a year, and @sharifelgamal's suggestion fixed things for me. Thank you!

[macdaddyaz]

I had the same issue, and the fix was to purge minikube _and_ all of the old containers & images that were hanging out in Docker:

$ minikube delete --all --purge
$ docker images
REPOSITORY                           TAG                 IMAGE ID            CREATED             SIZE
k8s.gcr.io/kube-scheduler            v1.19.3             aaefbfa906bd        3 weeks ago         45.7MB
k8s.gcr.io/kube-controller-manager   v1.19.3             9b60aca1d818        3 weeks ago         111MB
k8s.gcr.io/etcd                      3.3.15-0            b2756210eeab        14 months ago       247MB
k8s.gcr.io/coredns                   1.6.2               bf261d157914        15 months ago       44.1MB
k8s.gcr.io/pause                     3.1                 da86e6ba6ca1        2 years ago         742kB
$ docker rmi aaefbfa906bd
Error response from daemon: conflict: unable to delete aaefbfa906bd (must be forced) - image is being used by stopped container 051cc3562a8d
$ docker rm 051cc3562a8d
051cc3562a8d
$ docker rmi aaefbfa906bd
Untagged: k8s.gcr.io/kube-scheduler:v1.19.3
Untagged: k8s.gcr.io/kube-scheduler@sha256:54c61fbd9939006a8fe691e308d28636bffd8031af9d53a97214d6e2d27b8720
Deleted: sha256:aaefbfa906bd854407acc3495e8a3b773bb3770e4a36d836f7fd3255c299ab25
Deleted: sha256:a2994d75f781212ac9c31112ac7f90c3a5787847a7ec907afac23791bcd4043a

For some reason, none of those images showed up with a docker ps -a. So I just had to repeatedly run those commands to clean up the containers and images. After that, I was able to get a minikube to start cleanly.