L’initialisation échoue avec invalid command code
bin/init signale sed: ... invalid command code lorsqu’il trouve le sed BSD de macOS. Placez GNU sed dans le PATH comme dans 1. Télécharger le Toolkit et vérifiez sed --version.
Une initialisation ratée peut laisser les trois fichiers dans config/ avec un OVERLEAF_INVITE_TOKEN_SECRET vide. Une nouvelle exécution de bin/init signale alors Config files already exist. Pour une nouvelle installation qui n’a jamais démarré, déplacez les trois fichiers dans un répertoire de sauvegarde et exécutez à nouveau bin/init. Pour une instance existante, conservez sa configuration et ses secrets, et ne supprimez pas ses fichiers pour pouvoir relancer bin/init.
MongoDB redémarre en boucle
Lisez les journaux de MongoDB et la version du noyau de la VM Docker :
Si le journal mentionne l’incompatibilité avec le noyau Linux, suivez Vérifier le noyau Linux de la VM Docker et exécutez à nouveau bin/up -d. Le code de sortie 137 à lui seul ne prouve pas que MongoDB a manqué de mémoire : vérifiez l’état du conteneur et les journaux. Pour un problème MongoDB plus ancien sous Docker Desktop, consultez également Dépannage.
Impossible de se connecter au démon Docker
Démarrez Docker Desktop et vérifiez le contexte Docker sélectionné, voir 0. Installer Docker Desktop. Si docker info fonctionne mais que les compilations ne peuvent pas joindre Docker, vérifiez les paramètres du socket dans config/overleaf.rc et lisez les journaux de clsi. Une CLI Docker fonctionnelle sur le Mac ne prouve pas que le montage du socket de l’application est correct.
La page s’ouvre, mais les compilations échouent
Vérifiez que l’image TeX Live existe en local et correspond à l’architecture du moteur Docker :
Sur Apple silicon, l’image doit être linux/arm64. Vérifiez que SERVER_PRO et SIBLING_CONTAINERS_ENABLED valent tous deux true, puis appliquez les modifications avec bin/up -d. Si les journaux signalent un répertoire de compilation manquant, vérifiez le partage de fichiers de Docker Desktop et l’emplacement de OVERLEAF_DATA_PATH. Ne désactivez pas les compilations en sandbox pour masquer un échec de montage.
Not a directory, ou un bind mount est manquant
Un fichier de l’hôte monté par une surcharge a peut-être été supprimé, ou Docker a peut-être créé un répertoire là où le fichier devrait se trouver. Vérifiez le chemin source sur l’hôte, et si le montage attend un fichier ou un répertoire. Restaurez le fichier de configuration avant de recréer le conteneur. Une installation sous /tmp peut rencontrer ce problème après que macOS a supprimé les fichiers temporaires.
Conflits de port ou de nom de conteneur
Si le port 8080 est utilisé, choisissez un autre port dans config/overleaf.rc, ajustez OVERLEAF_SITE_URL en conséquence et exécutez à nouveau bin/up -d.
Le Toolkit donne à ses conteneurs des noms fixes comme sharelatex, mongo et redis. Modifier uniquement PROJECT_NAME ne rend pas deux installations du Toolkit indépendantes. Avant de démarrer une seconde instance, vérifiez docker ps -a, et utilisez d’autres noms de conteneurs dans une surcharge Compose, un autre port et des répertoires de données distincts. Ne supprimez pas les conteneurs ou les données d’un déploiement existant pour résoudre un conflit de noms.
L’instance devient inaccessible au bout d’un moment
Le Mac s’est probablement mis en veille, ou Docker Desktop a été quitté. Consultez Garder l’instance disponible.
bin/doctor indique que ce n’est pas Linux, ou demande une connexion à Quay
Ces deux avertissements sont attendus sous macOS avec l’image publique, voir 2. Familiarisez-vous avec le Toolkit. Vérifiez plutôt la récupération des images, l’état des services et les résultats de compilation, et n’ignorez pas les autres erreurs du rapport.Dernière modification le 8 novembre 2026
