chmod y chown: cómo corregir permisos Linux sin usar 777
Publicado el 2026-10-26 por frfrand
Permisos Unix usuarios grupos y seguridad de archivos en servidores
Un archivo devuelve «Permission denied» y alguien recomienda chmod 777. Puede hacer desaparecer el error, pero también abre permisos innecesarios. Es mejor entender quién es propietario y qué usuario ejecuta la aplicación.
Te muestro dónde está el problema, cómo comprobarlo sin adivinar y qué haría en una aplicación que de verdad tiene usuarios. No necesitás memorizar un manual entero para resolver un fallo concreto.
Qué significa chmod y chown en la práctica
chown cambia usuario o grupo propietario; chmod ajusta bits de lectura, escritura y ejecución para propietario, grupo y otros. Los permisos de directorio determinan si se puede recorrer una ruta. En algunos entornos también intervienen ACL, montaje y políticas de seguridad.
Una aclaración antes de tocar el servidor: si el proyecto ya está en producción, guardá el estado que encontraste y comprobá en qué usuario y máquina vas a ejecutar los comandos. Trabajar como root sin necesidad y cambiar varias cosas a la vez dificulta encontrar la causa de un error.
Comandos útiles para empezar
ls -ld /srv/miapp
ls -l /srv/miapp/config.json
id www-data
sudo chown -R deploy:deploy /srv/miapp
chmod 750 /srv/miapp
chmod 640 /srv/miapp/config.json
namei -l /srv/miapp/config.jsonLas rutas, nombres de unidades y dominios son ejemplos. Adaptalos a tu servicio. Si un comando requiere permisos de administrador, revisá qué cambia y por qué. Las consultas de diagnóstico deberían venir antes de las modificaciones.
Paso a paso, con comprobaciones
- Identifica con
systemctl catopsel usuario que ejecuta el servicio. - Revisa propietario y permisos de cada directorio de la ruta, no solo del archivo final.
- Concede el mínimo acceso necesario: lectura si solo necesita leer, escritura en carpeta específica si debe generar archivos.
- Prueba de nuevo como usuario de servicio, no como root.
- Documenta los permisos para que el siguiente despliegue no los restablezca mal.
Después de cada paso, verifica un resultado observable: un estado, un archivo, una respuesta HTTP o una entrada de log. Si encuentras un mensaje inesperado, guárdalo para investigar en lugar de ocultarlo con reinicios repetidos.
Ejemplo real: una aplicación que hay que mantener
Un backend Django corre como usuario webapp y necesita escribir fotos en /srv/miapp/media, pero el directorio pertenece a root. Corrige solo la carpeta de subidas; no hagas todo el proyecto escribible por cualquier usuario.
Al final, prueba el camino completo: entrar por dominio, llamar a la API, escribir un dato de prueba y verificar que la información sigue ahí tras un reinicio controlado. Un servidor que «arranca» no siempre es una aplicación que funciona.
Errores que vale la pena evitar
El ejemplo de chown -R cambia todos los elementos bajo una ruta: verifica la ruta antes de ejecutar. Evita aplicar recursivamente a /, /etc o bases de datos administradas por el sistema.
También es importante que las credenciales no terminen en el historial de la terminal, logs, archivos compartidos o capturas. Para usuarios y servicios, usa permisos mínimos y documenta quién puede revocar el acceso.
Cómo entra ArduMaker en este escenario
En ArduMaker, separa usuarios de aplicación y de administración. La seguridad del VPS incluye permisos de archivos y servicios, no solo firewall y contraseña.
ArduMaker puede ayudarte a administrar los VPS, desplegar repositorios y trabajar con servicios, bases y dominios desde la misma plataforma. No reemplaza lo que acabamos de explicar sobre Linux: precisamente por eso conviene entender el diagnóstico y tener una forma de repetirlo.
Cuándo conviene automatizarlo
Si la tarea se repite, documenta primero el procedimiento manual y sus comprobaciones. Después considera un script o una tarea programada con errores visibles, logs y permisos limitados. No automatices un comando que todavía no sepas recuperar cuando sale mal.
Preguntas habituales
¿Puedo probarlo sin afectar clientes? En muchos casos sí: un VPS de staging o un servicio de prueba separado permite validar la configuración antes de cambiar producción.
¿Cómo sé si quedó bien? Mira logs y una operación funcional, no solamente que el comando terminó con código cero.
¿Cuándo necesito más recursos? Cuando las métricas indiquen saturación de CPU, RAM, disco o conexiones. Un fallo de configuración rara vez se arregla contratando más memoria.
Referencias
En una frase: primero entiende el error, después cambia una cosa concreta y comprueba su efecto. Esa disciplina te ahorra muchas horas de soporte.