dev containers being mounted with hashes instead of names, leading into 'workspace not found' errors.

[Molier]

[Dev Containers] Workspace mounted with hash instead of folder name in WSL2

Environment

• VS Code: 1.95.3 (stable) and 1.96.0-insider
• Dev Containers Extension: 0.391.0
• OS: Windows 10.0.22635.4515
• WSL: Version 2.3.24.0, Kernel 5.15.153.1-2
• Docker Desktop: 4.36.0 (175267)
• Docker Engine: 27.3.1
• Remote Type: Dev Containers

Description

When opening a folder in a devcontainer, the workspace is sometimes mounted with a hash instead of the proper folder name. For example:
/workspaces/0110a523bdc23904cd5568a7d6fc183dfe16c64ca76142a30185b6a070dedffe
instead of
/workspaces/project-name

The issue appears to be triggered particularly after adding a post-install script and rebuilding the container. The first build works correctly, but subsequent builds result in the hash-based workspace path.

Steps to Reproduce

1. Create a new folder with a .devcontainer/devcontainer.json:

{
    "name": "Python 3-test",
    "image": "mcr.microsoft.com/devcontainers/python:1.1.9-3.11-bookworm",
    "postCreateCommand": "zsh -l .devcontainer/post-install.sh",
    "remoteUser": "root",
    "customizations": {
        "vscode": {
            "extensions": [
                "ms-python.python",
                "ms-toolsai.jupyter",
                "ms-azuretools.vscode-azurefunctions",
                "mhutchie.git-graph",
                "charliermarsh.ruff",
                "ms-python.vscode-pylance",
                "esbenp.prettier-vscode"
            ],
            "settings": {
                "python.pythonPath": "/usr/local/bin/python",
                "terminal.integrated.profiles.linux": {
                    "zsh": {
                        "path": "/usr/bin/zsh"
                    }
                },
                "terminal.integrated.defaultProfile.linux": "zsh"
            }
        }
    }
}

2. Add .devcontainer/post-install.sh:

source $NVM_DIR/nvm.sh
nvm install 23
npm i -g azure-functions-core-tools@4 --unsafe-perm true
pipx install poetry && poetry install
pipx install pre-commit
pipx install deptry
pre-commit install
sed -i '/^ZSH_THEME/c\ZSH_THEME="agnoster"' ~/.zshrc

Open folder in container first time - works correctly
Make a change to devcontainer config or post-install script
Rebuild container
Workspace is now mounted with a hash instead of proper name

Expected Behavior
The workspace should consistently mount as /workspaces/project-name regardless of rebuilds or configuration changes.
Actual Behavior
After rebuilding, the workspace is mounted as /workspaces/ and the VS Code UI shows multiple workspace entries with various hashes.
Additional Context

Container Inspection

{
    "Mounts": [
        {
            "Type": "bind",
            "Source": "/mnt/wsl/docker-desktop-bind-mounts/Ubuntu/0110a523bdc23904cd5568a7d6fc183dfe16c64ca76142a30185b6a070dedffe",
            "Destination": "/workspaces/0110a523bdc23904cd5568a7d6fc183dfe16c64ca76142a30185b6a070dedffe",
            "Mode": "",
            "RW": true,
            "Propagation": "rprivate"
        }
    ]
}

WSL Configuration

[boot]
systemd=true

I've tried:

Removing containers and rebuilding from scratch
Using both VS Code stable and insiders
Verifying Docker Desktop WSL integration is enabled

The issue persists across VS Code restarts and container rebuilds.

Additional Technical Details

remoteContainers-2024-11-28T14-02-16.196Z.log

Log Analysis

1. The bind mount configuration shows that Docker Desktop is creating mounts with hashed paths:

Source: /mnt/wsl/docker-desktop-bind-mounts/Ubuntu/<hash>
Target: /workspaces/<hash>

2. The failure sequence appears to be:

• Initial container creation works
• Post-install script fails (exit code 127)
• Subsequent mounts use hashed directories instead of proper workspace names

3.Error pattern shows spaces in paths may be contributing:

source=/mnt/c/Users/oscar/Downloads/test run,target=/workspaces/test run

Observed Behavior in Logs

Docker Desktop is accumulating multiple bind mount directories in /mnt/wsl/docker-desktop-bind-mounts/Ubuntu/
The post-install script failure may be triggering a fallback mounting behavior
Container inspection shows proper labels but incorrect mount paths

Additional Environment Details

WSL Distribution: Ubuntu
Docker Engine: 27.3.1
containerd: 1.7.21
runc: 1.1.13

finally my 2 cents...:

possibly:

• Docker Desktop's bind mount handling with WSL2 getting confused by multiple rebuilds
• A race condition between the bind mount setup and the post-install script execution
• Path handling issues with spaces or special characters

[Molier]

Additional Finding

Investigating /mnt/wsl/docker-desktop-bind-mounts/Ubuntu/ reveals multiple hash-named directories accumulating:

➜  Ubuntu ls /mnt/wsl/docker-desktop-bind-mounts/Ubuntu/
0110a523bdc23904cd5568a7d6fc183dfe16c64ca76142a30185b6a070dedffe
0f27eebe173f247f4788a4ed7190a18a0a37c592e1946cd7d79b737fb4a5f321
[... multiple other hash directories ...]

[Molier]

2 logs, first time works, second time the path is wrong.

first boot: working log:

remoteContainers-2024-11-28T15-15-21.045Z.log

second boot: not working anymore:

remoteContainers-2024-11-28T15-29-37.114Z.log

analysis of the logs:

The key difference between the working (log 2) and non-working (log 1) Dev Container setup lies in how the workspace folder is mounted inside the container:

Log 2 (Working):

[2024-11-28T15:15:22.000Z] Start: Run: docker run ... --mount type=bind,source=/mnt/c/Users/oscar/Nextcloud/work/OpenEnergyID,target=/workspaces/OpenEnergyID ...

The source is the correct WSL path to your project, and the target mounts it directly as /workspaces/OpenEnergyID. This is the expected behavior.

Log 1 (Not Working):

[2024-11-28T15:29:39.025Z] Start: Run: docker run ... --mount type=bind,source=/mnt/wsl/docker-desktop-bind-mounts/Ubuntu/19069a979c0cb89ef07026d4294e38fa110acd773f80e2db7057190ee238b508,target=/workspaces/19069a979c0cb89ef07026d4294e38fa110acd773f80e2db7057190ee238b508 ...

The source points to a hashed directory within Docker Desktop's bind mount area (/mnt/wsl/docker-desktop-bind-mounts/.../). This hashed directory should be an intermediary, transparently linking to your actual project directory. However, it appears this link is broken or misconfigured, leading to the observed issues. The target also mirrors this hashed directory name inside the container, which is incorrect.

so the second boot the devcontainer tries to incorrectly open the hashed workspace?