mirror of https://github.com/docker/docs.git
75 lines
5.0 KiB
Markdown
75 lines
5.0 KiB
Markdown
---
|
|
description: Find known issues for Docker Desktop
|
|
keywords: mac, troubleshooting, known issues, Docker Desktop
|
|
title: Known issues
|
|
---
|
|
|
|
{{< tabs >}}
|
|
{{< tab name="For all platforms" >}}
|
|
* IPv6 is not yet supported on Docker Desktop.
|
|
{{< /tab >}}
|
|
{{< tab name="For Mac with Intel chip" >}}
|
|
* The Mac Activity Monitor reports that Docker is using twice the amount of memory it's actually using. This is due to a bug in MacOS. We have written [a detailed report](https://docs.google.com/document/d/17ZiQC1Tp9iH320K-uqVLyiJmk4DHJ3c4zgQetJiKYQM/edit?usp=sharing) on this.
|
|
|
|
* Force-ejecting the `.dmg` after running `Docker.app` from it can cause the
|
|
whale icon to become unresponsive, Docker tasks to show as not responding in
|
|
the Activity Monitor, and for some processes to consume a large amount of CPU
|
|
resources. Reboot and restart Docker to resolve these issues.
|
|
|
|
* Docker doesn't auto-start after sign in even when it's enabled in **Settings**. This is related to a set of issues with Docker helper, registration, and versioning.
|
|
|
|
* Docker Desktop uses the `HyperKit` hypervisor
|
|
(https://github.com/docker/hyperkit) in macOS 10.10 Yosemite and higher. If
|
|
you are developing with tools that have conflicts with `HyperKit`, such as
|
|
[Intel Hardware Accelerated Execution Manager
|
|
(HAXM)](https://software.intel.com/en-us/android/articles/intel-hardware-accelerated-execution-manager/),
|
|
the current workaround is not to run them at the same time. You can pause
|
|
`HyperKit` by quitting Docker Desktop temporarily while you work with HAXM.
|
|
This allows you to continue work with the other tools and prevent `HyperKit`
|
|
from interfering.
|
|
|
|
* If you are working with applications like [Apache
|
|
Maven](https://maven.apache.org/) that expect settings for `DOCKER_HOST` and
|
|
`DOCKER_CERT_PATH` environment variables, specify these to connect to Docker
|
|
instances through Unix sockets. For example:
|
|
|
|
```console
|
|
$ export DOCKER_HOST=unix:///var/run/docker.sock
|
|
```
|
|
|
|
* There are a number of issues with the performance of directories bind-mounted
|
|
into containers. In particular, writes of small blocks, and traversals of large
|
|
directories are currently slow. Additionally, containers that perform large
|
|
numbers of directory operations, such as repeated scans of large directory
|
|
trees, may suffer from poor performance. Applications that behave in this way
|
|
include:
|
|
|
|
- `rake`
|
|
- `ember build`
|
|
- Symfony
|
|
- Magento
|
|
- Zend Framework
|
|
- PHP applications that use [Composer](https://getcomposer.org) to install
|
|
dependencies in a `vendor` folder
|
|
|
|
As a workaround for this behavior, you can put vendor or third-party library
|
|
directories in Docker volumes, perform temporary file system operations
|
|
outside of bind mounts, and use third-party tools like Unison or `rsync` to
|
|
synchronize between container directories and bind-mounted directories. We are
|
|
actively working on performance improvements using a number of different
|
|
techniques. To learn more, see the [topic on our roadmap](https://github.com/docker/roadmap/issues/7).
|
|
{{< /tab >}}
|
|
{{< tab name="For Mac with Apple silicon" >}}
|
|
- On Apple silicon in native `arm64` containers, older versions of `libssl` such as `debian:buster`, `ubuntu:20.04`, and `centos:8` will segfault when connected to some TLS servers, for example, `curl https://dl.yarnpkg.com`. The bug is fixed in newer versions of `libssl` in `debian:bullseye`, `ubuntu:21.04`, and `fedora:35`.
|
|
- Some command line tools do not work when Rosetta 2 is not installed.
|
|
- The old version 1.x of `docker-compose`. Use Compose V2 instead. Either type `docker compose` or enable the **Use Docker Compose V2** option in the [General preferences tab](../settings/mac.md#general).
|
|
- The `docker-credential-ecr-login` credential helper.
|
|
- Some images do not support the ARM64 architecture. You can add `--platform linux/amd64` to run (or build) an Intel image using emulation.
|
|
|
|
However, attempts to run Intel-based containers on Apple silicon machines under emulation can crash as qemu sometimes fails to run the container. In addition, filesystem change notification APIs (`inotify`) do not work under qemu emulation. Even when the containers do run correctly under emulation, they will be slower and use more memory than the native equivalent.
|
|
|
|
In summary, running Intel-based containers on Arm-based machines should be regarded as "best effort" only. We recommend running arm64 containers on Apple silicon machines whenever possible, and encouraging container authors to produce arm64, or multi-arch, versions of their containers. This issue should become less common over time, as more and more images are rebuilt [supporting multiple architectures](https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/).
|
|
- `ping` from inside a container to the Internet does not work as expected. To test the network, use `curl` or `wget`. See [docker/for-mac#5322](https://github.com/docker/for-mac/issues/5322#issuecomment-809392861).
|
|
- Users may occasionally experience data drop when a TCP stream is half-closed.
|
|
{{< /tab >}}
|
|
{{< /tabs >}} |