Storage emulator node does not appear in Storage Explorer after running Azurite container in Docker desktop

[v-xianya]

Storage Explorer Version

1.41.0-dev

Regression From

1.40.2

Architecture

x64

Storage Explorer Build Number

20251107.1

Platform

All

OS Version

Windows 11 x64

Bug Description

After launching Docker Desktop and running the Azurite Docker image, the expected storage emulator node does not appear in Storage Explorer.

Resource Types

No response

Authentication Method

Sign in

Connection Type

None

Steps to Reproduce

1. Launch Docker Desktop, then expand the Terminal from the status bar at the bottom.
2. Run docker pull mcr.microsoft.com/azure-storage/azurite to download the Azurite Docker image.
3. Click the “Images” button on the left, then click the Play button to run a new container.
4. Expand the “Optional settings” and assign three host ports (10000,10001,10002).
5. Launch Storage Explorer -> Expand Emulator & Attached -> Storage Accounts.
6. Check whether a node appears with a name following the format "Account Name (Container Name)".

Actual Experience

No node appears with a name following the format "Account Name (Container Name)".

Expected Experience

A node appears with a name following the format "Account Name (Container Name)".

Additional Context

1. This issue doesn't reproduce on MacOS.
2. This issue also reproduces for Custom accounts.

[craxal]

@v-xianya I am able to reproduce...maybe? If I build and run a local build, it seems to reproduce if my editor was open before I installed Docker Desktop. That's because the editor doesn't pick up the updated PATH environment variable that Docker modifies.

What happens if you log out and log back in after installing Docker, then launch Docker and Storage Explorer? Or restart then launch Docker and Storage Explorer?

If the issue still occurs:

• Can you provide the app logs, please?
• Can you tell me where Docker is installed?
• Can you share the PATH environment variable?
  1. Open the dev window with F12.
  2. Click the Console tab.
  3. Type process.env.path.split(";").
  4. Copy the output.

[v-xianya]

Hi @craxal
I verified on the latest build 20251110.1. This issue reproduces for both scenarios log out and log back in after installing Docker, then launch Docker and Storage Explorer/restart then launch Docker and Storage Explorer.

Can you provide the app logs, please?
Here is the log for the scenario restart then launch Docker and Storage Explorer.
2025-11-11_102752.zip

Can you tell me where Docker is installed?
C:\Program Files\Docker\Docker

Can you share the PATH environment variable?
[
"C:\Program Files (x86)\Microsoft\Edge\Application",
"C:\Windows\system32",
"C:\Windows",
"C:\Windows\System32\Wbem",
"C:\Windows\System32\WindowsPowerShell\v1.0\",
"C:\Windows\System32\OpenSSH\",
"C:\Windows\system32\config\systemprofile\AppData\Local\Microsoft\WindowsApps",
"",
"C:\Program Files\Microsoft Dev Box Agent\Scripts",
"C:\Program Files\Microsoft SQL Server\170\Tools\Binn\",
"C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\",
"C:\Program Files\dotnet\",
"C:\Program Files\Docker\Docker\resources\bin",
"C:\Users\v-xianya\AppData\Local\Microsoft\WindowsApps",
"C:\Users\v-xianya\.dotnet\tools"
]

[craxal]

@v-xianya That seems to explain why Docker isn't working. The CLI is not in the path variable. Can you confirm whether the Docker CLI is in the PATH variable for the current user after installing Docker but before launch Storage Explorer?

[v-xianya]

@craxal

1. I Installed docker desktop then install storage explorer using current user (do not launch storage explorer).
   Run 'where docker' in cmd

2. Below is the output after typing process.env.path.split(";"). in Console tab.
   [
   "C:\Windows\system32",
   "C:\Windows",
   "C:\Windows\System32\Wbem",
   "C:\Windows\System32\WindowsPowerShell\v1.0\",
   "C:\Windows\System32\OpenSSH\",
   "C:\Windows\system32\config\systemprofile\AppData\Local\Microsoft\WindowsApps",
   "",
   "C:\Program Files\Microsoft Dev Box Agent\Scripts",
   "C:\Program Files\Microsoft SQL Server\170\Tools\Binn\",
   "C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\",
   "C:\Program Files\dotnet\",
   "C:\Program Files\Docker\Docker\resources\bin",
   "C:\Users\v-xianya\AppData\Local\Microsoft\WindowsApps",
   "C:\Users\v-xianya\.dotnet\tools"
   ]

[craxal]

@v-xianya My guess is the system environment variables are not translating to the Storage Explorer process's environment variables.

Feel free to send me the VM info, and I can find some time to debug.

[v-xianya]

Hi @craxal I’ve sent the VM information on Teams.

[v-xianya]

Hi @craxal Here are the collected logs from three VMs with different configurations when installing Docker Desktop.

1. 2025-11-14_013117_storage-account-extension_17996.log

2. 2025-11-14_030044_storage-account-extension_13096.log

3. 2025-11-14_061529_storage-account-extension_14844.log

[craxal]

I think I found the error. There's an escapeShellArgs function we call that wraps command arguments in single quotes. So in this case, the command that's running (and failing) is docker inspect 'container_name' -format json. This is fine in bash, but CMD interprets single quotes as characters in their own right and things we literally mean 'container_name'.

The escapeShellArgs was a suggested safety consideration we put in a little while ago. But since container names must adhere to [a-zA-Z0-9][a-zA-Z0-9_.-]+, I don't think we need it.

[craxal]

@v-xianya Docker/Podman integration now uses pipes/sockets to communicate with containers instead of CLI. Can you verify whether this fixed?

[v-xianya]

@craxal Verified this issue on the main build 20251222.1. Fixed. So, we are going to close it.