La inicialización falla con invalid command code
bin/init informa de sed: ... invalid command code cuando encuentra el sed BSD de macOS. Pon GNU sed en el PATH como en 1. Descargar el Toolkit y comprueba sed --version.
Una inicialización fallida puede dejar los tres archivos de config/ con un OVERLEAF_INVITE_TOKEN_SECRET vacío. Al volver a ejecutar bin/init, se informa de Config files already exist. Para una instalación nueva que nunca se ha iniciado, mueve los tres archivos a un directorio de copia de seguridad y vuelve a ejecutar bin/init. Para una instancia existente, conserva su configuración y sus secretos, y no elimines sus archivos para que bin/init vuelva a ejecutarse.
MongoDB se reinicia continuamente
Lee los registros de MongoDB y la versión del kernel de la máquina virtual de Docker:
Si el registro menciona la incompatibilidad con el kernel Linux, sigue Comprobar el kernel Linux de la máquina virtual de Docker y vuelve a ejecutar bin/up -d. El código de salida 137 por sí solo no demuestra que MongoDB se haya quedado sin memoria: comprueba el estado del contenedor y los registros. Para un problema más antiguo de MongoDB en Docker Desktop, consulta también Solución de problemas.
No se puede conectar con el daemon de Docker
Inicia Docker Desktop y comprueba el contexto de Docker seleccionado; consulta 0. Configurar Docker Desktop. Si docker info funciona pero las compilaciones no pueden acceder a Docker, comprueba los ajustes del socket en config/overleaf.rc y lee los registros de clsi. Que la CLI de Docker funcione en el Mac no demuestra que el montaje del socket de la aplicación sea correcto.
La página se abre, pero las compilaciones fallan
Comprueba que la imagen de TeX Live existe localmente y coincide con la arquitectura del motor de Docker:
En Apple silicon, la imagen debería ser linux/arm64. Comprueba que SERVER_PRO y SIBLING_CONTAINERS_ENABLED son ambos true y, a continuación, aplica los cambios con bin/up -d. Si los registros informan de que falta un directorio de compilación, comprueba el uso compartido de archivos de Docker Desktop y la ubicación de OVERLEAF_DATA_PATH. No desactives la compilación en sandbox para ocultar un fallo de montaje.
Not a directory, o falta un bind mount
Es posible que se haya eliminado un archivo del host que monta un override, o que Docker haya creado un directorio donde debería estar el archivo. Comprueba la ruta de origen en el host y si el montaje espera un archivo o un directorio. Restaura el archivo de configuración antes de volver a crear el contenedor. Una instalación en /tmp puede encontrarse con esto después de que macOS elimine los archivos temporales.
Conflictos de puerto o de nombre de contenedor
Si el puerto 8080 está en uso, elige otro puerto en config/overleaf.rc, ajusta OVERLEAF_SITE_URL en consecuencia y vuelve a ejecutar bin/up -d.
El Toolkit asigna a sus contenedores nombres fijos, como sharelatex, mongo y redis. Cambiar solo PROJECT_NAME no hace que dos instalaciones del Toolkit sean independientes. Antes de iniciar una segunda instancia, comprueba docker ps -a y usa otros nombres de contenedor en un override de Compose, otro puerto y directorios de datos separados. No elimines los contenedores ni los datos de un despliegue existente para resolver un conflicto de nombres.
La instancia deja de ser accesible al cabo de un tiempo
Probablemente el Mac entró en reposo o se cerró Docker Desktop. Consulta Mantener la instancia disponible.
bin/doctor indica que esto no es Linux, o pide iniciar sesión en Quay
Ambas advertencias son esperables en macOS con la imagen pública; consulta 2. Familiarízate con el Toolkit. En su lugar, comprueba las descargas de imágenes, el estado de los servicios y los resultados de compilación, y no ignores otros errores del informe.Última modificación el 8 de noviembre de 2026
