Why does Docker Desktop create temporary bind-mount paths for some Compose volumes on WSL2?

Those /run/desktop/... paths are Docker Desktop’s bind-mount proxy. Docker Desktop creates them when a host path has to be made visible inside its Linux VM. They are implementation details, not paths from your Compose file, and they can disappear when Docker Desktop or WSL is restarted.

The first thing to check is the fully resolved configuration with `docker compose config`. Confirm the project directory and the resolved `source` values, rather than relying on the relative paths shown in the YAML. Also make sure the Compose command is being run from the same WSL directory every time and that the directories exist before the containers are created. If the containers were created with an older configuration, remove and recreate them after correcting the paths.

Nginx working does not prove that both services were created from identical resolved input. Inspect the running container’s labels, creation time, and the output of `docker compose config`; compare those with `docker inspect`. A container can retain mount settings from an earlier Compose run even after the YAML has been changed. Recreating it rather than merely restarting it is important when diagnosing this kind of problem.

There may also be a startup race. Docker Desktop, its WSL distributions, the integration with Ubuntu, and the Compose project do not necessarily become ready at exactly the same time after Windows boots. Starting containers before Docker Desktop has fully initialized can leave stale or incomplete mount-proxy state.

For a production deployment, avoid depending on Docker Desktop’s on-demand startup if possible. Run Docker Engine natively inside WSL/Linux, or use a supported native Windows container setup when Windows containers are actually required. At minimum, ensure Docker Desktop and WSL are fully started before bringing the Compose project up, and recreate containers if they retain obsolete mount definitions.

The most reliable setup is to keep the project and all bind-mounted files inside the WSL filesystem, for example under /home/mickael/odoo-gema, and run Compose from there. Avoid launching the project through a Windows path, a mounted /mnt/c path, or a Windows-side Docker client if possible. Use absolute Linux paths temporarily to verify what Docker is receiving, then recreate the containers with `docker compose down` followed by `docker compose up -d`.

The named `odoo-data` entry is a Docker-managed volume, not a bind mount, so it is unrelated to the temporary bind-mount directories. The Odoo image itself does not normally require Docker to invent permanent host paths for these mounts.