Die Initialisierung schlägt mit „invalid command code“ fehl
bin/init meldet sed: ... invalid command code, wenn es das BSD sed von macOS findet. Nehmen Sie GNU sed wie unter 1. Toolkit herunterladen beschrieben in den PATH auf und prüfen Sie sed --version.
Eine fehlgeschlagene Initialisierung kann alle drei Dateien in config/ mit einem leeren OVERLEAF_INVITE_TOKEN_SECRET hinterlassen. Ein erneuter Aufruf von bin/init meldet dann Config files already exist. Verschieben Sie bei einer Neuinstallation, die noch nie gestartet wurde, die drei Dateien in ein Backup-Verzeichnis und führen Sie bin/init erneut aus. Bei einer bestehenden Instanz behalten Sie deren Konfiguration und Secrets bei und löschen Sie ihre Dateien nicht, nur damit bin/init erneut läuft.
MongoDB startet ständig neu
Lesen Sie die MongoDB-Logs und die Kernel-Version der Docker-VM:
Wenn das Log die Inkompatibilität mit dem Linux-Kernel nennt, folgen Sie Den Linux-Kernel der Docker-VM prüfen und führen Sie bin/up -d erneut aus. Der Exit-Code 137 allein beweist nicht, dass MongoDB der Speicher ausgegangen ist: Prüfen Sie den Containerstatus und die Logs. Zu einem älteren MongoDB-Problem unter Docker Desktop siehe auch Fehlerbehebung.
Keine Verbindung zum Docker-Daemon
Starten Sie Docker Desktop und prüfen Sie den ausgewählten Docker-Kontext, siehe 0. Docker Desktop einrichten. Wenn docker info funktioniert, Kompilierungen Docker aber nicht erreichen, prüfen Sie die Socket-Einstellungen in config/overleaf.rc und lesen Sie die clsi-Logs. Eine funktionierende Docker-CLI auf dem Mac beweist nicht, dass der Socket-Mount der Anwendung korrekt ist.
Die Seite öffnet sich, aber Kompilierungen schlagen fehl
Prüfen Sie, ob das TeX Live-Image lokal vorhanden ist und zur Architektur der Docker-Engine passt:
Auf Apple Silicon sollte das Image linux/arm64 sein. Prüfen Sie, ob SERVER_PRO und SIBLING_CONTAINERS_ENABLED beide true sind, und übernehmen Sie Änderungen dann mit bin/up -d. Wenn die Logs ein fehlendes Kompilierungsverzeichnis melden, prüfen Sie die Dateifreigabe von Docker Desktop und den Speicherort OVERLEAF_DATA_PATH. Deaktivieren Sie Sandboxed Compiles nicht, um einen Mount-Fehler zu verbergen.
„Not a directory“ oder ein fehlender Bind-Mount
Eine Host-Datei, die ein Override einbindet, wurde möglicherweise gelöscht, oder Docker hat dort, wo die Datei sein sollte, ein Verzeichnis angelegt. Prüfen Sie den Quellpfad auf dem Host und ob der Mount eine Datei oder ein Verzeichnis erwartet. Stellen Sie die Konfigurationsdatei wieder her, bevor Sie den Container neu erstellen. Eine Installation unter /tmp kann hierauf stoßen, nachdem macOS temporäre Dateien entfernt hat.
Port- oder Containernamenskonflikte
Wenn Port 8080 belegt ist, wählen Sie in config/overleaf.rc einen anderen Port, passen Sie OVERLEAF_SITE_URL entsprechend an und führen Sie bin/up -d erneut aus.
Das Toolkit gibt seinen Containern feste Namen wie sharelatex, mongo und redis. Das Ändern von PROJECT_NAME allein macht zwei Toolkit-Installationen nicht unabhängig voneinander. Bevor Sie eine zweite Instanz starten, prüfen Sie docker ps -a und verwenden Sie in einem Compose-Override andere Containernamen, einen anderen Port und separate Datenverzeichnisse. Entfernen Sie nicht die Container oder Daten einer bestehenden Bereitstellung, um einen Namenskonflikt zu lösen.
Die Instanz ist nach einer Weile nicht mehr erreichbar
Wahrscheinlich ist der Mac in den Ruhezustand gegangen oder Docker Desktop wurde beendet. Siehe Die Instanz verfügbar halten.
bin/doctor meldet, dass dies kein Linux ist, oder verlangt eine Quay-Anmeldung
Beide Warnungen sind unter macOS mit dem öffentlichen Image zu erwarten, siehe 2. Machen Sie sich mit dem Toolkit vertraut. Prüfen Sie stattdessen die Image-Downloads, den Dienststatus und die Kompilierungsergebnisse, und ignorieren Sie keine anderen Fehler im Bericht.Zuletzt geändert am 8. November 2026
