Resolución de conflictos de permisos de archivos y carpetas en servidores Linux

Los conflictos de permisos en servidores Linux son una de las causas más comunes de errores en sitios alojados en hosting compartido: accesos denegados, errores 403/500, imposibilidad de subir archivos o actualizar plugins en WordPress. Este artículo, escrito por un profesional en hosting, servidores e infraestructura, ofrece un diagnóstico claro, comandos prácticos y soluciones seguras para resolver estos conflictos sin comprometer la seguridad del servidor.

Por qué ocurren los conflictos de permisos en hosting compartido

En un entorno de hosting compartido conviven múltiples usuarios y aplicaciones en el mismo servidor. Esto introduce complejidad en la asignación de propietarios (owner), grupos (group) y permisos (modo de lectura/escritura/ejecución). Las causas más frecuentes son:

  • Migraciones o restauraciones que cambian propietarios de archivos.
  • Configuraciones de PHP (suPHP, PHP-FPM, suEXEC) que ejecutan procesos con diferentes usuarios.
  • Fallas al usar FTP/FTPS/SFTP con un usuario distinto al usuario del proceso web.
  • Permisos excesivos aplicados por copia de tutoriales (por ejemplo 777) que luego se endurecen o generan bloqueos por seguridad.
  • ACLs (access control lists) o atributos extendidos (chattr) que bloquean cambios.
  • Políticas de SELinux en distribuciones que lo emplean.

Conceptos esenciales: owner, group y permisos

Antes de actuar, recuerda la base de permisos en Linux:

  • Propietario (u): habitualmente el usuario que sube los archivos o el usuario del proceso web.
  • Grupo (g): usuarios agrupados con permisos compartidos.
  • Otros (o): todos los demás.
  • Modos: lectura (r=4), escritura (w=2), ejecución (x=1). Ejemplo 755 = propietario rwx, grupo r-x, otros r-x.

Diagnóstico paso a paso

Un diagnóstico sistemático evita aplicar cambios a ciegas. Sigue estos pasos:

  • Reproducir el error y anotar el código (403, 500, 401, etc.).
  • Verificar logs: access.log y error.log del servidor web, y logs de PHP-FPM o suPHP.
  • Comprobar propietario y permisos del archivo o carpeta afectada con ls -l.
  • Comprobar si existen ACLs con getfacl y atributos con lsattr.
  • Confirmar el usuario con el que corre el proceso web (ps aux | grep php-fpm; ps aux | grep apache o nginx).

Comandos básicos de diagnóstico

ls -l /ruta/al/sitio
getfacl /ruta/al/sitio
lsattr /ruta/al/sitio
ps aux | egrep 'php-fpm|apache|httpd|nginx'
tail -n 200 /var/log/nginx/error.log

Soluciones prácticas según el escenario

1) Archivos con propietario incorrecto

Si los archivos fueron subidos por FTP como usuario ftpuser y el proceso web corre como www-data, dará problemas para escribir. La solución segura es ajustar owner y group al usuario correcto del sitio.

chown -R usuario_web:grupo_web /home/usuario_web/public_html

En hosting compartido el usuario_web suele ser el mismo que el usuario del shell y del proceso PHP-FPM. Evita chown a root.

2) Permisos demasiado estrictos o demasiado laxos

Recomendación estándar para sitios PHP/WordPress:

  • Archivos: 644
  • Carpetas: 755
  • wp-config.php: 600 o 640 si el servidor lo permite
find /home/usuario/public_html -type d -exec chmod 755 {} \;
find /home/usuario/public_html -type f -exec chmod 644 {} \;
chmod 640 /home/usuario/public_html/wp-config.php

Evita 777; solo úsalo temporalmente en un test muy controlado y revierte inmediatamente.

3) Conflictos entre PHP-FPM y suPHP

Algunos paneles usan PHP-FPM con pools por usuario; otros usan suPHP que ejecuta PHP como propietario del archivo. Si hay mezcla, ajusta la configuración para que el proceso web use siempre el mismo usuario o adapta permisos/grupos.

  • Verificar PHP-FPM pool: /etc/php/*/fpm/pool.d/*.conf (user, group).
  • Si usas suPHP o suEXEC, asegúrate que los archivos pertenezcan al usuario correcto.

4) ACLs y atributos que impiden cambios

ACLs pueden dar permisos adicionales o negar escritura. Comprueba y limpia si es necesario:

getfacl /home/usuario/public_html
setfacl -b -R /home/usuario/public_html

lsattr puede mostrar archivos con atributo inmutable (i). Para quitarlo:

chattr -i /ruta/al/archivo

5) SELinux

En distribuciones con SELinux activo, etiquetas SELinux controlan acceso. Verifica con:

sestatus
ls -Z /home/usuario/public_html

Si SELinux es la causa, ajusta contexto con chcon o mejor con semanage fcontext y restorecon para persistencia.

Casos concretos en WordPress y soluciones rápidas

WordPress suele fallar en actualizaciones de plugins o subidas si no hay permisos de escritura. Diagnóstico y correcciones típicas:

  • Comprobar wp-content/uploads owner y permisos; directorio uploads debe ser escribible por el proceso web.
  • Si no se pueden instalar plugins desde el panel: comprobar owner de wp-content/plugins y wp-content.
  • Para actualizaciones automáticas, wp-config.php debe permitir operaciones (no estar a 600 si el proceso web necesita leer/escribir temporalmente).
chown -R usuario_web:usuario_web /home/usuario/public_html/wp-content
find /home/usuario/public_html/wp-content -type d -exec chmod 755 {} \;
find /home/usuario/public_html/wp-content -type f -exec chmod 644 {} \;

Buenas prácticas y checklist de seguridad

Al aplicar cambios sigue estas buenas prácticas:

  • Realiza una copia de seguridad antes de ejecutar chown o chmod recursivos.
  • Aplica el principio de mínimo privilegio: no entregues permisos de escritura a otros si no son necesarios.
  • Evita el uso continuado de 777; documenta y revierte cualquier permiso temporal amplio.
  • Registra cambios en un control de configuración o ticket para auditoría.
  • Si usas WP, considera plugins de seguridad que notifiquen cambios en archivos.

Resolución de problemas avanzada

Si los pasos anteriores no funcionan:

  • Revisa errores detallados en logs y habilita display_errors solo en entorno de desarrollo.
  • Verifica integridad de discos y permisos a nivel de sistema de archivos (errors de I/O pueden causar problemas aparentes de permisos).
  • Consulta con el proveedor de hosting: en hosting compartido puede haber políticas centralizadas que requieren intervención del soporte (pools PHP, chroot, reglas de seguridad).
  • Considera mover a hosting VPS/dedicado si el aislamiento de procesos es imprescindible para tu aplicación.

Resumen y pasos recomendados

  • Diagnóstico: reproducir error, revisar logs, identificar usuario del proceso web.
  • Ajustar propietario con chown al usuario correcto del sitio.
  • Establecer permisos estándar: carpetas 755, archivos 644, wp-config 600/640.
  • Verificar y limpiar ACLs o atributos inmutables.
  • Considerar SELinux o políticas específicas del proveedor y consultar soporte si procede.

Conclusión

Los conflictos de permisos en servidores Linux en entornos de hosting compartido pueden parecer complejos, pero con un enfoque ordenado se resuelven de forma segura. Diagnostica con logs y comandos básicos, corrige propietarios y permisos siguiendo políticas prudentes, y ten en cuenta la interacción con PHP-FPM, suPHP y SELinux. Mantén siempre copias de seguridad y aplica el principio de mínimo privilegio. Si tras estos pasos persiste el problema, el equipo de soporte del hosting puede identificar políticas de seguridad o configuraciones globales que requieren su intervención.

Aplicando estas prácticas reducirás errores 403/500, mejorarás la experiencia de administración de WordPress y protegerás tanto al sitio como al entorno compartido sin comprometer la seguridad del servidor.

Tags: