Dev Containers fails with rootless Docker socket; need user-configurable host docker socket path / priority

[cubicYYY]

Description

When using Dev Containers with docker-outside-of-docker feature, container startup can fail if the host Docker socket is not at a predefined path.

For example, in rootless Docker setups, the daemon socket is typically located at:

/run/user/$UID/docker.sock

instead of the conventional:

/var/run/docker.sock

The feature/init script assumes a fixed socket position /var/run/docker.sock.

If the actual host socket is elsewhere, the default mount fails.
Attempting to fix this by manually mounting the rootless socket failed to override this path, causing conflicts.

Expected behavior

• Dev Containers should work with both rootful and rootless Docker without fragile manual mounts.
• Users should be able to explicitly specify or override the preferred host Docker socket path.

Actual behavior

• Startup fails when the host socket is not at an assumed location.
• Manual socket mounts can conflict with feature-managed sockets (docker-host.sock vs docker.sock).

Environment

• Host: Linux, rootless Docker (/run/user/$UID/docker.sock)
• Dev Containers / docker-outside-of-docker feature
• (versions can be added)

Suggested improvement

Add a supported configuration option to override host Docker socket selection, for example:

• hostDockerSocket
• sourceSocket
• or an ordered preference list (e.g. ${XDG_RUNTIME_DIR}/docker.sock → /var/run/docker.sock)

This would:

• Avoid hardcoded assumptions about socket paths
• Eliminate conflicting manual mounts
• Make Dev Containers robust in rootless and nested Docker environments

Additional note

Rootless Docker is common on shared machines and restricted environments. First-class support for non-standard socket paths would significantly improve reliability.

[Clockwork-Muse]

This also affects things podman, which:

1. Doesn't even have a socket by default
2. Runs rootless by default
3. Uses a different socket name, obviously

In my case, I'm running inside a toolbox on Fedora 43, using podman. I've managed to get around things by using podman-remote and symlinking to that, but need this feature to work as well.

That aside, last I was aware it's not possible to expose mount configurations from extension entries in the .devcontainer.json - we need new spec/tooling support for that.