FAQs for Windows
Yes, you can run VirtualBox along with Docker Desktop if you have enabled the Windows Hypervisor Platformopen_in_new feature on your machine.
Docker Desktop uses the Windows Hyper-V features. While older Windows versions have Hyper-V, their Hyper-V implementations lack features critical for Docker Desktop to work.
No, running Docker Desktop on Windows Server is not supported.
Docker Desktop displays the Docker Desktop - Access Denied error if a Windows user is not part of the docker-users group.
If your admin account is different to your user account, add the docker-users group. Run Computer Management as an administrator and navigate to Local Users and Groups* > Groups > docker-users.
Right-click to add the user to the group. Sign out and sign back in for the changes to take effect.
Some anti-virus software may be incompatible with Hyper-V and Windows 10 builds which impact Docker Desktop. For more information, see Docker Desktop fails to start when anti-virus software is installed.
Docker Desktop does not enable you to control (
the Unix-style permissions on
shared volumes for
deployed containers, but rather sets permissions to a default value of
execute permissions for
user and for
group) which is not configurable.
For workarounds and to learn more, see Permissions errors on data directories for shared volumes.
Docker Desktop supports two types of symlinks: Windows native symlinks and symlinks created inside a container.
The Windows native symlinks are visible within the containers as symlinks, whereas symlinks created inside a container are represented as mfsymlinksopen_in_new. These are regular Windows files with a special metadata. Therefore the symlinks created inside a container appear as symlinks inside the container, but not on the host.
Docker Desktop mounts the Windows host filesystem under
/run/desktop inside the container running Kubernetes.
Stack Overflow postopen_in_new for an example of how to configure a Kubernetes Persistent Volume to represent directories on the host.
You can add trusted Certificate Authorities (CAs) to your Docker daemon to verify registry server certificates, and client certificates, to authenticate to registries.
Docker Desktop supports all trusted Certificate Authorities (CAs) (root or intermediate). Docker recognizes certs stored under Trust Root Certification Authorities or Intermediate Certification Authorities.
Docker Desktop creates a certificate bundle of all user-trusted CAs based on the Windows certificate store, and appends it to Moby trusted certificates. Therefore, if an enterprise SSL certificate is trusted by the user on the host, it is trusted by Docker Desktop.
To learn more about how to install a CA root certificate for the registry, see Verify repository client with certificates in the Docker Engine topics.
You can add your client certificates
~/.docker/certs.d/<MyRegistry><Port>/client.key. You do not need to push your certificates with
When the Docker Desktop application starts, it copies the
~/.docker/certs.d folder on your Windows system to the
directory on Moby (the Docker Desktop virtual machine running on Hyper-V).
You need to restart Docker Desktop after making any changes to the keychain
or to the
~/.docker/certs.d directory in order for the changes to take effect.
The registry cannot be listed as an insecure registry (see
Docker Daemon). Docker Desktop ignores
certificates listed under insecure registries, and does not send client
certificates. Commands like
docker run that attempt to pull from the registry
produce error messages on the command line, as well as on the registry.
To learn more about how to set the client TLS certificate for verification, see Verify repository client with certificates in the Docker Engine topics.
From the Docker Desktop menu, you can toggle which daemon (Linux or Windows) the Docker CLI talks to. Select Switch to Windows containers to use Windows containers, or select Switch to Linux containers to use Linux containers (the default).
For more information on Windows containers, refer to the following documentation:
Microsoft documentation on Windows containersopen_in_new.
Build and Run Your First Windows Server Container (Blog Post)open_in_new gives a quick tour of how to build and run native Docker Windows containers on Windows 10 and Windows Server 2016 evaluation releases.
Getting Started with Windows Containers (Lab)open_in_new shows you how to use the MusicStoreopen_in_new application with Windows containers. The MusicStore is a standard .NET application and, forked here to use containersopen_in_new, is a good example of a multi-container application.
To understand how to connect to Windows containers from the local host, see I want to connect to a container from Windows
Settings dialog changes with Windows containers
When you switch to Windows containers, the Settings dialog only shows those tabs that are active and apply to your Windows containers:
If you set proxies or daemon configuration in Windows containers mode, these apply only on Windows containers. If you switch back to Linux containers, proxies and daemon configurations return to what you had set for Linux containers. Your Windows container settings are retained and become available again when you switch back.