# Problemas conocidos


**Para Mac con chip Intel**


- El Monitor de Actividad de Mac informa que Docker utiliza el doble de la cantidad de memoria que realmente está consumiendo. Esto se debe a un [error en macOS](https://docs.google.com/document/d/17ZiQC1Tp9iH320K-uqVLyiJmk4DHJ3c4zgQetJiKYQM/edit?usp=sharing).

- **Diálogo "Docker.app está dañada"**: Si ves el diálogo "Docker.app está dañada y no se puede abrir" durante la instalación o actualización, esto suele ser causado por operaciones de copia no atómicas cuando otras aplicaciones están utilizando la CLI de Docker. Consulta [Solucionar "Docker.app está dañada" en macOS](/desktop/troubleshoot-and-support/troubleshoot/known-issues/mac-damaged-dialog/) para ver los pasos de resolución.

- Expulsar a la fuerza el `.dmg` después de ejecutar `Docker.app` desde él puede hacer que el icono de la ballena deje de responder, que las tareas de Docker aparezcan como "no responde" en el Monitor de Actividad y que algunos procesos consuman una gran cantidad de recursos de CPU. Reinicia la máquina y vuelve a iniciar Docker para resolver estos problemas.

- Docker Desktop utiliza el hipervisor `HyperKit` (https://github.com/docker/hyperkit) en macOS 10.10 Yosemite y versiones superiores. Si estás desarrollando con herramientas que presentan conflictos con `HyperKit`, como [Intel Hardware Accelerated Execution Manager (HAXM)](https://software.intel.com/en-us/android/articles/intel-hardware-accelerated-execution-manager/), la solución temporal actual consiste en no ejecutarlos al mismo tiempo. Puedes pausar `HyperKit` saliendo temporalmente de Docker Desktop mientras trabajas con HAXM. Esto te permite seguir trabajando con las otras herramientas y evitar que `HyperKit` interfiera.

- Si estás trabajando con aplicaciones como [Apache Maven](https://maven.apache.org/) que esperan configuraciones para las variables de entorno `DOCKER_HOST` y `DOCKER_CERT_PATH`, especifícalas para conectarte a las instancias de Docker a través de sockets Unix. Por ejemplo:

  ```console
  $ export DOCKER_HOST=unix:///var/run/docker.sock
  ```

**Para Mac con Apple silicon**



- Algunas herramientas de línea de comandos no funcionan si Rosetta 2 no está instalado.
  - La antigua versión 1.x de `docker-compose`. Utiliza Compose V2 en su lugar escribiendo `docker compose`.
  - El ayudante de credenciales `docker-credential-ecr-login`.
- Algunas imágenes no son compatibles con la arquitectura ARM64. Puedes añadir `--platform linux/amd64` para ejecutar (o construir) una imagen de Intel mediante emulación.

   Sin embargo, los intentos de ejecutar contenedores basados en Intel en máquinas con Apple silicon bajo emulación pueden fallar, ya que a veces QEMU no logra ejecutar el contenedor. Además, las API de notificación de cambios en el sistema de archivos (`inotify`) no funcionan bajo la emulación de QEMU. Incluso si los contenedores se ejecutan correctamente bajo emulación, serán más lentos y consumirán más memoria que su equivalente nativo.

   En resumen, la ejecución de contenedores basados en Intel en máquinas basadas en Arm debe considerarse únicamente como "el mejor esfuerzo" (best effort). Recomendamos ejecutar contenedores `arm64` en máquinas con Apple silicon siempre que sea posible, y animar a los creadores de contenedores a producir versiones de sus contenedores para `arm64` o multiarquitectura. Este problema debería ser menos común con el tiempo, a medida que más y más imágenes se vuelvan a construir [admitiendo múltiples arquitecturas](https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/).
- Ocasionalmente, los usuarios pueden experimentar pérdida de datos cuando una transmisión TCP se cierra a medias.