minikube: Minikube v1.30.1 unable to resolve current docker CLI context after upgrade on Ubuntu 22.04 LTS

@life5ign Try using docker context use default to update your active context which Minikube will pick up.

@life5ign Try using docker context use default to update your active context which Minikube will pick up.

Well that fixed it. I guess I never tried because docker context show printed default.

Thanks!

@life5ign Try using docker context use default to update your active context which Minikube will pick up.

This command helped fixed this issue on my end. I was getting the error when I run “minikube ssh” on my Windows machine: Error: W0810 07:22:32.053865 12548 main.go:291] Unable to resolve the current Docker CLI context "default": context "default": context not found: open C:\

I’ve had this issue as well - but default wasn’t the answer for me. instead of “docker context show” (which shows default which is what minikube is trying to use), i did “docker context ls” which shows all contexts of docker env. for some reason my local docker engine context was named “desktop-linux”. “docker context use desktop-linux” solved it… hope this helps.

@life5ign Try using docker context use default to update your active context which Minikube will pick up.

I got the same error when I run minikube ip and execute docker context use default make it worked for me

@life5ign Try using docker context use default to update your active context which Minikube will pick up.

This command helped fixed this issue on my end. I was getting the error when I run “minikube ssh” on my Windows machine: Error: W0810 07:22:32.053865 12548 main.go:291] Unable to resolve the current Docker CLI context "default": context "default": context not found: open C:\

It worked well for me

So, as it turns out, it’s actually not a bug upstream in Docker, but rather a “known limitation”. There should be guards in place, but it looks like that’s not the case. There is, however, support for resolving the default context, using the ContextStoreWithDefault, but that requires to pull in some additional packages, and I don’t know if the Minikube project wants to do that.

Taking a step back, I was questioning the purpose of this code, in general, as I think that that determines if you want to go into this direction. Some questions that popped up with me:

• what does this code really do?
  • the only observable side-effect that I can get from that function, is that it sets the DOCKER_HOST env var. Why is that needed?
• when it actually fails to resolve the default context, then Minikube is still capable of doing its job, how is that possible?
  • why is this optional? how does it gracefully degrades actually?

I don’t really know who to tag for this, as I’m not familiar with the Minikube project. @mzuzek Do you know perhaps?

I’ve updated the gist with my hack attempt to make use of this ContextStoreWithDefault. That’s working, and I can succesfully retrieve the default context. Just in case, someone wants to know what it takes to use this other API.

Thank you @tiesmaster for picking this up! Keeping my fingers crossed for the Docker ticket.

AFAICT, this is still an issue, and fully agree that this is a problem upstream in Docker. I’ve managed to make a reproduction, as shown below. @mzuzek Thanks for the hints, that definitely helped! I intent to open a ticket upstream, if anyone hasn’t already. If I don’t hear anything within, like a day, I will open the ticket.

Reproduction (full reproduction code, including the go.mod):

package main

import (
	"fmt"
	dconfig "github.com/docker/cli/cli/config"
	ddocker "github.com/docker/cli/cli/context/docker"
	dstore "github.com/docker/cli/cli/context/store"
)

func main() {
	currentContext := "default"
	storeConfig := dstore.NewConfig(
		func() interface{} { return &ddocker.EndpointMeta{} },
		dstore.EndpointTypeGetter(ddocker.DockerEndpoint, func() interface{} { return &ddocker.EndpointMeta{} }),
	)
	st := dstore.New(dconfig.ContextStoreDir(), storeConfig)
	_, err := st.GetMetadata(currentContext)
	if err != nil {
		fmt.Printf("Unable to resolve the current Docker CLI context %q: %v\n", currentContext, err)
		return
	}
}

Find out appropriate settings:

$ minikube -p minikube docker-env
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://127.0.0.1:64569"
export DOCKER_CERT_PATH="/Users/risentveber/.minikube/certs"
export MINIKUBE_ACTIVE_DOCKERD="minikube"

Then check certs

$ la /Users/risentveber/.minikube/certs
total 32
-rw-------  1 risentveber  staff   1.6K Sep  6 16:23 ca-key.pem
-rw-r--r--  1 risentveber  staff   1.1K Sep  6 16:23 ca.pem
-rw-r--r--  1 risentveber  staff   1.1K Sep  6 16:23 cert.pem
-rw-------  1 risentveber  staff   1.6K Sep  6 16:23 key.pem

Finally create special docker context

docker context create minikube --description "Minikube" --docker "host=tcp://localhost:64569,ca=/Users/risentveber/.minikube/certs/ca.pem,cert=/Users/risentveber/.minikube/certs/cert.pem,key=/Users/risentveber/.minikube/certs/key.pem"

And then use it:

docker context use minikube

Hi,

I got the same issue on Windows, below there is my current version of minikube and windows

minikube v1.31.2 on Microsoft Windows 11 Pro 10.0.22621.2134 Build 22621.2134

In attachment, there is the screenshot of the output from docker context ls. Why should I use docker context use default if it is already adopted?

This worked fine, and I can start my existing profiles (clusters), but every minikube command prints this to stderr:

I guess the warning message can be safely demoted to a debug message

@life5ign Try using docker context use default to update your active context which Minikube will pick up.

thanks a lot timothytavarez.

docker context use default worked for me !

minikube v1.31.2 on Ubuntu 22.04 x86-64 Client: Docker Engine - Community Version: 24.0.5 Server: Docker Engine - Community Engine: Version: 24.0.5 API version: 1.43 (minimum version 1.12) Go version: go1.20.6

This issue is so weird, docker context shows that default context is in use (marked with asterisk), but the warning message shows a file not found , and that file’s path belongs to the other context which is not in use (desktop-linux context).

Looks like running - docker context use default - command refreshed that path to the right one.

Thanks everyone for your help

Minikube 1.31.1 CLI commands like minikube ip on Windows 11 Pro 10.0.22621.1702 with Docker Desktop 4.22.1 (details: docker_version.txt) on WSL2-based backend gave me the warning (@@@ is my user name; line breaks added for clarity):

W0902 17:49:21.153391   31364 main.go:291] Unable to resolve the current Docker CLI context "default":
context "default": context not found: open
C:\Users\@@@\.docker\contexts\meta\37a8eec1ce19687d132fe29051dca629d164e2c4958ba141d5f4133a33f0688f\meta.json:
The system cannot find the path specified.

Weirdly enough, in VS Code the terminal (PS again) doesn’t show the path, as in the issue description:

W0902 19:26:19.803557   30516 main.go:291] Unable to resolve the current Docker CLI context "default":
context "default" does not exist

On my side docker context use worked and I’ve persisted it by setting DOCKER_CONTEXT to desktop-linux in the environment.

@carminoplata

Why should I use docker context use default if it is already adopted?

Good question!

Seems like any call to docker context use (even with current context) fixes a broken reference to nonexistent meta.json file that Docker keeps somewhere for the default context (couldn’t find it neither in the registry, nor in $env:USERPROFILE\.docker nor in $env:APPDATA…).

Looks like it’s a Docker bug, possibly related to https://github.com/docker/for-win/issues/11530 or https://github.com/docker/for-win/issues/11721, because by the docs the default context shouldn’t reference any meta.json file and indeed when it’s inspected, it says that the metadata is stored in memory:

Hey @life5ign , i had the same error and what fixed the error from appearing, was to change the path to the specified in the error message (on my machine that one alphanumerical folder name was wrong)…as yourself i had no real issues besides it popping up. Hope this helps 😉