Permiso denegado en Linux: averiguar qué falla sin usar chmod 777

Cuando Linux responde Permiso denegado, la tentación es buscar un comando rápido y terminar con chmod 777. A veces hace desaparecer el mensaje, pero lo consigue dando permisos de lectura, escritura y ejecución a todo el mundo. Es una forma bastante mala de resolver algo que normalmente se puede localizar en un minuto.

El error puede venir del archivo, de una carpeta superior, del propietario, de una ACL, de un sistema montado en sólo lectura o de intentar ejecutar algo que no debería ser ejecutable. Antes de cambiar permisos hay que saber cuál de esos casos tenemos.

Leer el error completo

No es lo mismo abrir un documento, guardar dentro de una carpeta o ejecutar un script. Anoto el comando exacto y la ruta que falla. Después compruebo mi usuario y los grupos a los que pertenezco:

id

Usar sudo como primera respuesta oculta el problema y puede crear archivos propiedad de root dentro de mi carpeta personal, complicándolo todavía más.

Ver propietario y permisos

ls -ld /ruta/al/archivo
stat -c '%A %a %U:%G %n' /ruta/al/archivo

La salida muestra los permisos, el propietario y el grupo. En -rwxr-xr--, los tres primeros caracteres después del tipo corresponden al propietario, los tres siguientes al grupo y los últimos al resto de usuarios.

• r: leer el archivo o listar el directorio.
• w: modificar el archivo o crear y borrar entradas dentro del directorio.
• x: ejecutar un archivo; en un directorio permite atravesarlo y acceder a sus elementos.

Ese último detalle explica muchos casos: puedo tener permiso sobre un archivo y no poder abrirlo porque me falta x en una de las carpetas de la ruta.

Permisos numéricos sin convertirlos en una receta

Los números suman lectura (4), escritura (2) y ejecución (1). Por eso 755 significa permisos completos para el propietario y lectura/ejecución para los demás; 644 deja un archivo escribible sólo para su propietario.

Esos valores son habituales, no universales. Un documento privado puede necesitar 600; una clave SSH privada debe ser mucho más restrictiva que una imagen pública. Prefiero formas simbólicas como u+x cuando quiero modificar un único permiso, porque expresan mejor la intención y conservan el resto.

Comprobar todas las carpetas de la ruta

namei -l /ruta/completa/al/archivo

namei descompone la ruta y enseña propietario y permisos de cada nivel. Es mucho más útil que cambiar recursivamente todo un árbol sin saber dónde está el bloqueo.

Cambiar sólo el permiso que falta

Para hacer ejecutable un script que me pertenece:

chmod u+x script.sh

Para dar lectura y escritura al propietario:

chmod u+rw archivo

Y para permitir al grupo trabajar en un directorio compartido, conservando la ejecución sólo donde corresponda:

chmod -R g+rwX carpeta

La X mayúscula añade ejecución a directorios y a archivos que ya eran ejecutables; evita convertir documentos y fotografías en programas. Antes de usar -R reviso con find o ls qué contiene la carpeta y hago copia si son datos importantes.

Cuando el propietario es incorrecto

Si ejecuté una aplicación con sudo y ahora una carpeta de mi proyecto pertenece a root, el arreglo puede ser devolver la propiedad, no abrir los permisos:

sudo chown -R "$USER":"$USER" /ruta/al/proyecto

Sólo usaría ese comando en una carpeta personal que sé que debe pertenecerme. Nunca sobre /, /usr, /etc o una ruta del sistema: sus archivos necesitan propietarios diferentes.

Por qué chmod 777 suele ser mala idea

777 concede lectura, escritura y ejecución al propietario, al grupo y a cualquier otro usuario. En una carpeta web permitiría que procesos ajenos modificasen archivos; en un equipo compartido, cualquier usuario podría alterarlos. Además, activar ejecución en todos los archivos no aporta nada para documentos normales.

Si 777 «funciona», sólo demuestra que el problema estaba relacionado con permisos. Todavía falta averiguar si el acceso debía corresponder al propietario, a un grupo o a una aplicación concreta.

Si los permisos parecen correctos

Hay otras capas que pueden producir el mismo mensaje.

ACL adicionales

getfacl /ruta/al/archivo

Una ACL puede conceder o limitar permisos más allá de lo que resume ls -l. No la eliminaría sin entender para qué se creó.

Sistema de archivos en sólo lectura

findmnt -T /ruta/al/archivo

Si el montaje aparece como ro, cambiar el modo del archivo no permitirá escribir. Puede ser una decisión de montaje o una protección activada después de detectar errores en el disco.

Atributo inmutable

lsattr /ruta/al/archivo

Una i puede indicar que el archivo es inmutable. Antes de quitar ese atributo hay que saber quién lo puso y por qué.

Tres casos frecuentes y su solución correcta

Un script descargado no se ejecuta

Primero leo el script y confirmo su procedencia. Si es seguro y me pertenece, chmod u+x script.sh añade ejecución sólo para mi usuario. También puedo ejecutarlo con el intérprete correspondiente, por ejemplo bash script.sh, sin volver ejecutable el archivo.

Una carpeta creada con sudo no se puede editar

Compruebo con stat si pertenece a root. Si es una carpeta de mi proyecto personal, corrijo su propietario de forma acotada. No aplico chown a todo mi directorio personal sin revisar, porque algunas carpetas de aplicaciones pueden tener requisitos propios.

Un servicio web no puede leer un archivo

El proceso del servidor utiliza un usuario distinto. Abrir todo con 777 es especialmente peligroso. Reviso el usuario del servicio, el grupo apropiado y cada directorio de la ruta; después concedo sólo lectura o escritura donde realmente la necesita. En servidores con SELinux o AppArmor también puede existir una política adicional que los permisos Unix no muestran.

Un diagnóstico corto que evita destrozos

1. Reproducir el error sin sudo y anotar la ruta exacta.
2. Consultar usuario, propietario y permisos con id, ls -ld y stat.
3. Revisar toda la ruta con namei -l.
4. Aplicar el cambio mínimo con permisos simbólicos o corregir el propietario sólo si procede.
5. Si todo parece correcto, comprobar ACL, montaje y atributos.

Si el problema consiste en administrar el sistema, no conviertas carpetas en escribibles para evitar sudo. Es mejor configurar bien el usuario; en esta guía explicamos cómo añadirlo al grupo sudo y comprobar el acceso.

Los permisos de Linux dejan de parecer misteriosos cuando se separan propietario, grupo, resto de usuarios y cada carpeta del camino. Casi siempre hay una corrección mucho más pequeña y segura que chmod 777.