Cómo resolver errores de permisos de archivo en Linux al correr un servidor de MU Online

Todo administrador de servidor de MU Online que migra de Windows a Linux —ya sea para alojar en un VPS más barato, ya sea para correr el GameServer vía Wine en un contenedor Docker— tarde o temprano se topa con un error de permisos de archivo. El mensaje puede ser un simple Permission denied, un EACCES en el log de MySQL, un fallo silencioso al escribir en Data/Log/, o que el proceso simplemente no arranque sin ninguna explicación clara. A diferencia de Windows, Linux maneja los permisos con un modelo de dueño/grupo/otros mucho más estricto, y un error de configuración aquí puede bloquear el arranque de todo el servidor o, peor, dejar archivos sensibles demasiado abiertos. Este tutorial cubre el diagnóstico paso a paso, las causas más comunes en entornos de MU Online (Wine, Docker, systemd) y cómo corregirlas sin recurrir a atajos peligrosos como chmod 777.

Cómo decide Linux quién puede acceder a qué

Cada archivo y directorio en Linux tiene tres conjuntos de permisos —dueño (owner), grupo (group) y otros (others)— y tres tipos de acceso: lectura (r), escritura (w) y ejecución (x). Un servidor de MU Online típico corre con un usuario dedicado (por ejemplo muserver), y todos los archivos del juego (Data/, Log/, Config/) deben pertenecer a ese usuario o a un grupo del que forme parte. Cuando el proceso intenta abrir, crear o escribir en un archivo fuera de ese permiso, el kernel devuelve EACCES (Permission denied) antes incluso de que el binario del servidor ejecute cualquier lógica; por eso el error suele aparecer en los primeros segundos de arranque o en el primer intento de escribir el log.

Síntomas comunes en servidores de MU Online

Diagnóstico: comandos esenciales

Antes de cualquier corrección, reúne información. Los tres comandos siguientes resuelven el 90% de los casos de diagnóstico:

# Quién es el dueño del archivo/directorio y cuáles son los permisos actuales
ls -la /home/muserver/MuServer/Data/Log/

# Qué usuario/grupo está corriendo el proceso del servidor
ps -eo user,group,cmd | grep -i gameserver

# Con qué usuario ejecuta systemd (si se usa) el servicio
systemctl show muserver.service -p User -p Group

Compara el dueño del archivo (primera columna de ls -la) con el usuario que devuelven ps o systemctl show. Si son diferentes, ya encontraste la causa raíz en la mayoría de los casos.

Corrigiendo dueño y grupo (chown)

Después de identificar al usuario correcto, ajusta la propiedad de todo el árbol del servidor:

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

Esto garantiza que el usuario muserver sea dueño de todos los archivos y directorios de forma recursiva. Si el servidor necesita que otro servicio (por ejemplo, un panel web) también lea los archivos, crea un grupo compartido en lugar de cambiar el dueño al servicio secundario:

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/

El 2770 activa el bit setgid en el directorio (el 2 inicial), garantizando que los archivos nuevos creados dentro hereden automáticamente el grupo mu-shared.

Ajustando permisos (chmod) sin exagerar

Evita 777. Usa la siguiente tabla como referencia de permisos seguros y funcionales para las carpetas más comunes de un servidor de MU Online:

Aplícalo con chmod explícito por tipo, nunca de forma recursiva idéntica en todo:

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

Permisos dentro de Wine

Cuando el GameServer corre vía Wine (común en builds de Windows portados a Linux), el prefijo ~/.wine debe pertenecer al mismo usuario que ejecuta Wine —nunca corras wine como root en un prefijo creado por otro usuario. Verifícalo con:

ls -ld ~/.wine
whoami

Si el prefijo se creó por error con sudo wine ..., el camino más seguro es recrearlo desde cero con el usuario correcto, en vez de intentar corregir permisos dentro de todo un árbol de registro de Windows emulado:

rm -rf ~/.wine
WINEARCH=win32 winecfg

Permisos en contenedores Docker

El error más común en Docker es el mapeo de UID: el volumen en el host pertenece al UID 1000, pero el proceso dentro del contenedor corre como UID 1001 (o root, UID 0), y ambos no coinciden aunque los nombres de usuario parezcan iguales. Corrígelo de dos formas:

1. Fijando el UID del contenedor para que coincida con el del host, en el Dockerfile:

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

1. Ajustando el dueño del volumen en el host antes de levantar el contenedor:

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

Prefiere la primera opción en producción: es reproducible y no depende de acordarte de correr chown cada vez que se recrea el volumen.

SELinux y AppArmor: cuando chmod no es suficiente

En distribuciones como CentOS, RHEL, Rocky Linux y Fedora, SELinux puede bloquear el acceso incluso con permisos Unix correctos. El síntoma clásico es que ls -l muestra todo en orden, pero el proceso sigue recibiendo Permission denied. Verifica el estado y el log:

getenforce
sudo ausearch -m avc -ts recent

Si hay negaciones relacionadas con tu proceso, ajusta el contexto del archivo en lugar de desactivar SELinux globalmente (lo cual reduce la seguridad de todo el servidor):

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

En Ubuntu/Debian, el equivalente es AppArmor; verifica los perfiles activos con sudo aa-status y ajusta el perfil correspondiente si es necesario.

Atributos inmutables y montajes de solo lectura

Dos casos raros, pero que confunden a los administradores: el atributo inmutable (chattr +i) y los montajes read-only. Verifica ambos antes de perder tiempo revisando chmod/chown una y otra vez:

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

Si aparece el atributo i, quítalo con sudo chattr -i archivo. Si el montaje está en ro (read-only) en /etc/fstab o en un punto de montaje de red (NFS), el problema no es de permisos Unix, sino de opción de montaje, y hay que remontarlo con rw.

Buenas prácticas para evitar la recurrencia

Después de corregir el problema puntual, blinda el entorno contra la recurrencia: centraliza toda la instalación del servidor en un único usuario de servicio dedicado (nunca corras el GameServer con tu cuenta personal), documenta los permisos esperados en un script de setup versionado, y usa systemd con User= y Group= explícitos en lugar de depender de quién ejecutó el comando manualmente en la terminal. Un script de despliegue que aplica chown/chmod como parte del pipeline evita que la próxima actualización del servidor rompa de nuevo los permisos.

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

Errores comunes y soluciones

Lista de verificación de corrección de permisos

• Identifiqué el usuario/grupo real que corre el proceso del servidor.
• Comparé con el dueño actual de los archivos vía ls -la.
• Apliqué chown -R al usuario/grupo correctos.
• Ajusté chmod por tipo de archivo, evitando 777.
• Verifiqué SELinux/AppArmor si usaba RHEL/CentOS/Ubuntu con el módulo activo.
• Revisé atributos inmutables (lsattr) y montajes (mount).
• Configuré systemd con User=/Group= explícitos para evitar la recurrencia.
• Probé reiniciar el servicio desde cero para confirmar que el error no vuelve.

Con los permisos corregidos y el servicio estable, el siguiente paso natural es revisar toda la estructura de despliegue de tu entorno Linux, para garantizar que futuras actualizaciones no reintroduzcan el mismo problema: consulta el tutorial de creación de servidor para revisar la configuración completa desde cero.

Preguntas frecuentes