Causas posibles
- 01. Problema
- 02. Causas posibles
- 03. Cómo comprobarlo
- 04. Soluciones
- 05. Prevención
- El usuario actual no tiene permiso de lectura, escritura o ejecución sobre el archivo o carpeta.
- El script no tiene el bit de ejecución (
x) activado. - El archivo pertenece a otro usuario o grupo distinto al tuyo.
- El sistema de archivos está montado como solo lectura.
- Estás intentando escribir en una ruta protegida (como
/etco/usr) sin usarsudo.
Cómo comprobarlo
- Ejecuta
ls -l archivopara ver permisos y propietario. - Comprueba con
whoamiqué usuario eres y compáralo con el propietario del archivo. - Si es un script, revisa si tiene el bit
x: debería aparecer unaxenrwx. - Ejecuta
mount | grep ' / 'para comprobar si la partición está en modoro(solo lectura).
Soluciones
1. Dar permiso de ejecución a un script
chmod +x script.sh
./script.sh2. Cambiar el propietario del archivo
sudo chown $(whoami) archivo.txt3. Ejecutar el comando con privilegios elevados
sudo comandoUsa sudo con criterio
sudo debería ser la última opción, no la primera. Si un archivo de tu propio usuario te da "Permission denied", casi siempre el problema real es el propietario o los permisos, no la falta de sudo.
Prevención
- Usa permisos 644 para archivos normales y 755 solo cuando el archivo deba ser ejecutable.
- Evita ejecutar aplicaciones como root de forma habitual; usa un usuario con sudo.
- Al desplegar aplicaciones web, asegúrate de que el propietario coincide con el usuario del servidor (por ejemplo
www-data).
Preguntas frecuentes
¿Por qué me da Permission denied si uso sudo?
Puede deberse a que el propio usuario root tampoco tiene el bit de ejecución activado, o a restricciones adicionales como SELinux o AppArmor en algunas distribuciones.
¿Es seguro usar chmod 777?
No, en general no. 777 da permiso total a cualquier usuario del sistema. Es preferible ajustar el permiso mínimo necesario (por ejemplo 755 o 644).