The situation:

I develop on a windows VDI that uses the WSL to run docker, and I'm actually using a remote docker daemon running on a Red Hat server. Locally, I have the DOCKER_HOST variable set to the correct path to my docker daemon (tcp://<userid>@<my server running the remote docker daemon>), but this environment variable is only recognized immediately after being set.

What I mean by this is, right now, if I run a docker command, I get the Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? error, but if I assign DOCKER_HOST to itself with $ export DOCKER_HOST=$DOCKER_HOST, future docker commands will now recognize the remote daemon I'm directing it to with that variable.

I've added this assignment to DOCKER_HOST in my ~/.bashrc, and I can see that it's properly set when I reboot the shell and run $ echo $DOCKER_HOST.

Expected behavior:

I expect docker commands to refer to the DOCKER_HOST variable that is set within ~/.bashrc, who's presence is confirmed with $ echo $DOCKER_HOST


Docker doesn't recognize this variable/this variable's value unless it is set in the active shell's session. I literally have to assign the variable to itself for docker to recognize it (e.g. export DOCKER_HOST=$DOCKER_HOST) and only then will docker commands run against the remote daemon.

My questions:

Why do I have to reset the DOCKER_HOST variable for docker to be able to recognize it?

If I'm doing this incorrectly, what is the proper way?

I'm open to hearing that I'm in the wrong place with my question. I could see this being a Linux/WSL issue, or an issue with docker itself.

1 Answer 1


I found the solution to this shortly after posting this, and I feel a bit silly.

The problem was that I was merely setting a shell variable within ~/.bashrc and not exporting an envrionment variable.

The solution:

Modify ~/.bashrc to use export:

export DOCKER_HOST=tcp://<userid>@<my server running the remote docker daemon>

instead of just:

DOCKER_HOST=tcp://<userid>@<my server running the remote docker daemon>

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .