Solução de problemas

Problemas observados ao executar o Ayakaleaf Pro com o Docker Desktop no macOS e como verificá-los.

​

A inicialização falha com invalid command code

bin/init informa sed: ... invalid command code quando encontra o BSD sed do macOS. Coloque o GNU sed no PATH como em 1. Baixar o Toolkit e verifique sed --version.

Uma inicialização com falha pode deixar os três arquivos em config/ com um OVERLEAF_INVITE_TOKEN_SECRET vazio. Executar bin/init novamente passa então a informar Config files already exist. Para uma nova instalação que nunca foi iniciada, mova os três arquivos para um diretório de backup e execute bin/init novamente. Para uma instância existente, mantenha sua configuração e seus segredos e não exclua os arquivos dela para fazer o bin/init rodar novamente.

​

O MongoDB continua reiniciando

Leia os logs do MongoDB e a versão do kernel da VM do Docker:

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

Se o log mencionar a incompatibilidade com o kernel Linux, siga Verificar o kernel Linux da VM do Docker e execute bin/up -d novamente. O código de saída 137 sozinho não prova que o MongoDB ficou sem memória: verifique o estado do contêiner e os logs. Para um problema mais antigo do MongoDB no Docker Desktop, consulte também Solução de problemas.

​

Não é possível conectar ao daemon do Docker

Inicie o Docker Desktop e verifique o contexto do Docker selecionado; consulte 0. Configurar o Docker Desktop. Se docker info funcionar, mas as compilações não conseguirem acessar o Docker, verifique as configurações do socket em config/overleaf.rc e leia os logs do clsi. Uma CLI do Docker funcionando no Mac não prova que a montagem do socket da aplicação está correta.

​

A página abre, mas as compilações falham

Verifique se a imagem do TeX Live existe localmente e corresponde à arquitetura do engine do Docker:

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

No Apple silicon, a imagem deve ser linux/arm64. Verifique se SERVER_PRO e SIBLING_CONTAINERS_ENABLED estão ambos como true e, em seguida, aplique as alterações com bin/up -d. Se os logs indicarem um diretório de compilação ausente, verifique o compartilhamento de arquivos do Docker Desktop e o local de OVERLEAF_DATA_PATH. Não desative as compilações em sandbox para esconder uma falha de montagem.

​

Not a directory, ou uma montagem bind está ausente

Um arquivo do host que um override monta pode ter sido excluído, ou o Docker pode ter criado um diretório onde deveria estar o arquivo. Verifique o caminho de origem no host e se a montagem espera um arquivo ou um diretório. Restaure o arquivo de configuração antes de recriar o contêiner. Uma instalação em /tmp pode enfrentar isso depois que o macOS remove os arquivos temporários.

​

Conflitos de porta ou de nome de contêiner

Se a porta 8080 estiver em uso, escolha outra porta em config/overleaf.rc, ajuste OVERLEAF_SITE_URL de acordo e execute bin/up -d novamente.

O Toolkit dá aos seus contêineres nomes fixos, como sharelatex, mongo e redis. Alterar apenas PROJECT_NAME não torna duas instalações do Toolkit independentes. Antes de iniciar uma segunda instância, verifique docker ps -a e use outros nomes de contêiner em um override do Compose, outra porta e diretórios de dados separados. Não remova os contêineres nem os dados de uma implantação existente para resolver um conflito de nomes.

​

A instância fica inacessível depois de um tempo

Provavelmente o Mac entrou em repouso ou o Docker Desktop foi encerrado. Consulte Manter a instância disponível.

​

bin/doctor diz que isto não é Linux ou pede um login no Quay

Ambos os avisos são esperados no macOS com a imagem pública; consulte 2. Familiarize-se com o Toolkit. Em vez disso, verifique o download das imagens, o status dos serviços e os resultados das compilações, e não ignore os demais erros do relatório.