Muitos plugins guardam dados de forma permanente: permissões, saldos, registos ou o histórico de ações de construção. Para isso, usam uma base de dados MySQL ou MariaDB, acedida através da rede, ou ficheiros na própria pasta em plugins/, por exemplo uma base de dados SQLite ou H2, ou seja, uma base de dados completa num único ficheiro. Se a abertura ou a gravação falhar, o plugin fica sem os seus dados ou as alterações novas perdem-se.

Cada secção abaixo trata de uma mensagem. Encontras a mensagem completa na Consola ou em Ficheiros, em logs/latest.log. As linhas imediatamente a seguir indicam muitas vezes a causa exata. Antes de qualquer intervenção em pastas de plugins, ficheiros de base de dados ou configurações, cria uma cópia em Cópias de segurança e só elimines ou movas ficheiros de base de dados com o servidor parado.

A base de dados recusa o acesso: utilizador ou palavra-passe incorretos

Assim se apresenta a mensagem:

java.sql.SQLException: Access denied for user '<User>'@'<Address>' (using password: YES)

O que está por trás disto: Um plugin como o LuckPerms ou o CoreProtect quer ligar-se à sua base de dados MySQL ou MariaDB, mas o nome de utilizador ou a palavra-passe não estão corretos. A base de dados rejeita o início de sessão. Assim, o plugin não consegue carregar nem guardar dados: consoante o plugin, ou nem arranca ou funciona sem as suas permissões, saldos ou registos, e as novas alterações não chegam à base de dados. Se no final aparecer using password: NO, não há qualquer palavra-passe indicada na configuração.

Como resolver:

  1. Consulta em Bases de dados ou no teu add-on de base de dados quais são as credenciais válidas: anfitrião, porta, nome da base de dados, utilizador e palavra-passe.
  2. Abre em Ficheiros a configuração do plugin, no caso do LuckPerms, por exemplo, plugins/LuckPerms/config.yml, secção data.
  3. Introduz todos os valores exatamente como aparecem no painel. Atenção a maiúsculas e minúsculas e a espaços no final.
  4. Se a palavra-passe contiver carateres especiais como # ou :, coloca-a entre aspas simples. Caso contrário, o YAML, o formato de texto destes ficheiros, interpreta o valor de forma errada.
  5. Guarda o ficheiro e reinicia o servidor.

Bom saber: Se a palavra-passe da base de dados tiver sido redefinida, a antiga deixa de ser válida em qualquer configuração de plugin. Introduz a nova em todos os sítios onde a base de dados é utilizada.

O spark não consegue criar os seus ficheiros temporários

Assim se apresenta a mensagem:

[spark] Exception occurred while rotating profiler job
java.lang.RuntimeException: Unable to create temporary output file
[spark] Failed to stop previous profiler job

O que está por trás disto: O spark é um profiler, ou seja, uma ferramenta de medição que regista em que o servidor gasta o seu tempo de processamento. O spark guarda os seus ficheiros temporários na pasta plugins/spark/tmp-client. Se esta pasta não existir, todas as medições falham e o spark tenta novamente a cada minuto. É por isso que surgem tantas mensagens iguais. O teu servidor continua a funcionar sem ser afetado e não se trata de um problema de espaço de armazenamento nem de permissões.

Como resolver:

  1. O mais rápido é usar o botão «Corrigir automaticamente» junto à mensagem em Saúde do servidor.
  2. Manualmente: abre Ficheiros, muda para a pasta plugins/spark e cria lá a pasta tmp-client. Respeita a grafia exata.
  3. Observa a Consola durante alguns minutos. As mensagens deverão deixar de aparecer.

Bom saber: Reiniciar por si só não resolve, porque o spark não volta a criar a pasta sozinho. Para saberes como usar o spark na procura de lag, vê spark: encontrar e compreender o lag.

Um plugin não consegue aceder à sua base de dados

Assim se apresenta a mensagem:

<Plugin>-hikari - Connection is not available, request timed out after <Time>ms.
com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link failure
[LuckPerms] Failed to init storage

O que está por trás disto: O plugin não consegue estabelecer ligação à sua base de dados MySQL ou MariaDB. Causas típicas: o anfitrião na configuração está errado, a base de dados está parada ou uma ligação existente foi interrompida. «Hikari» é o pool de ligações que mantém as ligações à base de dados disponíveis para o plugin. Enquanto isto se mantiver, o plugin fica sem os seus dados.

Como resolver:

  1. Verifica se o teu add-on de base de dados está a funcionar.
  2. Compara o anfitrião e a porta na configuração do plugin com os dados indicados em Bases de dados ou no add-on. Não introduzas simplesmente localhost, mas sim exatamente o anfitrião indicado no painel.
  3. Reinicia o servidor e observa as mensagens de arranque do plugin na Consola.
  4. Se não precisares de uma base de dados própria, muda o plugin para armazenamento local, no caso do LuckPerms com storage-method: h2 em plugins/LuckPerms/config.yml. Os dados da base de dados não são transferidos automaticamente.

Bom saber: Se a seguir a «Error whilst saving group» surgir o aviso «Value too long», a culpa não é da ligação. Nesse caso, uma entrada é mais longa do que os 200 carateres previstos pelo LuckPerms, por exemplo um prefixo com muitas indicações de cor. Encurta-a.

O Grim não consegue abrir a sua base de dados de histórico

Assim se apresenta a mensagem:

IMPORTANT: Could not load SQLite driver for /grim history database.
Download the minecraft-sqlite-jdbc mod/plugin …, or change history.database.type
Alternatively set history.enabled=false to remove this message …

O que está por trás disto: O Grim é um plugin anti-cheat. Com /grim history mostra avaliações anteriores sobre um jogador e guarda-as para isso numa base de dados SQLite, uma base de dados num único ficheiro. Para a abrir, o Grim precisa de um driver SQLite, um pequeno pacote adicional para o acesso à base de dados. Este driver não existe, por isso a base de dados de histórico não está disponível.

Como resolver:

  1. Instala em Plugins ou Mods a dependência minecraft-sqlite-jdbc na versão que corresponde à tua versão do Grim.
  2. Em alternativa, escolhe na configuração do Grim, em history.database.type, outra base de dados de histórico.
  3. Se não precisares do histórico, desativa-o: na configuração é o valor enabled na secção history; a mensagem escreve-o como history.enabled=false.
  4. Pára o servidor por completo e volta a iniciá-lo.

Bom saber: A mensagem aparece em cada arranque até aplicares uma das três soluções.

O LuckPerms não consegue atualizar a sua base de dados

Assim se apresenta a mensagem:

[LuckPerms] Something went wrong whilst upgrading the LuckPerms database. Please report this on GitHub.
org.h2.jdbc.JdbcSQLSyntaxErrorException: Sequence "<Name>" already exists; SQL statement:

O que está por trás disto: Numa mudança de versão, o LuckPerms adapta a estrutura da sua base de dados à nova versão. Este passo não foi concluído por completo. A linha imediatamente a seguir, normalmente uma mensagem do H2 ou de SQL, indica o passo que falhou. O H2 é o ficheiro de base de dados que o LuckPerms cria na pasta plugins/LuckPerms quando não tem uma base de dados MySQL própria.

Como resolver:

  1. Pára o servidor e cria uma cópia de segurança em Cópias de segurança antes de tentares novamente.
  2. Atualiza o LuckPerms para uma build atual que corresponda ao teu software de servidor e à tua versão.
  3. Não elimines nem edites manualmente os ficheiros da base de dados.
  4. Se o erro voltar a ocorrer, restaura a cópia de segurança. Depois disso, ajudam a migração oficial do LuckPerms ou o suporte do LuckPerms.

Bom saber: Enquanto o LuckPerms ainda estiver em execução, guarda com lp export <File> todas as permissões e grupos adicionalmente num ficheiro. lp import <File> volta a importá-los mais tarde.

Pormenores: Atualizar o LuckPerms em segurança: plataforma, cópia de segurança e permissões

Falta a pasta da base de dados de um plugin

Assim se apresenta a mensagem:

java.sql.SQLException: path to 'plugins/<Plugin>/databases/<File>.db': '/home/container/plugins/<Plugin>/databases' does not exist

O que está por trás disto: O plugin guarda os seus dados numa base de dados SQLite, ou seja, num único ficheiro na pasta do plugin. O ficheiro em si ele consegue criar, mas a pasta para o conter, não. Enquanto esta pasta não existir, o plugin não consegue carregar nem guardar nada, por exemplo saldos, kits ou warps. Isto pode acontecer, por exemplo, se uma pasta de plugin tiver sido eliminada ou carregada apenas parcialmente.

Como resolver:

  1. Lê na mensagem a pasta indicada a seguir aos dois pontos, no exemplo plugins/<Plugin>/databases.
  2. Abre Ficheiros e cria exatamente essa pasta. Atenção a maiúsculas e minúsculas: Databases e databases são pastas diferentes.
  3. Reinicia o servidor e verifica se a mensagem deixa de aparecer.

Bom saber: /home/container é o diretório de topo que vês em Ficheiros. Esta parte do caminho omite-se ao criar a pasta.

Um plugin envia comandos SQLite que só o MySQL conhece

Este é o aspeto da mensagem:

[SQLITE_ERROR] SQL error or missing database (near "<Palavra>": syntax error)

O que está por detrás: o SQLite e o MySQL falam quase, mas não exatamente, a mesma linguagem de base de dados. O plugin guarda os seus dados em SQLite, mas envia comandos que só o MySQL entende. Trata-se de um erro do plugin, não dos teus ficheiros ou definições. As funções afetadas não guardam nada. A palavra a seguir a near indica em que ponto o SQLite não entendeu o comando.

Como resolver:

  1. Atualiza o plugin em Plugins para a versão mais recente para a versão do teu servidor. Talvez o erro já esteja corrigido aí.
  2. Se o plugin oferecer MySQL como armazenamento, cria uma base de dados em Bases de dados, desde que o teu plano inclua bases de dados.
  3. Na configuração do plugin, muda o armazenamento para MySQL, introduz os dados de acesso e reinicia o servidor.
  4. Se nenhuma das opções ajudar, comunica o erro ao autor do plugin e anexa a linha do log.

Bom saber: ao mudar para MySQL, um plugin normalmente não migra por si os dados SQLite anteriores, a menos que ofereça uma função própria para isso.

O EzShops ou o Jaloquent não conseguem aceder ao seu armazenamento

Este é o aspeto da mensagem:

[EzShops] Failed to initialise Jaloquent for player shops; falling back to YAML
com.github.ezframework.jaloquent.exception.StorageException: Failed to begin transaction

O que está por detrás: o Jaloquent é a biblioteca de armazenamento através da qual o EzShops guarda as lojas dos jogadores numa base de dados. Aqui, o Jaloquent não conseguiu iniciar uma transação, ou seja, uma operação de escrita coesa, ou o EzShops nem sequer conseguiu configurar o seu armazenamento Jaloquent. A causa real é indicada na mensagem de erro logo a seguir. O EzShops pode recorrer parcialmente a ficheiros YAML, e os dados ficam então em ficheiros em vez de na base de dados.

Como resolver:

  1. Em logs/latest.log, lê a mensagem de erro logo abaixo desta linha. Ela indica a causa na base de dados ou no armazenamento, por exemplo “Access denied” ou “Communications link failure”.
  2. Verifica se o teu add-on de base de dados está a funcionar.
  3. Confirma o host, a porta e os dados de acesso na configuração do plugin afetado.
  4. Se o EzShops recorreu a YAML, cria uma cópia de segurança em Cópias de segurança antes de alterares algo. Assim, as lojas que entretanto foram guardadas em YAML são preservadas.
  5. Reinicia o servidor.

O PvPManager não encontra a sua pasta da base de dados

Este é o aspeto da mensagem:

[PvPManager] Failed to batch update database
java.sql.SQLException: path to 'plugins/PvPManager/database.db': '<Caminho>' does not exist

O que está por detrás: o PvPManager gere o combate entre jogadores e guarda os dados dos jogadores na base de dados SQLite plugins/PvPManager/database.db. No entanto, a pasta plugins/PvPManager não existe no sistema de ficheiros do servidor. Por isso, o PvPManager não consegue abrir nem escrever na sua base de dados, e os novos dados não são guardados.

Como resolver:

  1. Pára o servidor.
  2. Em Ficheiros, cria a pasta plugins/PvPManager e respeita a grafia exata. Em alternativa, reinstala o PvPManager corretamente em Plugins.
  3. Verifica as permissões dos ficheiros: na nova pasta, cria um ficheiro de teste e volta a apagá-lo.
  4. Verifica se ainda há espaço livre suficiente.
  5. Inicia o servidor e verifica se a mensagem deixa de aparecer.

Bom saber: se o armazenamento estiver cheio, consulta Espaço de armazenamento cheio: resolver “No space left on device”.

O EssentialsX não consegue guardar a sua cache de UUID

Este é o aspeto da mensagem:

[Essentials] Error while saving Name->UUID cache
java.io.IOException: No such file or directory

O que está por detrás: o EssentialsX memoriza que nome de jogador corresponde a que UUID, o identificador fixo de uma conta Minecraft. Escreve esta lista como cache, ou seja, uma memória intermédia, na sua pasta de dados e para isso cria primeiro um ficheiro temporário. Isto falha porque a pasta plugins/Essentials não existe ou não permite escrita. Se a pasta realmente não existir, o EssentialsX também não consegue guardar aí os seus restantes dados.

Como resolver:

  1. Abre Ficheiros e verifica se a pasta plugins/Essentials existe. Se não existir, cria-a.
  2. Verifica se permite escrita: cria lá dentro um ficheiro de teste e volta a apagá-lo.
  3. Atualiza o EssentialsX em Plugins para uma versão compatível com a versão do teu servidor.
  4. Reinicia o servidor.

Bom saber: se não for possível criar um ficheiro na pasta, esta provavelmente não pertence ao utilizador com o qual o teu servidor é executado. Se não conseguires avançar, abre um ticket e indica a hora da mensagem.

FastAsyncWorldEdit: um ficheiro de histórico está danificado

Este é o aspeto da mensagem:

Could not load block history file plugins/FastAsyncWorldEdit/history/<Pasta>/<Ficheiro>
An unexpected error while handling a FastAsyncWorldEdit command
java.io.EOFException: Stream ended prematurely

O que está por detrás: o FastAsyncWorldEdit, abreviadamente FAWE, guarda um ficheiro de histórico das ações de construção, para que possas anulá-las com //undo. Um destes ficheiros está incompleto, normalmente porque o servidor foi parado enquanto o FAWE ainda estava a escrever. Precisamente esse //undo deixa então de ser possível. O teu mundo não é afetado e o servidor continua a funcionar normalmente.

Como resolver:

  1. Normalmente não é necessário fazer nada. A mensagem diz respeito apenas a esse passo do histórico.
  2. Se se repetir, pára o servidor.
  3. Em Ficheiros, apaga a pasta indicada na mensagem dentro de plugins/FastAsyncWorldEdit/history.
  4. Volta a iniciar o servidor.

Bom saber: depois de apagar, as ações dessa pasta já não podem ser anuladas. Mais sobre //undo: WorldEdit: construir e anular.

WorldEdit: não é possível carregar a área de transferência guardada

Este é o aspeto da mensagem:

Error loading clipboard from disk
… Size exceeds Integer.MAX_VALUE

O que está por detrás: o FAWE pode guardar no disco a área de transferência de um jogador. A área de transferência guardada não pôde ser carregada: ou é demasiado grande, e nesse caso a mensagem contém “Size exceeds Integer.MAX_VALUE”, ou está danificada. O jogador tem de voltar a copiar a sua seleção. O mundo e o servidor não são afetados.

Como resolver:

  1. Pára o servidor.
  2. Em Ficheiros, abre a pasta plugins/FastAsyncWorldEdit/clipboard.
  3. Apaga o ficheiro do jogador afetado. O nome contém normalmente a sua UUID, o identificador fixo da sua conta Minecraft.
  4. Volta a iniciar o servidor e pede ao jogador que copie novamente a seleção.

Bom saber: cópias muito grandes é melhor guardá-las como schematic, ou seja, como ficheiro de planta próprio, por exemplo com //schem save <Nome>. Podes voltar a carregá-la para a área de transferência, quando precisares, com //schem load <Nome>.

WorldEdit: Uma schematic contém uma entidade sem posição

Este é o aspeto da mensagem:

Failed to load a saved clipboard
java.io.IOException: Missing position for entity <Entidade>

O que está por trás disto: As entidades são tudo o que existe no mundo e que não é um bloco, como animais, suportes de armadura ou molduras. A schematic guardada, ou seja, o ficheiro de planta da construção, contém uma entidade sem indicação de posição. Por isso, o WorldEdit não consegue carregar a schematic por completo. O teu mundo não é afetado, apenas esta schematic não pode ser colada corretamente.

Como resolver:

  1. Se a construção ainda estiver num mundo, seleciona-a novamente com o WorldEdit e copia-a com //copy sem a opção -e. Assim, as entidades ficam de fora.
  2. Guarda a nova cópia com //schem save <Nome> com um nome novo e usa este ficheiro a partir de agora.
  3. Se só tiveres o ficheiro, abre-o num editor de schematics e remove a entidade danificada.
  4. Depois, carrega a schematic com //schem load <Nome> e verifica se a mensagem deixa de aparecer.

Bom saber: Se não precisares de animais ou molduras na construção, guardar sem entidades é o caminho mais rápido.

Falta uma pasta de cache

Este é o aspeto da mensagem:

java.nio.file.NoSuchFileException: /home/container/.cache/<Ficheiro>

O que está por trás disto: Um mod ou um launcher, ou seja, um programa de arranque, queria guardar ficheiros na pasta .cache no diretório principal do teu servidor. No entanto, essa pasta não existe. Isto acontece normalmente após uma reinstalação ou quando a pasta foi eliminada durante uma limpeza. Muitas vezes resolve-se sozinho, porque o arranque seguinte volta a criar a pasta.

Como resolver:

  1. Reinicia o servidor uma vez. Na maioria dos casos, a mensagem desaparece depois disso.
  2. Se continuar, abre Ficheiros e cria uma pasta de teste no diretório principal. Se não funcionar, o diretório não tem permissão de escrita.
  3. Verifica se ainda tens espaço de armazenamento suficiente. Um armazenamento cheio também impede a criação de pastas.
  4. Se não conseguires avançar, abre um ticket e indica a hora da mensagem.

Bom saber: Se o armazenamento estiver cheio, o guia Armazenamento cheio: resolver o erro „No space left on device“ pode ajudar.

O plugin de homes não consegue guardar um ponto de teletransporte

Este é o aspeto da mensagem:

Failed to create home for player <ID do jogador> in the database.

O que está por trás: Um home é um ponto de teletransporte guardado. O plugin responsável tenta criar uma nova entrada na sua base de dados e falha. A nova entrada de home não é guardada; o servidor continua a funcionar. A causa concreta na base de dados costuma constar nas mensagens de erro adjacentes.

Como resolver:

  1. Na Consola ou em Ficheiros, abre em logs/latest.log as linhas imediatamente antes e depois da mensagem. Procura o nome do plugin e a respetiva mensagem de erro da base de dados.
  2. Verifica a configuração de armazenamento deste plugin. Se utilizar uma base de dados externa, compara o endereço, a base de dados e as credenciais de acesso com Bases de dados.
  3. Faz uma cópia de segurança da base de dados existente antes de alterares as respetivas definições ou tabelas. Depois, corrige o erro concreto indicado, seguindo a documentação do plugin.
  4. Tenta criar o home novamente. Se o erro persistir, comunica-o ao autor com o rasto de erro completo e a hora.

Convém saber: Eliminar a base de dados remove também os homes já guardados.

A tua mensagem não está aqui?

Lê a mensagem completa em logs/latest.log, incluindo as linhas antes e depois. Nos erros de base de dados, a causa real surge muitas vezes numa linha com „Caused by“. O plugin afetado é indicado pelo nome entre parênteses retos e pelos nomes das pastas no stacktrace, ou seja, nas linhas at … por baixo da mensagem, por exemplo me/lucko/luckperms para o LuckPerms. Verifica depois os dados de acesso, as pastas e o espaço livre. Cria uma cópia de segurança antes de qualquer intervenção. Se não conseguires avançar, abre um ticket e indica a hora da mensagem.