Linuxエラーメッセージ辞典 - よくあるエラーの原因と対処法
この辞典の使い方
エラーメッセージ文字列をそのまま見出しにしている。ターミナルに出た文言で Ctrl+F 検索し、該当セクションの「原因」「切り分け」「対処」を上から順に読めば最短で復旧できる。
共通の鉄則
- エラー文は最後の1行だけでなく最初の1行を読む（根本原因は先頭に出ることが多い）
- 推測で
sudoを付けない。まず原因を切り分ける - 切り分けは「どのコマンドが／どのファイルに／どの権限で」の3点を特定する順で行う
前提（対象環境）
- OS: Ubuntu / Debian / RHEL 系の一般的なディストリビューション
- シェル: bash（zsh でも大半は同じ）
- 一般ユーザー権限で操作中を想定
command not found とは？
シェルが指定された名前の実行ファイルを PATH 上で見つけられない状態。コマンド名のタイプミス、未インストール、PATH 設定漏れのいずれかが原因のほぼ全て。
bash: dokcer: command not found
切り分け:
command -v docker # 実体パスが出れば PATH 上にある which docker # 同上（外部コマンド版） echo "$PATH" # 期待するディレクトリが含まれるか type docker # alias / 関数 / 実体のどれかを判別
対処:
- タイプミス: 上の例は
dokcer。正しくはdocker - 未インストール:
sudo apt install <パッケージ名>（RHEL 系はdnf install） - PATH 漏れ: 実体はあるのに見つからない場合。
export PATH="$PATH:/usr/local/bin"を~/.bashrcに追記 - sudo 時だけ not found:
sudoはsecure_pathを使うためPATHが別。フルパス指定かsudo env "PATH=$PATH" cmd
インストール直後に not found が続く場合、シェルがコマンド位置をキャッシュしている。hash -r でキャッシュをクリアする。
詳細は 「command not found」の対処法 を参照。
Permission denied はなぜ出るのか？
操作対象に対して、実行ユーザーが必要な権限（読み/書き/実行）を持っていないときに出る。ファイル権限・所有者・ディレクトリの実行ビット・SELinux/AppArmor のいずれかが原因。
bash: ./deploy.sh: Permission denied -bash: /var/log/app.log: Permission denied
切り分け:
ls -l deploy.sh # 実行ビット x があるか、所有者は誰か ls -ld /var/log # 親ディレクトリの権限 whoami # 自分のユーザー名 id # 所属グループ
対処:
- スクリプトが実行できない:
chmod +x deploy.sh - ファイルに書けない: 所有者なら
chmod u+w file、他人の所有ならsudoか所有者変更sudo chown $USER file - ディレクトリに入れない: ディレクトリには実行ビット
xが必要。chmod +x dir sudoが必要な領域（/etc,/var/log等）: 設定変更はsudo経由で行う
chmod 777 で「とりあえず通す」のは事故の元。必要最小限の権限（ファイル 644/755、ディレクトリ 755）に留める。
詳細は Permission denied の直し方 を参照。
No such file or directory の本当の意味
指定したパスが存在しない、または途中のディレクトリが存在しない。シンボリックリンク切れ、相対パスの誤解、インタプリタ行（shebang）のパス誤りでも発生する。
cat: config.yml: No such file or directory bash: ./run.sh: /bin/bash^M: bad interpreter: No such file or directory
切り分け:
pwd # いまどこにいるか ls -la # ファイルが本当にあるか（隠しファイル含む） file run.sh # 改行コード（CRLF）混入の確認 readlink -f link # シンボリックリンクの最終リンク先
対処:
- 相対パスの誤解:
cat ./config.ymlが無いなら絶対パスで確認cat /etc/app/config.yml - shebang で not found:
^Mが出たら Windows 改行（CRLF）。sed -i 's/\r$//' run.shで除去 - shebang のパス誤り:
#!/bin/bashのはずが/usr/bin/bash等。which bashで実体を確認 - リンク切れ:
ls -lで矢印先が赤表示ならリンク先が消えている。張り直す
No space left on device の調べ方
書き込み先のファイルシステムに空き容量が無い。実ブロックの枯渇だけでなく、inode 枯渇（小さいファイルが大量）でも同じメッセージが出る点が落とし穴。
cp: error writing 'backup.tar': No space left on device
切り分け:
df -h # 容量の使用率（Use%） df -i # inode の使用率（IUse%）← 見落としがち du -sh /var/* 2>/dev/null | sort -h # どこが太いか
対処:
- ブロック枯渇: 巨大ログ・古いアーカイブを削除。
journalctl --vacuum-size=200Mでログ圧縮 - inode 枯渇:
df -iが 100% なら容量に空きがあっても書けない。不要な小ファイル群（キャッシュ・セッション）を削除 - 削除したのに減らない: プロセスが掴んだままのファイル。
lsof +L1で確認し、該当プロセスを再起動
rm した直後でも、そのファイルを開いているプロセスが生きている限り容量は解放されない。サービス再起動まで df は減らない。
詳細は ディスクがいっぱいになったときの調べ方 を参照。
Connection refused と timed out の違い
Connection refused は相手に届いたがポートで拒否（サービス未起動 or ポート違い）。Connection timed out は応答が返ってこない（経路・ファイアウォール・ホスト停止）。この区別が切り分けの起点になる。
ssh: connect to host 10.0.0.5 port 22: Connection refused curl: (28) Failed to connect to api.example.com port 443: Connection timed out
切り分け:
ping -c3 10.0.0.5 # ホストまで到達するか nc -vz 10.0.0.5 22 # ポートが開いているか ss -tlnp | grep :22 # サーバ側でサービスが LISTEN しているか
対処:
- refused: 対象サービスが起動しているか確認
systemctl status sshd。ポート番号の指定ミスも確認 - timed out: ファイアウォール／セキュリティグループの許可、経路（
traceroute）、ホスト自体の死活を確認 - 名前解決で失敗:
Could not resolve hostなら DNS 問題。/etc/resolv.confとgetent hosts <名前>を確認
詳細は SSH で接続できないとき と ネットワークコマンド入門 を参照。
Address already in use の対処
起動しようとしたプロセスが使うポートを、別のプロセスが既に占有している。前回プロセスの残留、二重起動、TIME_WAIT 状態の残骸が主因。
Error: listen EADDRINUSE: address already in use :::3000 bind: Address already in use
切り分け:
ss -tlnp | grep :3000 # どの PID がポートを掴んでいるか lsof -i :3000 # 同上（プロセス名つき）
対処:
- 残留プロセスを停止:
kill <PID>。応答しなければkill -9 <PID> - 二重起動: systemd やプロセスマネージャ（pm2 等）で多重起動していないか確認
- TIME_WAIT で再バインド不可: アプリ側で
SO_REUSEADDRを有効化、または数十秒待つ
Killed / Out of memory が出たら
Killed の多くは OOM Killer がメモリ不足時にプロセスを強制終了したもの。アプリのログに痕跡が無くても、カーネルログには記録が残る。
$ ./train.py Killed
切り分け:
dmesg -T | grep -i -E 'oom|killed process' # OOM の証跡 journalctl -k | grep -i oom # systemd 環境 free -h # 現在のメモリ／swap
対処:
- 物理メモリ不足: 処理のバッチサイズ縮小、不要プロセス停止、swap 追加
- 特定プロセスが肥大:
ps aux --sort=-%mem | headでメモリ食いを特定 - コンテナの制限:
--memory制限に当たっていないか。制限値を見直す
OOM 以外の Killed は手動 kill やタイムアウト killer の可能性。dmesg に OOM 記録が無ければそちらを疑う。
bad interpreter / Exec format error
実行ファイルをカーネルが起動できない状態。shebang の誤り、CRLF 混入、アーキテクチャ不一致（ARM バイナリを x86 で実行等）が原因。
./run.sh: /bin/sh^M: bad interpreter: No such file or directory ./app: cannot execute binary file: Exec format error
切り分け:
head -1 run.sh # shebang 行を目視 file app # バイナリのアーキテクチャ（x86-64 / ARM aarch64） uname -m # 実行ホストのアーキテクチャ
対処:
^M付き: CRLF を除去sed -i 's/\r$//' run.sh- shebang のパス誤り: 実体を
whichで確認して修正 - アーキテクチャ不一致: そのホスト向けにビルドし直す。クロス実行が必要なら
qemu-user等を検討
segmentation fault (core dumped) の初動
プロセスが不正なメモリ領域にアクセスして OS に強制終了された。アプリ自体のバグが多いが、破損した共有ライブラリやバージョン不整合でも起きる。
Segmentation fault (core dumped)
切り分け:
dmesg -T | tail # segfault の発生アドレス ldd /path/to/app # 共有ライブラリの解決状況（not found が無いか） ulimit -c # core ファイル生成の可否
対処:
- ライブラリ不整合:
lddでnot foundがあれば該当ライブラリを再インストール - 再現性のあるバグ:
ulimit -c unlimited後に再実行し、gdb <app> <core>でbt（バックトレース）を取得 - アップデート直後: 依存パッケージの整合性を確認（
apt install --reinstall <pkg>）
詳細は パッケージ管理入門 を参照。
エラー早見表
| メッセージ | 主因 | まず打つコマンド |
|---|---|---|
| command not found | 未インストール / PATH | command -v cmd |
| Permission denied | 権限 / 所有者 | ls -l target |
| No such file or directory | パス誤り / CRLF | ls -la / file f |
| No space left on device | 容量 / inode 枯渇 | df -h / df -i |
| Connection refused | サービス未起動 | ss -tlnp |
| Connection timed out | 経路 / FW | nc -vz host port |
| Address already in use | ポート占有 | lsof -i :PORT |
| Killed | OOM | dmesg -T | grep -i oom |
| Exec format error | アーキ不一致 | file app |
| Segmentation fault | アプリ / ライブラリ | ldd app |
やってはいけないこと
- メッセージを読まずに
sudoを付ける chmod 777で権限問題を握りつぶすdfだけ見てdf -i（inode）を確認しないKilledをアプリログだけで判断（カーネルログを見ない）