Como resolver erros de permissão de arquivo no Linux ao rodar um servidor de MU Online

Resposta rápida

Todo administrador de servidor de MU Online que migra do Windows para o Linux — seja para hospedar em uma VPS mais barata, seja para rodar o GameServer via Wine em um container Docker — esbarra cedo ou tarde em um erro de permissão de arquivo. A mensagem pode ser um simples Permission denied, um EACCES no log do MySQL, uma falha silenciosa ao gravar em Data/Log/, ou o processo simplesmente não subir sem explicação clara. Diferente do Windows, o Linux trata permissões com um modelo de dono/grupo/outros bem mais rígido, e um erro de configuração aqui pode travar o boot do servidor inteiro ou, pior, deixar arquivos sensíveis abertos demais. Este tutorial cobre o diagnóstico passo a passo, as causas mais comuns em ambientes de MU Online (Wine, Docker, systemd) e como corrigir sem recorrer a atalhos perigosos como chmod 777.

Como o Linux decide quem pode acessar o quê

Cada arquivo e diretório no Linux tem três conjuntos de permissões — dono (owner), grupo (group) e outros (others) — e três tipos de acesso — leitura (r), escrita (w) e execução (x). Um servidor de MU Online típico roda com um usuário dedicado (por exemplo muserver), e todos os arquivos do jogo (Data/, Log/, Config/) precisam pertencer a esse usuário ou a um grupo do qual ele participe. Quando o processo tenta abrir, criar ou escrever em um arquivo fora dessa permissão, o kernel devolve EACCES (Permission denied) antes mesmo de o binário do servidor rodar qualquer lógica — por isso o erro costuma aparecer nos primeiros segundos de boot ou na primeira tentativa de gravar log.

Sintomas comuns em servidores de MU Online

Sintoma observado	Onde aparece	Causa típica
GameServer fecha ao iniciar sem mensagem clara	Terminal / systemd journal	Sem permissão de escrita em `Data/Log/`
MySQL não conecta ao socket local	Log do DBAgent/JoinServer	Permissão do socket `/var/run/mysqld/mysqld.sock`
Erro `EACCES` ao salvar personagem	Log do GameServer	Diretório de save pertence a outro usuário
Wine trava ao abrir o executável	Console do Wine	Prefixo `.wine` com dono/grupo incorretos
Container reinicia em loop	`docker logs`	Volume montado com UID diferente do usuário do processo

Diagnóstico: comandos essenciais

Antes de qualquer correção, colete informação. Os três comandos abaixo resolvem 90% dos casos de diagnóstico:

# Quem é o dono do arquivo/diretório e quais as permissões atuais
ls -la /home/muserver/MuServer/Data/Log/

# Qual usuário/grupo está rodando o processo do servidor
ps -eo user,group,cmd | grep -i gameserver

# Com qual usuário o systemd (se usado) executa o serviço
systemctl show muserver.service -p User -p Group

Compare o dono do arquivo (primeira coluna de ls -la) com o usuário retornado por ps ou systemctl show. Se forem diferentes, você já encontrou a causa raiz na maioria dos casos.

Corrigindo dono e grupo (chown)

Depois de identificar o usuário correto, ajuste a posse de toda a árvore do servidor:

sudo chown -R muserver:muserver /home/muserver/MuServer/

Isso garante que o usuário muserver seja dono de todos os arquivos e diretórios recursivamente. Se o servidor precisa que outro serviço (por exemplo, um painel web) também leia os arquivos, crie um grupo compartilhado em vez de trocar o dono para o serviço secundário:

sudo groupadd mu-shared
sudo usermod -aG mu-shared muserver
sudo usermod -aG mu-shared www-data
sudo chgrp -R mu-shared /home/muserver/MuServer/Data/
sudo chmod -R 2770 /home/muserver/MuServer/Data/

O 2770 liga o bit setgid no diretório (o 2 inicial), garantindo que novos arquivos criados dentro dele herdem o grupo mu-shared automaticamente.

Ajustando permissões (chmod) sem exagerar

Evite 777. Use a tabela abaixo como referência de permissões seguras e funcionais para as pastas mais comuns de um servidor de MU Online:

Diretório/arquivo	Permissão recomendada	Motivo
`Data/Log/`	`750` (rwxr-x---)	Só o dono grava; grupo lê para monitoramento
`Data/Save/` (personagens)	`700`	Dados sensíveis, só o processo do servidor acessa
`Config/*.ini`	`640`	Leitura para o grupo (ex.: painel admin), sem execução
Executáveis do servidor	`750`	Execução restrita ao dono e grupo
Scripts de backup (`.sh`)	`750`	Execução controlada, sem acesso de outros

Aplique com chmod explícito por tipo, nunca recursivamente igual em tudo:

find /home/muserver/MuServer/Data -type d -exec chmod 750 {} \;
find /home/muserver/MuServer/Data -type f -exec chmod 640 {} \;

Permissões dentro do Wine

Quando o GameServer roda via Wine (comum em builds Windows portadas para Linux), o prefixo ~/.wine precisa pertencer ao mesmo usuário que executa o Wine — nunca rode wine como root em um prefixo criado por outro usuário. Verifique com:

ls -ld ~/.wine
whoami

Se o prefixo foi criado por engano com sudo wine ..., o caminho mais seguro é recriá-lo do zero com o usuário correto, em vez de tentar corrigir permissões dentro de uma árvore inteira de registro do Windows emulado:

rm -rf ~/.wine
WINEARCH=win32 winecfg

Permissões em containers Docker

O erro mais comum em Docker é o mapeamento de UID: o volume no host pertence ao UID 1000, mas o processo dentro do container roda como UID 1001 (ou root, UID 0), e os dois não coincidem mesmo que os nomes de usuário pareçam iguais. Corrija de duas formas:

Fixando o UID do container para bater com o do host, no Dockerfile:

ARG UID=1000
RUN useradd -m -u ${UID} muserver
USER muserver

Ajustando o dono do volume no host antes de subir o container:

sudo chown -R 1000:1000 /srv/muserver/data
docker compose up -d

Prefira a primeira opção em produção — ela é reprodutível e não depende de lembrar de rodar chown toda vez que o volume é recriado.

SELinux e AppArmor: quando chmod não é suficiente

Em distribuições como CentOS, RHEL, Rocky Linux e Fedora, o SELinux pode bloquear acesso mesmo com permissões Unix corretas. O sintoma clássico é ls -l mostrando tudo certo, mas o processo ainda recebendo Permission denied. Verifique o estado e o log:

getenforce
sudo ausearch -m avc -ts recent

Se houver negativas relacionadas ao seu processo, ajuste o contexto do arquivo em vez de desativar o SELinux globalmente (o que reduz a segurança do servidor inteiro):

sudo semanage fcontext -a -t bin_t "/home/muserver/MuServer/GameServer(/.*)?"
sudo restorecon -Rv /home/muserver/MuServer/GameServer

Em Ubuntu/Debian, o equivalente é o AppArmor; verifique perfis ativos com sudo aa-status e ajuste o perfil correspondente se necessário.

Attributos imutáveis e montagens somente leitura

Dois casos raros, mas que confundem administradores: o atributo imutável (chattr +i) e montagens read-only. Verifique ambos antes de gastar tempo revisando chmod/chown repetidamente:

lsattr /home/muserver/MuServer/Data/Log/mu.log
mount | grep /home

Se aparecer o atributo i, remova com sudo chattr -i arquivo. Se a montagem estiver ro (read-only) em /etc/fstab ou em um ponto de montagem de rede (NFS), o problema não é de permissão Unix — é de opção de montagem, e precisa ser remontado com rw.

Boas práticas para evitar recorrência

Depois de corrigir o problema pontual, blinde o ambiente contra a recorrência: centralize toda a instalação do servidor em um único usuário de serviço dedicado (nunca rode o GameServer com sua conta pessoal), documente as permissões esperadas em um script de setup versionado, e use systemd com User= e Group= explícitos em vez de depender de quem executou o comando manualmente no terminal. Um script de deploy que aplica chown/chmod como parte do pipeline evita que a próxima atualização do servidor quebre as permissões novamente.

[Service]
User=muserver
Group=muserver
WorkingDirectory=/home/muserver/MuServer
ExecStart=/home/muserver/MuServer/GameServer

Erros comuns e soluções

Sintoma	Causa provável	Solução
`Permission denied` ao gravar log	Diretório não pertence ao usuário do processo	`chown -R` para o usuário correto
Container reinicia em loop por erro de escrita	UID do host diferente do UID do container	Fixar UID no Dockerfile ou ajustar dono do volume
`ls -l` correto mas processo ainda falha	SELinux/AppArmor bloqueando	Ajustar contexto/perfil, não desativar globalmente
Wine trava ao abrir o servidor	Prefixo `.wine` criado por outro usuário	Recriar prefixo com o usuário correto
Arquivo não pode ser alterado mesmo com permissão certa	Atributo imutável (`chattr +i`)	Remover com `chattr -i`
Escrita falha mesmo com tudo certo	Montagem `read-only`	Remontar com `rw` em `/etc/fstab`

Checklist de correção de permissões

Identifiquei o usuário/grupo real que roda o processo do servidor.
Comparei com o dono atual dos arquivos via ls -la.
Apliquei chown -R para o usuário/grupo corretos.
Ajustei chmod por tipo de arquivo, evitando 777.
Verifiquei SELinux/AppArmor se estava usando RHEL/CentOS/Ubuntu com módulo ativo.
Conferi atributos imutáveis (lsattr) e montagens (mount).
Configurei systemd com User=/Group= explícitos para evitar recorrência.
Testei reiniciar o serviço do zero para confirmar que o erro não retorna.

Com as permissões corrigidas e o serviço estável, o próximo passo natural é revisar toda a estrutura de deploy do seu ambiente Linux, para garantir que futuras atualizações não reintroduzam o mesmo problema — veja o tutorial de criação de servidor para revisar a configuração completa do zero.

Perguntas frequentes

Por que meu GameServer roda como root mas ainda dá Permission denied?

Rodar como root evita a maioria dos erros de permissão do sistema de arquivos, mas não corrige ACLs restritivas, atributos imutáveis (chattr +i), montagens somente leitura ou contêineres com usuário mapeado diferente do host. Verifique esses pontos antes de assumir que root resolve tudo.

Preciso usar chmod 777 para resolver de vez?

Não. 777 é uma solução perigosa que abre todo o diretório para leitura, escrita e execução por qualquer usuário do sistema, inclusive processos comprometidos. Prefira 750 ou 770 com o dono e grupo corretos — isso resolve o mesmo problema sem expor o servidor.

O erro só acontece dentro do Docker, no host funciona. Por quê?

Isso costuma ser mapeamento de UID/GID entre o host e o contêiner. Se o volume foi criado pelo usuário 1000 no host e o processo dentro do contêiner roda como UID 1001, o contêiner não terá permissão mesmo que o host mostre o arquivo como acessível.

Como sei se o problema é permissão Unix ou SELinux/AppArmor?

Rode o comando de teste (ex.: tentar abrir o arquivo com o mesmo usuário do serviço) e olhe o log correspondente. Se ls -l e id mostram permissão compatível mas o processo ainda falha, verifique getenforce, audit.log ou dmesg para negativas de SELinux/AppArmor antes de mexer em mais chmod.

Rodar o MuServer via Wine muda alguma coisa nas permissões?

Sim. O Wine cria seu próprio prefixo (~/.wine) e mapeia caminhos do Windows para diretórios reais do Linux. Se o prefixo pertence a outro usuário ou tem permissões erradas, o servidor 'roda' mas falha silenciosamente ao gravar log, DB local ou arquivos temporários dentro do prefixo.

Bruno

Editor de eventos, mapas e itens

Bruno é especialista em eventos, mapas, bosses e economia de itens do MU Online. Documenta cada detalhe com base em jogo real.