Los mensajes de error de Linux no son avisos aleatorios ni textos pensados únicamente para desarrolladores. Cada uno revela qué operación ha fallado, sobre qué recurso actuaba el sistema y por qué el kernel o la aplicación la rechazaron. Interpretar esas pistas permite diagnosticar incidencias con más rapidez y evita aplicar comandos encontrados en Internet sin entender sus consecuencias.
Las claves de los errores de Linux en 20 segundos
- Cada mensaje suele identificar el comando, el recurso afectado y la causa del fallo.
errnodescribe errores de llamadas al sistema, mientras el código de salida indica si un comando terminó correctamente.- Permisos, espacio, memoria y red concentran muchas incidencias habituales.
- Antes de corregir un problema conviene confirmarlo con registros y herramientas de diagnóstico.
- Algunos comandos requieren precaución para no perder datos.
Un administrador experimentado no memoriza una solución para cada mensaje. Primero comprueba el contexto, reproduce el fallo cuando es seguro hacerlo y reúne evidencias con herramientas como journalctl, dmesg, ss, lsof, df o strace.
Por ejemplo:
cat /etc/shadow
cat: /etc/shadow: Permission denied
Lenguaje del código: JavaScript (javascript)El mensaje identifica tres elementos: cat es el programa que falla, /etc/shadow es el recurso solicitado y Permission denied explica el motivo.
Cómo interpretar un error antes de intentar corregirlo
Linux informa de los fallos mediante dos mecanismos relacionados, pero diferentes.
El primero es errno, un código numérico devuelto cuando falla una llamada al sistema. Las aplicaciones suelen traducir códigos como EACCES, ENOENT o ENOSPC a mensajes comprensibles.
El segundo es el código de salida del comando. El valor 0 suele indicar que la operación terminó correctamente, mientras que un número distinto de cero señala algún tipo de error.
El código del último comando puede consultarse así:
echo $?
Lenguaje del código: PHP (php)Este valor resulta especialmente útil en scripts:
if cp origen.txt destino.txt; then
echo "Copia completada"
else
echo "La copia ha fallado"
fi
Lenguaje del código: PHP (php)No todos los códigos distintos de cero representan un fallo grave. Algunas herramientas los utilizan para comunicar resultados concretos. grep, por ejemplo, devuelve 1 cuando no encuentra coincidencias.
Los 17 mensajes de error de Linux más habituales
1. Permission denied (EACCES)
El usuario no tiene permisos suficientes para leer, modificar o ejecutar el recurso solicitado.
Puede deberse a los permisos tradicionales de Unix, pero también a listas de control de acceso, SELinux, AppArmor, capacidades o a la falta de permiso de ejecución sobre alguno de los directorios que forman la ruta.
Diagnóstico:
ls -la /ruta/al/archivo
namei -l /ruta/al/archivo
id
getfacl /ruta/al/archivo
En sistemas con SELinux o AppArmor:
ls -Z /ruta/al/archivo
getenforce
aa-status
Posibles soluciones:
chmod u+r archivo.txt
chmod u+x script.sh
sudo chown usuario:grupo archivo.txt
sudo usermod -aG grupo usuario
Lenguaje del código: CSS (css)sudo no debería utilizarse como respuesta automática. Antes conviene comprobar qué permiso falta y si el usuario realmente debe tenerlo.
2. No such file or directory (ENOENT)
El sistema no encuentra el archivo, directorio o ejecutable indicado.
El motivo puede ser una ruta incorrecta, un enlace simbólico roto, un fichero eliminado o un intérprete inexistente en la primera línea de un script.
Diagnóstico:
pwd
ls -la /ruta/al/archivo
namei -l /ruta/al/archivo
readlink -f /ruta/al/enlace
command -v nombre_comando
También puede buscarse un archivo, aunque hacerlo desde / puede ser lento:
find /ruta/razonable -name "archivo.txt" 2>/dev/null
Lenguaje del código: JavaScript (javascript)Posibles soluciones:
cd /directorio/correcto
mkdir -p /ruta/al/directorio
sudo apt install paquete
export PATH="$PATH:/ruta/a/bin"
ln -s /ruta/correcta /ruta/del/enlace
Lenguaje del código: JavaScript (javascript)3. Command not found
El shell no encuentra un ejecutable con ese nombre en los directorios incluidos en PATH.
Puede que el programa no esté instalado, que su nombre esté mal escrito o que se intente ejecutar un script local sin indicar su ruta.
Diagnóstico:
command -v nombre_comando
type nombre_comando
printf '%s\n' "$PATH" | tr ':' '\n'
ls -l ./script.sh
Lenguaje del código: JavaScript (javascript)Posibles soluciones:
sudo apt install paquete
sudo dnf install paquete
chmod +x script.sh
./script.sh
El directorio actual no suele estar incluido en PATH por razones de seguridad. Por eso se utiliza ./script.sh.
4. Device or resource busy (EBUSY)
El recurso está siendo utilizado por otro proceso y no puede desmontarse, eliminarse o modificarse en ese momento.
Es frecuente al intentar desmontar un sistema de archivos mientras algún proceso conserva archivos abiertos o tiene allí su directorio de trabajo.
Diagnóstico:
findmnt /punto/de/montaje
lsof /punto/de/montaje
fuser -vm /punto/de/montaje
Posibles soluciones:
kill PID
umount /punto/de/montaje
kill -9 debe reservarse para procesos que no responden a una terminación normal, ya que impide que la aplicación cierre archivos o libere recursos de forma ordenada.
El desmontaje diferido:
umount -l /punto/de/montaje
puede resultar útil en situaciones concretas, pero no resuelve la causa que mantiene ocupado el sistema de archivos.
5. Connection refused (ECONNREFUSED)
El equipo de destino es accesible, pero no hay ningún servicio aceptando conexiones en el puerto solicitado o un firewall las está rechazando expresamente.
Diagnóstico:
ss -lntup
systemctl status servicio
nc -vz servidor 443
journalctl -u servicio
sudo nft list ruleset
Lenguaje del código: PHP (php)Posibles soluciones:
sudo systemctl start servicio
sudo systemctl restart servicio
sudo systemctl enable servicio
Antes de abrir un puerto debe comprobarse que el servicio escucha en la interfaz correcta y que exponerlo resulta necesario.
6. Disk quota exceeded (EDQUOT)
El usuario, grupo o proyecto ha alcanzado su cuota de espacio o de inodos, aunque el sistema de archivos todavía tenga capacidad libre.
Diagnóstico:
quota -s
df -h
df -i
du -sh "$HOME"/*
sudo repquota -a
Lenguaje del código: JavaScript (javascript)Posibles soluciones:
Puede eliminarse información prescindible, trasladar archivos a otro volumen, reducir la retención de copias o solicitar al administrador una ampliación de cuota.
Antes de borrar conviene localizar qué consume espacio:
du -xhd1 "$HOME" | sort -h
Lenguaje del código: JavaScript (javascript)7. Read-only file system (EROFS)
El sistema de archivos está montado en modo de solo lectura.
Puede ser una configuración intencionada o una medida de protección adoptada por el kernel tras detectar errores de almacenamiento o corrupción.
Diagnóstico:
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /punto/de/montaje
journalctl -k
dmesg | tail -50
lsblk -f
Posibles soluciones:
Si no existen errores y el diseño permite escritura:
sudo mount -o remount,rw /punto/de/montaje
Si hay indicios de corrupción, no conviene limitarse a remontarlo. Debe detenerse la actividad, desmontar el volumen y comprobarlo con la herramienta adecuada:
sudo umount /dev/dispositivo
sudo fsck /dev/dispositivo
fsck no debe ejecutarse normalmente sobre un sistema de archivos montado en lectura y escritura.
8. File exists (EEXIST)
La operación exige crear un recurso nuevo, pero ya existe otro con el mismo nombre.
Diagnóstico:
ls -la /ruta/destino
stat /ruta/destino
readlink /ruta/destino
Posibles soluciones:
mkdir -p /ruta/al/directorio
mv archivo.txt archivo-anterior.txt
ln -sf origen destino
Las opciones de sobrescritura como cp -f o ln -sf deben utilizarse únicamente después de comprobar qué se va a reemplazar.
9. No space left on device (ENOSPC)
El sistema de archivos no puede reservar más bloques o inodos.
El mensaje puede aparecer aunque df -h muestre espacio disponible si se han agotado los inodos, una situación habitual cuando existen millones de archivos pequeños.
Diagnóstico:
df -h
df -i
du -xhd1 /var | sort -h
sudo lsof +L1
docker system df
Lenguaje del código: JavaScript (javascript)lsof +L1 permite localizar archivos eliminados que continúan abiertos por algún proceso y siguen ocupando espacio.
Posibles soluciones:
sudo apt clean
sudo journalctl --vacuum-time=7d
docker system prune
docker system prune puede eliminar recursos no utilizados. Antes de ejecutarlo debe revisarse qué contenedores, imágenes y volúmenes necesita el entorno.
10. Operation not permitted (EPERM)
El kernel no permite la operación aunque el archivo pueda ser accesible.
A diferencia de EACCES, suele estar relacionado con privilegios especiales, capacidades, atributos inmutables, restricciones del sistema de archivos o políticas de seguridad.
Diagnóstico:
id
lsattr /ruta/al/archivo
getcap /ruta/al/ejecutable
capsh --print
findmnt -o TARGET,OPTIONS /ruta
Lenguaje del código: PHP (php)Posibles soluciones:
sudo chattr -i /ruta/al/archivo
sudo setcap capacidad /ruta/al/ejecutable
Modificar capacidades o atributos sin conocer su finalidad puede debilitar la seguridad del sistema.
11. Too many open files (EMFILE)
Un proceso ha alcanzado el límite de descriptores de archivo.
En Linux un descriptor puede representar archivos, sockets, tuberías, terminales y otros recursos de entrada y salida.
Diagnóstico:
ulimit -n
ls /proc/PID/fd | wc -l
lsof -p PID
cat /proc/sys/fs/file-nr
Posibles soluciones:
Aumentar el límite puede aliviar la incidencia, pero primero debería comprobarse si existe una fuga de descriptores.
En una sesión de shell:
ulimit -n 65535
En un servicio de systemd puede configurarse:
[Service]
LimitNOFILE=65535
Después:
sudo systemctl daemon-reload
sudo systemctl restart servicio
12. OOM Killed o proceso terminado con SIGKILL
El Out-Of-Memory Killer ha finalizado un proceso porque el sistema o un grupo de control se ha quedado sin memoria disponible.
Diagnóstico:
journalctl -k | grep -i -E 'oom|killed process'
free -h
ps aux --sort=-%mem | head
systemd-cgtop
docker stats
Lenguaje del código: JavaScript (javascript)En contenedores también deben revisarse sus límites de memoria.
Posibles soluciones:
La respuesta puede consistir en corregir una fuga, reducir la concurrencia, ajustar la configuración, ampliar la RAM o añadir swap. Reiniciar el proceso solo recupera el servicio temporalmente si la causa continúa presente.
13. Kernel panic
Un kernel panic aparece cuando el kernel encuentra una situación fatal de la que no puede recuperarse con seguridad.
Puede estar causado por fallos de RAM, almacenamiento defectuoso, controladores, módulos incompatibles, corrupción del sistema de archivos o errores del propio kernel.
Diagnóstico tras reiniciar:
journalctl -k -b -1
journalctl -b -1
sudo smartctl -a /dev/dispositivo
uname -r
lsmod
Si los registros no sobreviven al reinicio, puede ser necesario habilitar almacenamiento persistente para journald, utilizar una consola serie, kdump o mecanismos remotos de registro.
La solución depende de la causa: sustituir hardware, retirar un módulo, arrancar con un kernel anterior o reparar el sistema de archivos.
14. Segmentation fault (SIGSEGV)
Un proceso ha intentado acceder a una región de memoria no permitida y el kernel lo ha terminado con la señal SIGSEGV.
Suele indicar un error de programación, una biblioteca incompatible, corrupción de memoria o, con menor frecuencia, un problema físico de RAM.
Diagnóstico:
coredumpctl list
coredumpctl info
coredumpctl debug
journalctl -k
ldd /ruta/al/programa
Lenguaje del código: PHP (php)Durante el desarrollo también pueden utilizarse:
valgrind ./programa
gcc -g -fsanitize=address codigo.c -o programa
La corrección real suele requerir localizar el fallo en el programa, actualizarlo o instalar una versión compatible de sus dependencias.
15. APT Lock Error
APT o dpkg ya están siendo utilizados por otro proceso. El bloqueo evita que dos operaciones modifiquen simultáneamente la base de datos de paquetes.
Diagnóstico:
ps aux | grep -E '[a]pt|[d]pkg'
sudo lsof /var/lib/dpkg/lock-frontend
systemctl status apt-daily.service
sudo dpkg --audit
Lenguaje del código: JavaScript (javascript)La primera medida suele ser esperar a que terminen las actualizaciones automáticas.
Si un proceso está bloqueado, debe comprobarse antes de detenerlo. Tras una operación interrumpida pueden utilizarse:
sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt update
Eliminar manualmente los archivos de bloqueo mientras APT o dpkg siguen activos puede dañar la base de datos de paquetes.
16. Host key verification failed
SSH detecta que la clave pública del servidor no coincide con la guardada previamente en known_hosts.
Puede deberse a una reinstalación legítima, un cambio de servidor, una dirección IP reutilizada o un ataque de intermediario.
Diagnóstico:
ssh-keygen -F servidor
ssh -vv usuario@servidor
Lenguaje del código: CSS (css)La nueva huella debe verificarse mediante un canal fiable, como la consola del proveedor, la documentación del equipo o una comunicación directa con el administrador.
Después de confirmarla:
ssh-keygen -R servidor
ssh usuario@servidor
Lenguaje del código: CSS (css)ssh-keyscan permite obtener una clave, pero no demuestra por sí solo que pertenezca al servidor correcto.
17. Network is unreachable y Connection timed out
Aunque ambos errores impiden la conexión, señalan problemas diferentes.
Network is unreachable (ENETUNREACH) indica que el sistema no dispone de una ruta válida hacia la red de destino.
Connection timed out (ETIMEDOUT) suele significar que existe una ruta, pero el destino o algún elemento intermedio no respondió a tiempo.
Diagnóstico:
ip addr
ip link
ip route
ping -c 4 puerta_de_enlace
dig ejemplo.com
tracepath servidor
nc -vz servidor 443
sudo nft list ruleset
Lenguaje del código: CSS (css)Posibles soluciones:
sudo ip link set interfaz up
sudo systemctl restart NetworkManager
sudo ip route add default via puerta_de_enlace
Lenguaje del código: JavaScript (javascript)También deben comprobarse la configuración DNS, las listas de control, las reglas del firewall, las rutas en la nube y los grupos de seguridad.
Un método práctico para diagnosticar sin empeorar el problema
Ante cualquier error conviene seguir un orden sencillo:
- Leer el mensaje completo y no quedarse solo con la última línea.
- Identificar el comando, el recurso afectado y la operación solicitada.
- Consultar el código de salida cuando resulte útil.
- Comprobar permisos, espacio, memoria, procesos y conectividad.
- Revisar los registros del servicio y del kernel.
- Cambiar una sola cosa cada vez.
- Confirmar que el problema se ha resuelto y que no se ha ocultado la causa.
Los comandos destructivos deberían ser el último recurso. Borrar archivos de bloqueo, utilizar kill -9, vaciar directorios completos o ejecutar fsck sin revisar el estado del volumen puede convertir una incidencia recuperable en una pérdida de datos.
Linux suele explicar con bastante precisión por qué ha rechazado una operación. La dificultad no está tanto en memorizar comandos como en saber qué evidencia buscar y distinguir el síntoma de la causa real.
Preguntas frecuentes
¿Qué diferencia existe entre errno y el código de salida?
errno explica por qué ha fallado una llamada concreta al sistema. El código de salida resume cómo terminó un comando y puede consultarse mediante echo $?.
¿Por qué aparece “No space left on device” si todavía queda espacio?
El sistema puede haberse quedado sin inodos, existir una cuota agotada o haber archivos eliminados que siguen abiertos por procesos activos. Conviene comprobar df -h, df -i, las cuotas y lsof +L1.
¿Es seguro utilizar sudo para corregir “Permission denied”?
No siempre. sudo evita algunas restricciones, pero también puede ocultar permisos mal configurados o ejecutar una operación peligrosa como administrador. Primero debe identificarse qué control bloquea el acceso.
¿Se debe borrar el archivo de bloqueo de APT?
No mientras exista un proceso de APT o dpkg en ejecución. Lo correcto es esperar, comprobar el proceso y reparar el estado de los paquetes si una actualización quedó interrumpida.
Fuentes:
- Linux man-pages project, documentación de códigos de error y llamadas al sistema.
- GNU Bash Reference Manual, códigos de salida y ejecución de comandos.
- OpenSSH, documentación sobre verificación de claves de host.
- Debian, documentación de APT y
dpkg. - systemd, manuales de
journalctl, gestión de servicios y límites de recursos. - medium
