Docker Desktop 4.11.1 restores VM mounts and WSL registry login
Two regressions expose the integration work beneath ordinary Docker commands. One confuses VM system paths with host shares, while the other blocks private-registry authentication from WSL.
A path passed to Docker Desktop can refer to the host filesystem or to the Linux environment managed inside its VM. Confusing those locations can break a container before its process starts. Docker Desktop 4.11.1 fixes a regression that prevented VM system locations such as /var/lib/docker from being bind-mounted, according to the August 5 release notes.
The same patch fixes private-registry login from a WSL 2 distribution. These are small release notes with concrete consequences. A container monitoring system can lose access to the files it inspects, while a developer can lose the ability to authenticate to the registry holding an application image. Neither failure requires an application code change.
I value Docker's ability to make an environment portable through an image and a repeatable build. These regressions concern the workstation integration around that artifact. They are a reminder that an unchanged image can become unusable through a change in how Desktop connects its environments.
A VM path was treated as a host sharing path
The mount regression report was opened on July 29 after an upgrade to Desktop 4.11.0. Its minimal reproduction attempted to mount /var/lib/docker/containers into an Ubuntu container and run echo hello. The reporter expected the container to start, but the daemon instead tried to create a source path under /host_mnt/private/var/lib/docker and returned an operation-not-permitted error.
That error provides more information than a general statement that a mount failed. The requested source was a system location in the VM. Instead, the error referred to a translated host mount path. The release notes describe the correction as restoring bind mounts from VM system locations. They do not provide the implementation patch, so the precise internal cause should not be inferred beyond that documented mismatch.
The reporter identified a practical use case involving a monitoring agent that reads container logs and metrics. That makes the failure consequential even when ordinary application containers still start. A tool inspecting the environment has different filesystem requirements from a service that only needs its own source directory or data volume.
Other comments made before this patch describe failures involving /etc/machine-id and local kind cluster creation. These reports illustrate why the location of the source path matters. They do not establish that every bind mount failed or that every monitoring tool was affected. The release's stated scope is the regression involving VM system locations.
Authentication failed with a misleading policy message
The Windows login report, also opened on July 29, describes docker login registry.gitlab.com failing under Desktop 4.11.0. The error said Registry Access Management was blocking Docker Hub and that command line login was unsupported in that configuration. According to the reporter, the installation did not use Docker Business and login succeeded after returning to 4.10.1.
The registry named in the command matters. The developer requested access to a private registry, while the error described a Docker Hub policy condition. A policy message is therefore evidence of the code path producing the error. It is not sufficient evidence that the organization intentionally configured the claimed restriction.
Reports in the thread include other private registry services and WSL environments. Docker supplied a test build during investigation, and participants reported differing results. Some could log in through Windows but still received an error from WSL about a missing backend socket. Those differences show why describing the shell environment is useful when reporting the failure.
The release notes give the supported outcome for the shipped patch. They identify private-registry login from WSL 2 as fixed in 4.11.1. There is no need to treat the experimental build numbers in the discussion as a separate released product or to generalize every reported test result into a release guarantee.
Successful engine access does not establish successful login
One participant could run docker ps while docker login failed to find a backend socket. That is a useful distinction between operations through the same command line program. Listing containers and authenticating can require different integration paths. Success in the first operation does not prove that the second has all its prerequisites.
My preference is to keep that distinction in the explanation of a patch. A report that Docker works from WSL is too broad when the failing operation is authentication. Naming the command and the environment gives the next engineer a reproducible description instead of a general health claim.
Desktop 4.11.1 restores two connections required by existing workflows. The mount fix concerns where a source path belongs. The login fix concerns a command executed through WSL against a private registry. Both make the environment's intended boundaries usable again without requiring changes to the application's image definition.