minikube: docker inspect -f "'{{(index (index .NetworkSettings.Ports "22/tcp") 0).HostPort}}'" minikube: exit status 1

Was facing the same issue after a fresh minikube install. Only a minikube delete did not solve for me as @j75, I did a docker system prune, minikube delete and then minikube start --driver=docker and it worked fine.

I performed a cleanup using “minikube delete” and then started using “minikube start --driver=docker” it worked

In my case, removing minikube container docker rm minikube and minikube start solved the problem.

I was able to start the cluster without tearing it down.

These are the steps that I followed:

1. Re-create the Minikube network that the existing Minikube cluster is using (note: you might need to disconnect whichever containers are currently connected to that network)

$ docker network rm minikube
$ docker network create minikube

1. Connect your existing Minikube containers to the new network (you might want to automate this if you have many nodes in your cluster)

$ docker network connect minikube minikube
$ docker network connect minikube minikube-m02
$ docker network connect minikube minikube-m03

1. Build minikube from source in order to use the new --network flag. This flag is not available in the latest release, and it’s needed. Otherwise, minikube start will attempt to create a network and it will fail with the errors above.
2. Run the following command to start your cluster (there can be more flags depending on each specific case, I’m just showing the relevant one):

$ minikube start --network=minikube

I beleive this happens when minikube tried to create a container, but then docker failed but on a second start there is stuck container, that minikube can not create on top of it.

currently if users specify “–delete-on-failure” as this PR https://github.com/kubernetes/minikube/pull/8628 it will fix the problem.

however we could detect that this is not a recover-able state and we should just delete it for them. even if they don’t specify this flag. this would require some extra care or maybe a prompt from the user. to confirm the delete (if they dont have a any interesting data inside the dead container)

The current work-around:

restart docker and ensure it is running minikube delete minikube start