Felsökning

Problem som uppstår när Ayakaleaf Pro körs med Docker Desktop på macOS, och hur du kontrollerar dem.

​

Initieringen misslyckas med invalid command code

bin/init rapporterar sed: ... invalid command code när det hittar macOS BSD sed. Lägg GNU sed i PATH som i 1. Ladda ner Toolkit och kontrollera sed --version.

En misslyckad initiering kan lämna alla tre filerna i config/ med en tom OVERLEAF_INVITE_TOKEN_SECRET. Om du kör bin/init igen rapporteras då Config files already exist. För en ny installation som aldrig har startats flyttar du de tre filerna till en säkerhetskopieringskatalog och kör bin/init igen. För en befintlig instans behåller du dess konfiguration och hemligheter, och tar inte bort dess filer för att få bin/init att köras igen.

​

MongoDB startar om hela tiden

Läs MongoDB-loggarna och kärnversionen för Docker-VM:en:

bin/docker-compose logs --tail=100 mongo
docker info --format '{{.KernelVersion}}'

Om loggen nämner inkompatibiliteten med Linux-kärnan följer du Kontrollera Linux-kärnan i Docker-VM:en och kör bin/up -d igen. Avslutningskoden 137 ensam bevisar inte att MongoDB fick slut på minne: kontrollera containerns tillstånd och loggarna. För ett äldre MongoDB-problem på Docker Desktop, se även Felsökning.

​

Det går inte att ansluta till Docker-daemonen

Starta Docker Desktop och kontrollera den valda Docker-kontexten, se 0. Installera Docker Desktop. Om docker info fungerar men kompileringar inte når Docker kontrollerar du socket-inställningarna i config/overleaf.rc och läser clsi-loggarna. Att Docker CLI fungerar på din Mac bevisar inte att applikationens socket-montering är korrekt.

​

Sidan öppnas, men kompileringar misslyckas

Kontrollera att TeX Live-avbildningen finns lokalt och matchar Docker-motorns arkitektur:

docker image inspect ghcr.io/ayaka-notes/texlive-full:2026.1 \
  --format '{{.Os}}/{{.Architecture}}'
bin/logs -f clsi

På Apple silicon ska avbildningen vara linux/arm64. Kontrollera att SERVER_PRO och SIBLING_CONTAINERS_ENABLED båda är true och tillämpa sedan ändringarna med bin/up -d. Om loggarna rapporterar en saknad kompileringskatalog kontrollerar du Docker Desktops fildelning och platsen för OVERLEAF_DATA_PATH. Stäng inte av sandlådekompilering för att dölja ett monteringsfel.

​

Not a directory, eller en bind-montering saknas

En värdfil som en override monterar kan ha tagits bort, eller så kan Docker ha skapat en katalog där filen borde finnas. Kontrollera källsökvägen på värden och om monteringen förväntar sig en fil eller en katalog. Återställ konfigurationsfilen innan du återskapar containern. En installation under /tmp kan råka ut för detta efter att macOS har tagit bort temporära filer.

​

Konflikter med port eller containernamn

Om port 8080 används väljer du en annan port i config/overleaf.rc, anger OVERLEAF_SITE_URL så att den matchar och kör bin/up -d igen.

Toolkit ger sina containrar fasta namn som sharelatex, mongo och redis. Att bara ändra PROJECT_NAME gör inte två Toolkit-installationer oberoende av varandra. Innan du startar en andra instans kontrollerar du docker ps -a och använder andra containernamn i en Compose-override, en annan port och separata datakataloger. Ta inte bort containrar eller data från en befintlig driftsättning för att lösa en namnkonflikt.

​

Instansen går inte att nå efter en stund

Din Mac har förmodligen gått i viloläge, eller så har Docker Desktop avslutats. Se Håll instansen tillgänglig.

​

bin/doctor säger att detta inte är Linux, eller ber om en Quay-inloggning

Båda varningarna är förväntade på macOS med den publika avbildningen, se 2. Bekanta dig med Toolkit. Kontrollera i stället hämtningen av avbildningar, tjänsternas status och kompileringsresultaten, och ignorera inte andra fel i rapporten.