Docker-desktop does not work on Debian

General
1

I have followed this guide to install docker-desktop on a fresh Debian 12 install. Although the docker-desktop GUI appears and will open, I am unable to actually interact with docker in the terminal.

I notice that a desktop-linux context did not get created.

These commands show some information:

➜ docker --version
Docker version 28.0.4, build b8034c0

➜ docker compose version
Docker Compose version v2.34.0-desktop.1

➜ docker version
Client: Docker Engine - Community
 Version:           28.0.4
 API version:       1.48
 Go version:        go1.23.7
 Git commit:        b8034c0
 Built:             Tue Mar 25 15:07:22 2025
 OS/Arch:           linux/amd64
 Context:           default
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

I tried adding my user to the docker group but this didn’t change things.

Here is my docker info:

🗴 docker info
Client: Docker Engine - Community
 Version:    28.0.4
 Context:    default
 Debug Mode: false
 Plugins:
  ai: Docker AI Agent - Ask Gordon (Docker Inc.)
    Version:  v1.1.3
    Path:     /usr/lib/docker/cli-plugins/docker-ai
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.22.0-desktop.1
    Path:     /usr/lib/docker/cli-plugins/docker-buildx
  cloud: Docker Cloud (Docker Inc.)
    Version:  0.2.20
    Path:     /usr/lib/docker/cli-plugins/docker-cloud
  compose: Docker Compose (Docker Inc.)
    Version:  v2.34.0-desktop.1
    Path:     /usr/lib/docker/cli-plugins/docker-compose
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.38
    Path:     /usr/lib/docker/cli-plugins/docker-debug
  desktop: Docker Desktop commands (Beta) (Docker Inc.)
    Version:  v0.1.6
    Path:     /usr/lib/docker/cli-plugins/docker-desktop
  dev: Docker Dev Environments (Docker Inc.)
    Version:  v0.1.2
    Path:     /usr/lib/docker/cli-plugins/docker-dev
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.27
    Path:     /usr/lib/docker/cli-plugins/docker-extension
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.4.0
    Path:     /usr/lib/docker/cli-plugins/docker-init
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     /usr/lib/docker/cli-plugins/docker-sbom
  scout: Docker Scout (Docker Inc.)
    Version:  v1.17.0
    Path:     /usr/lib/docker/cli-plugins/docker-scout

Server:
ERROR: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
errors pretty printing info

I even completely purged docker to try again this morning, but this is the same outcome. Maybe I have some missing dependencies? I noticed from reading other threads that docker needs iptables, which I did not have on my system when installing. Not sure if that’s a problem. At this point I need some assistance before I try this for a third time.

As a side-question, if I were to install docker the older way, using my package manager and docker.io (which has worked in the past), would I still be able to run the docker-desktop GUI? Would I still be able to enable kubernetes?

2

You probably just need to switch to the Docker Desktop context

docker context use desktop-linux

docker.io is not recommended. Docker has an official documentation to install the officially supported version. docker.io is supported by the Linux distribution’s maintainers.

And The Docker Engine is not an “older way”. Docker Desktop is for development while Docker Engine could be used in production. Not to mention that there are features that Docker Desktop cannot support as it runs the Docker daemon in a virtual machine whether you ant it or not. So you cannot mount devices or unix socket files from physical hosts to virtual machines.

Docke rDesktop by the way sets the context by default to “desktop-linux”, so if your docker info shows you are using the default context, it is probably because it was somehow overridden.If you want to avoid confusion, make sure you only have either Docker Desktop or Docker CE, and not docker.io or the docker snap package.

It is not an independent GUI. It is for the virtual machine that comes with Docker Desktop. If you have Docker CE installed instead of Docker DEsktop, you can still use kind directly on the host (which is also used by Docker Desktop for multi-node clusters) or minikube, or just k3s for example.

3

Hi, thanks for the reply.

This was something I tried initially, as I mentioned in my OP. Listing the contexts out showed that there was no desktop-linux context.

4

You are right, I read too quickly again and missed that part. Contexts are created under $HOME/.docker/contexts. If the desktop-linux context was not created, my next guess is that Docker Desktop didn’t have permission to create it for some reason. Here is my context meta file, but your would have a different hash

cat ~/.docker/contexts/meta/fe9c6bd7a66301f49ca9b6a70b217107cd1284598bfc254700c989b916da791e/meta.json

Output

{"Name":"desktop-linux","Metadata":{"Description":"Docker Desktop","otel":{"OTEL_EXPORTER_OTLP_ENDPOINT":"unix:///Users/ta/.docker/run/user-analytics.otlp.grpc.sock"}},"Endpoints":{"docker":{"Host":"unix:///Users/ta/.docker/run/docker.sock","SkipTLSVerify":false}}}

Check what you have in $HOME/.docker/contexts and what are the permissions on the folder and also $HOME/.docker/contexts/meta.

If permissions are broken, you can also try to stop Docker Desktop, move the original .docker folder to a backup folder, just in case you want to restore, strt Docker Desktop again and see if the context is created.

You could probably create it manually using docker context create, but I’m not on Linux now, so I can’t tell if the context is built like mine on macOS.

5

Interesting thought about permissions. So I had completely purged docker again from my system and this time I reinstalled it but after pre-creating the directory, just to make sure:

mkdir 700 ~/.docker
chown $USER:$USER ~/.docker

After the installation I started the app and everything looks ok in the UI - it says docker engine is running. But I again try docker context ls and it shows just:

 ➜ docker context ls
NAME        DESCRIPTION                               DOCKER ENDPOINT               ERROR
default *   Current DOCKER_HOST based configuration   unix:///var/run/docker.sock

The weird thing is that my .docker/contexts/meta file shows a desktop-linux context:

➜ cat ~/.docker/contexts/meta/fe9c6bd7a66301f49ca9b6a70b217107cd1284598bfc254700c989b916da791e/meta.json
{"Name":"desktop-linux","Metadata":{"Description":"Docker Desktop","otel":{"OTEL_EXPORTER_OTLP_ENDPOINT":"unix:///home/l/.docker/desktop/user-analytics.otlp.grpc.sock"}},"Endpoints":{"docker":{"Host":"unix:///home/l/.docker/desktop/docker.sock","SkipTLSVerify":false}}}

So it doesn’t appear to be a permissions issue (?), but I’m also quite confused as to why there is a desktop-linux entry in this directory. If I try to docker pull hello-world it just says the same old Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?. I also tried systemctl --user start docker-desktop just to make sure, even though it’s clearly running.

On your suggestion I tried docker context create desktop-linux, and then switched, but it’s still unable to connect to the daemon.

I also found your post, which gave some extra clues. Interestingly, I see this:

l ~
🗴 docker context inspect --format '{{ .Endpoints.docker.Host }}'
unix:///var/run/docker.sock

l ~
➜ file /var/run/docker.sock
/var/run/docker.sock: cannot open `/var/run/docker.sock' (No such file or directory)

If I am understanding correctly, this file should exist on my system. Also, you mention that many users skip the post-install. In the guide (at least for debian), it has a small section that starts “The RPM package includes a post-install script…”. I do wonder if this is a mistake in the documentation as RPM is quite irrelevant for a debian-based distribution, which is the focus on that page… So could it be that there are some post-install steps missing from that guide? I did previously try adding my user to the docker group, which is still in place, but I did not do anything relating to symlinks that I can now see mentioned in the RPM section there…

6

Docker Desktop can also set the default context for itself and it can also set the default socket to be used with Docker Desktop, but as far as I know, the desktop-linux context is always there. Since I mainly use macOS, I may be wrong about how a new Docker Desktop can be installed on Linux.

The fact that your file contains “desktop-linux” as context name is still strange as it is what you should see when you run docker context ls and you don’t see it. Please, run this command to get the context as json using the docker cli:

docker context ls --format json

Normally you should see the same json as you see in the file. Since docker context ls shows “default”, I expect that to be shown in the json formatted output as well.

If you get a different context from the docker cli, that could mean that your cli is using another folder. You can actually change it using an environment variable as I did that in this script:

using the DOCKER_CONFIG env variable. You can check if it is set in your shell. I would also check what you get in the outpot of this command:

which docker

And just to be sure you have no any accidentally left packages from other docker variants, you can run this command too:

dpkg -l 'docker*' | grep '^ii'
snap list docker

I don’t expect snap to be present on Debian, but the first command should also confirm that you have no other docker clients only the one from the official Docker CE repository.

I haven’t shared the command so it was not a suggestion to run it, without arguments. If you just create a new context without setting which socket you want to connect to, it will not work.

If Docker Desktop is running, this is where you should see the socket file that would be used in the desktop-linux context:

$HOME/.docker/run/docker.sock

If you run the following command in the terminal (not as root), it should set the docker host to the socket file even if your context is set to use another socket:

export DOCKER_HOST=unix://$HOME/.docker/run/docker.sock

Then if docker commands work, we at least know the client can communicate with Docker Desktop, but the required context is wrong for some reason.

If the socket file cannot be found, please run this command too:

find "$HOME/.docker" -name '*.sock'

It lists the socket files used by Docker Desktop

7

Ok, problem solved! This was all down to me having my DOCKER_CONFIG environment variable set in my bashrc. I had copied some variables over to this machine and completely missed that I had it set to $XDG_CONFIG_HOME/docker in an attempt to avoid cluttering my home dir. I’ll leave it there as docker is now working, thanks very much for taking the time to troubleshoot this.