Casi todos Linux El administrador se ha encontrado con el error "Permiso denegado" en algún momento. Intentamos ejecutar un script, abrir un archivo, entrar en un directorio o conectarnos a través de SSHy la terminal devuelve el mensaje de bloqueo. La reacción más común es añadir un `chmod 777` y seguir adelante, lo que soluciona el problema pero abre vulnerabilidades de seguridad en el sistema.
En esta guía mostraremos cómo diagnosticar la causa real del error, identificar qué capa está bloqueando el acceso y aplicar la corrección mínima necesaria. Cubrimos el modelo POSIX, el uso adecuado de chmod y chown, escenarios comunes como SSH claves y directorios web, además de capas adicionales como SELinux y atributos extendidos.
Para los ejercicios prácticos, un servidor desechable es una buena idea. VPS Linux on Serverspace funciona bien para probar los comandos en un entorno aislado. Los ejemplos funcionan de la misma manera en Ubuntu, Debian, AlmaLinuxy Rocky.
Qué significa el error "Permiso denegado"
El mensaje aparece cuando el Linux El kernel rechaza una operación porque el usuario actual no tiene permisos suficientes sobre el archivo o directorio en cuestión. El mensaje es casi siempre el mismo, aunque las causas varían considerablemente.
Los contextos más frecuentes incluyen intentar ejecutar un script sin el bit de ejecución, leer un archivo propiedad de otro usuario, escribir en directorios del sistema como /etc o /var/www, acceder a una carpeta a través de cd sin el bit x, y SSH autenticación con claves cuyos permisos son demasiado permisivos.
Antes de aplicar cualquier solución, es útil saber que Linux Comprueba el acceso en tres capas. La primera son los permisos POSIX clásicos (rwx para el propietario, el grupo y otros). La segunda son las ACL extendidas, que permiten reglas más precisas para usuarios y grupos específicos. La tercera son los módulos de seguridad obligatorios: SELinux en RHEL y derivados, AppArmo Ubuntu y Debian.
Terminología: cómo Linux organiza permisos
El control de acceso se basa en tres categorías de sujetos y tres tipos de operaciones. Las categorías son: propietario del archivo (usuario, u), grupo del archivo (grupo, g) y otros usuarios del sistema (otros, o). Cada archivo tiene un único propietario y un único grupo asociado, que se definen al crear el archivo.
Los tipos de operación son leer (r), escribir (w) y ejecutar (x). Para archivos, el significado es directo. Para directorios, existe una sutileza importante: leer lista el contenido, escribir permite crear y eliminar archivos, y ejecutar permite recorrer el directorio, es decir, acceder a él mediante el comando cd y buscar archivos por ruta completa.
La salida de ls -l muestra este modelo en acción:
-rwxr-xr-- 1 maria devs 2048 Mar 10 14:20 deploy.shEl primer carácter indica el tipo (- para archivo regular, d para directorio, l para enlace simbólico). Los siguientes nueve caracteres forman tres tríos, uno por categoría: rwx para el propietario, rx para el grupo, r-- para los demás.
Existen dos formas de establecer permisos con chmod. La forma simbólica utiliza letras y operadores (chmod u+x script.sh añade permisos de ejecución para el propietario). La forma octal suma los valores 4 (r), 2 (w) y 1 (x) por categoría, lo que produce tres dígitos. Las combinaciones más comunes en el trabajo diario son:
| Octal | Simbólico | Uso típico | Lo que otorga |
|---|---|---|---|
| 644 | rw-r--r-- | Archivos de texto, configuraciones | El propietario edita, otros leen |
| 755 | rwxr-xr-x | Directorios, scripts públicos | Todos pueden navegar y ejecutar |
| 700 | rwx------ | ~/.ssh, datos privados | Acceso exclusivo para propietarios |
| 600 | rw------- | SSH claves privadas, archivos .env | El propietario solo lee y escribe |
| 775 | rwxrwxr-x | Carpeta de carga compartida | Un grupo escribe, otros leen |
Memorizar estas cinco combinaciones cubre la mayoría de las situaciones prácticas. Cualquier otra cosa se puede construir a partir de ellas con pequeñas variaciones.
Cómo funciona el sistema de permisos
Cuando un proceso intenta acceder a un archivo, el núcleo ejecuta una secuencia de comprobaciones. Primero, compara el UID del proceso con el UID del propietario del archivo. Si coinciden, se aplican los bits de propietario. De lo contrario, comprueba si alguno de los grupos del usuario coincide con el grupo del archivo y aplica los bits de grupo. Si ninguna de las dos condiciones se cumple, se aplica la tripleta de otros.
Este flujo tiene implicaciones importantes. Para la eliminación, el permiso de escritura en el directorio padre es más relevante que el permiso en el archivo en sí. Por eso, a veces podemos eliminar archivos de solo lectura sin problemas, siempre que tengamos acceso de escritura al directorio que los contiene.
Otra implicación tiene que ver con el bit de ejecución en los directorios. Si /home/maria/projects no tiene el bit x para el usuario actual, no se podrá acceder a ningún archivo en su interior, ni siquiera con permisos de apertura. La ruta completa al archivo debe ser transitable.
Por último, conviene conocer el concepto de umask. Al crear un archivo nuevo, el sistema parte de 666 (archivos) o 777 (directorios) y le resta el valor de umask. El valor predeterminado de 022 resulta en 644 para archivos y 755 para directorios.
Escenarios prácticos donde aparece el error
Script de shell sin permiso de ejecución
Creamos un script, escribimos unas pocas líneas e intentamos ejecutarlo:
$ ./deploy.sh
bash: ./deploy.sh: Permission denied
La causa es que el archivo se creó sin el bit x. La solución es agregar permisos de ejecución para el propietario:
chmod u+x deploy.sh
./deploy.sh
Si el script debe ejecutarse para todos los usuarios, podemos usar chmod 755. Para uso personal, chmod 700 mantiene el script privado.
SSH clave con permisos demasiado abiertos
Al conectarse a un servidor:
Permissions 0644 for '~/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
Este comportamiento se debe al parámetro StrictModes yes, habilitado por defecto en sshd_config. El servidor rechaza cualquier clave que pueda ser leída por otros usuarios en la máquina cliente. La solución requiere permisos restringidos para la clave y el directorio.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub
chmod 600 ~/.ssh/authorized_keys
Escribir en un directorio del sistema
Intentar crear un archivo dentro de /etc o /var/www como usuario normal provoca un bloqueo inmediato. La solución depende de la intención. Para cambios puntuales en archivos del sistema, sudo lo resuelve. Para directorios web donde una aplicación escribe regularmente, la ruta correcta es ajustar la propiedad:
sudo chown -R www-data:www-data /var/www/html
sudo find /var/www/html -type d -exec chmod 755 {} \;
sudo find /var/www/html -type f -exec chmod 644 {} \;
Acceder a los archivos de otro usuario
Si María necesita leer archivos creados por Joao, hay dos opciones sencillas. La primera es agregar a María al grupo de Joao y garantizarle acceso de lectura en el grupo:
sudo usermod -aG joao maria
chmod g+r /home/joao/report.txt
El segundo método utiliza ACL para una regla específica sin modificar los grupos:
sudo setfacl -m u:maria:r /home/joao/report.txtSistema de archivos de solo lectura o atributo inmutable
En algunos casos, el propio chmod devuelve "Permiso denegado", incluso para el usuario root. Las dos causas más probables son: el sistema de archivos se montó con la opción ro, o el archivo recibió el atributo i (inmutable) a través de chattr. Para diagnosticar:
mount | grep " on / "
lsattr file
Si el archivo tiene el atributo i, lo eliminamos con sudo chattr -i archivo. Si la partición está montada en modo de solo lectura, la volvemos a montar con acceso de escritura o ajustamos /etc/fstab.
Instrucciones paso a paso: diagnóstico y solución
Siempre que aparezca el mensaje "Permiso denegado", recomendamos seguir esta secuencia. Permite llegar al diagnóstico correcto sin necesidad de adivinar.
Paso 1. Identificar al propietario, el grupo y los permisos.
ls -l file
ls -ld directory
id
groups
El comando `ls -l` muestra el propietario, el grupo y los bits rwx. El comando `id` revela el UID del usuario actual, el GID principal y los grupos suplementarios. Al comparar ambos, descubrimos contra qué acceso de triplete se está evaluando. Para obtener información aún más detallada, `stat` proporciona todo, incluyendo marcas de tiempo y número de inodo.
stat filePaso 2. Ajustar los permisos con chmod
Una vez identificada la causa, ajustamos los permisos. La forma simbólica resulta práctica para realizar cambios específicos:
chmod u+x script.sh
chmod g-w file.txt
chmod o=r file.txt
La forma octal es mejor cuando se configura un conjunto completo de una sola vez:
chmod 644 config.yaml
chmod 755 deploy.sh
chmod 600 ~/.ssh/id_rsa
chmod 700 ~/.ssh
Para realizar ajustes recursivos en árboles de directorios, evite usar `chmod -R` con un solo valor. Utilice `find` para separar archivos y directorios:
find /path -type d -exec chmod 755 {} \;
find /path -type f -exec chmod 644 {} \;
Paso 3. Corrige la propiedad con chown.
Cuando el problema reside en el propietario o grupo del archivo, el comando chown lo soluciona:
sudo chown maria file.txt
sudo chown maria:devs file.txt
sudo chown :devs file.txt
sudo chown -R www-data:www-data /var/www
La sintaxis usuario:grupo abarca ambos ajustes en una sola operación. El indicador -R se aplica recursivamente a los directorios y su contenido.
Paso 4. Usa sudo cuando tenga sentido.
sudo es la herramienta adecuada para operar con archivos del sistema (/etc, /var/log, /usr) y para iniciar servicios que requieren privilegios. Para archivos dentro de /home o tus propios proyectos, es preferible cambiar la propiedad con chown en lugar de ejecutar todo como root, lo que evita crear archivos propiedad de root en tu directorio personal.
Paso 5. Comprobar capas adicionales
Si los permisos POSIX son correctos y el error persiste, es hora de revisar las capas adicionales. Para comprobar las ACL:
getfacl file
If there are entries denying access, adjust with setfacl or remove them with setfacl -b.
Para comprobar SELinux en RHEL, AlmaLinuxo sistemas rocosos:
getenforce
sudo ausearch -m avc -ts recent
Si getenforce devuelve Enforcing y ausearch muestra bloqueos, el SELinux La política está denegando el acceso. La solución depende del contexto y posiblemente implique restorecon, chcon o ajustes booleanos con setsebool.
Para comprobar la aplicaciónArmo Ubuntu y Debian, use sudo aa-status. Si un perfil activo restringe la aplicación, los registros en /var/log/syslog o /var/log/audit/audit.log mostrarán la denegación.
Errores comunes al corregir permisos
Enumeramos los resbalones que causan más problemas y cómo evitarlos.
Aplicar permisos chmod 777 a todo es la solución más tentadora, pero la peor idea. Otorga permisos de lectura, escritura y ejecución a cualquier usuario del sistema. En servidores expuestos, es una receta para el ataque. Identifique el usuario o grupo específico que necesita acceso y otorgue solo lo necesario.
El uso de chmod -R 755 en árboles mixtos agrega innecesariamente el bit x a los archivos regulares. Use find con -type d y -type f para separar archivos y directorios.
Olvidar el bit x en el directorio padre provoca fallos incluso con permisos de apertura en el archivo. Comprueba la ruta completa con ls -ld en cada nivel.
Invertir el orden de chmod y chown en los scripts de aprovisionamiento (DockerLos archivos (Ansible) pueden generar permisos incorrectos si chown altera los bits suid y sgid. El orden seguro es chown primero, luego chmod.
Ignorando SELinux on CentOS, AlmaLinuxy Rocky suele hacer perder el tiempo. Siempre ejecute getenforce y ausearch cuando los ajustes POSIX no solucionen el problema.
Usar sudo donde la propiedad debería ser fija crea archivos propiedad del usuario root en ubicaciones incorrectas. Si una aplicación necesita escribir en /var/www, establezca el propietario como www-data y permita que la aplicación se ejecute con ese usuario.
Conclusión
El mensaje de "permiso denegado" no es tanto un obstáculo, sino más bien una clara señal de que el sistema está funcionando correctamente. Lo ideal es comprender qué capa provocó el bloqueo y corregir el problema en el punto exacto.
Con la práctica, decodificar un mensaje de "Permiso denegado" se convierte en cuestión de segundos. La secuencia funciona en cualquier escenario: `ls -l` e `id` para diagnóstico, `chmod` para ajustar bits, `chown` para corregir la propiedad, `sudo` solo cuando tenga sentido y verificación de ACL y SE.Linux cuando el resto parece estar bien.
