【完全版】Linux「No such file or directory」エラーの原因と確認方法まとめ

Linuxを使っていると、誰もが一度は遭遇する No such file or directory というエラー。一見シンプルなメッセージですが、実際に出会うと:

• ファイルは確実に存在しているのに出る
• lsでは見えるのに、実行すると出る
• スクリプトのどの行で出ているのか分からない
• シンボリックリンクなのか実体なのか区別がつかない
• コンテナの中だけで再現する
• 改行コードやエンコーディングが原因らしいと聞いたが確認方法が分からない

など、「ファイルが無い」という表面的な意味だけでは説明がつかないケースが多々あります。実はこのエラーは、ファイルの不存在以外にも10通り以上の原因で発生します。

本記事では、No such file or directoryの原因の全パターンと確認方法を、リファレンスとしてまとめ直しました。基本的な切り分け方から、cd・実行ファイル・スクリプト内・シンボリックリンク・シバン行・改行コード・アーキテクチャ不一致・コンテナ環境まで、考えられるあらゆる原因と調査コマンドを完全網羅。この1本をブックマークすれば、No such file or directoryに関するあらゆる疑問が解決します。

結論：まず実行すべき確認コマンド10選

時間がない方向けに、超頻出の確認コマンドを先に示します。

# 1. ファイルが本当に存在するか確認
ls -la /path/to/file

# 2. 現在のディレクトリを確認（相対パスのミスを疑う）
pwd

# 3. パスにタイプミスがないか、ワイルドカードで確認
ls -la /path/to/fil*

# 4. シンボリックリンクが壊れていないか確認
ls -la /path/to/file   # -> の先が赤色なら切れている

# 5. 実行ファイルのシバン行（先頭行）を確認
head -1 /path/to/script.sh

# 6. シバン行で指定したインタプリタが実在するか確認
which bash
file /usr/bin/python3

# 7. ファイルの改行コードを確認（CRLF問題）
file /path/to/script.sh

# 8. 実行ファイルの形式・アーキテクチャを確認
file /path/to/binary

# 9. 動的リンクライブラリの不足を確認
ldd /path/to/binary

# 10. システムコールレベルでどのパスを探しに行っているか追跡
strace -f -e trace=open,openat /path/to/command 2>&1 | grep ENOENT

詳細は以下で順に解説します。

“No such file or directory” の正体

このエラーメッセージは、Linuxカーネルが返す ENOENT（Error NO ENTry） というエラーコードを、各コマンドやプログラムが人間向けに表示したものです。

プログラムがファイル/ディレクトリにアクセスしようとする
        │
        ▼
カーネルが該当パスを探索
        │
        ▼
パスのどこかの階層が存在しない
        │
        ▼
カーネルが ENOENT を返す
        │
        ▼
各言語・コマンドが "No such file or directory" として表示

⚠️ 重要なのは、エラーメッセージの見た目が同じでも原因は1つではないということです。「ファイルそのものが無い」だけでなく、以下のように多様な原因があります。

基本の確認：ファイルとパスを疑う

ファイルの存在確認

# 基本のls確認
ls -la /path/to/file

# 存在有無だけをシンプルに判定
[ -e /path/to/file ] && echo "存在する" || echo "存在しない"

# ファイルかディレクトリかも含めて判定
test -f /path/to/file && echo "ファイルとして存在"
test -d /path/to/dir && echo "ディレクトリとして存在"

現在地（カレントディレクトリ）を疑う

相対パスの指定ミスは最も頻出する原因です。

# 今どこにいるか確認
pwd

# 相対パスで指定したつもりが、実は違う場所を見ている、という事故が多い
cd /home/user/project
./scripts/deploy.sh
# → scripts/deploy.sh が本当に存在するかカレントディレクトリ基準で確認
ls -la ./scripts/deploy.sh

タイプミス・大文字小文字を疑う

Linuxのファイルシステムは大文字小文字を区別します。

# ワイルドカードで近い名前のファイルを探す
ls -la /path/to/fil*

# 大文字小文字を無視して検索
find /path/to/ -iname "filename*"

# タブ補完を使ってミスを未然に防ぐ
cd /path/to/<Tabキー>

空白文字・特殊文字の混入を疑う

コピペ等で全角スペースや見えない制御文字が混入しているケースがあります。

# ファイル名を16進ダンプして余計な文字がないか確認
ls /path/to/ | cat -A

# lsの出力をod等でバイト単位確認
ls /path/to/file | od -c | head

# 該当ディレクトリ内のファイル名一覧をクォート付きで確認（空白の有無が分かりやすい）
ls -Q /path/to/

cd・コマンド実行時のエラーを調査する

cd: No such file or directory

# 親ディレクトリから順に存在確認していく
ls -la /
ls -la /home/
ls -la /home/user/
ls -la /home/user/project/
# どの階層で消えているか特定できる

# 一括でパスの各階層を検証するワンライナー
path="/home/user/project/missing"
p=""
for part in $(echo "$path" | tr '/' ' '); do
    p="$p/$part"
    if [ ! -e "$p" ]; then
        echo "存在しない階層: $p"
        break
    fi
done

bash: ./script.sh: No such file or directory（実行ファイルなのに出る）

ファイルは確実に存在するのに実行時だけこのエラーが出る場合、ファイル自体の不存在ではなく中身の問題であることがほとんどです。

# まずファイル自体の存在と実行権限を確認
ls -la ./script.sh
# -rwxr-xr-x なら実行権限はある

# 実行権限がなければ付与（ただしこれは別エラー "Permission denied" になることが多い）
chmod +x ./script.sh

実行権限があるのにNo such file or directoryが出る場合は、次章のシバン行の問題を疑います。

シバン行（shebang）の問題を調査する

シバン行とは

スクリプトの1行目にある #!/bin/bash のような指定で、どのインタプリタでこのスクリプトを実行するかをカーネルに伝える仕組みです。

#!/bin/bash
echo "Hello"

./script.shのように直接実行すると、カーネルはまずこの1行目を読み、指定されたインタプリタ（/bin/bash）を起動してスクリプトを渡します。

シバン行で指定したパスが存在しない

# スクリプトの1行目（シバン行）を確認
head -1 /path/to/script.sh

# 出力例: #!/bin/sh だが /bin/sh が存在しない環境の場合エラーになる
ls -la /bin/sh
which sh

# シバン行で指定されたインタプリタの実在確認
SHEBANG_PATH=$(head -1 script.sh | sed 's/^#!//' | awk '{print $1}')
ls -la "$SHEBANG_PATH"

⚠️ よくあるケースとして、MacやWindows（WSL）で書いたスクリプトをLinuxサーバーにそのまま持ち込んだ際、シバン行で指定したパス（#!/usr/local/bin/python3等）がそのサーバーには存在せず、No such file or directoryになることがあります。

シバン行に余計な文字が混入している

# シバン行を厳密にバイト単位で確認
head -1 script.sh | od -c | head -3

# 正常な例: #  !  /  b  i  n  /  b  a  s  h  \n
# 異常な例: \r （キャリッジリターン）が末尾に混入していないか

このパターンは次の「改行コード問題」と直結します。

改行コード（CRLF）の問題を調査する

Windows由来のCRLFが原因になるケース

Windowsで作成・編集したスクリプトファイルは、行末が CRLF（\r\n）になっていることが多く、Linux環境ではLF（\n）のみが正しい改行として扱われます。

#!/bin/bash\r
echo "Hello"\r

この場合カーネルは1行目を #!/bin/bash\r という改行コードを含む1つの文字列として解釈しようとし、/bin/bash\rという実在しないパスを探しに行って No such file or directory が発生します。

改行コードを確認する方法

# fileコマンドで改行コード情報を確認
file script.sh
# 出力例: script.sh: ASCII text, with CRLF line terminators

# catで制御文字を可視化
cat -A script.sh | head -3
# 行末に ^M$ が見えればCRLF（^Mが\rの可視化表現）

# odコマンドでバイト単位確認
od -c script.sh | head -3

改行コードを修正する方法

# dos2unixコマンドで変換（要インストール）
sudo apt install dos2unix    # Debian/Ubuntu
sudo yum install dos2unix    # RHEL/CentOS
dos2unix script.sh

# sedで\rを除去（dos2unixが使えない環境向け）
sed -i 's/\r$//' script.sh

# tr コマンドでの除去
tr -d '\r' < script.sh > script_fixed.sh

シンボリックリンクの問題を調査する

リンク切れの確認

# シンボリックリンクの一覧表示（リンク先も表示される）
ls -la /path/to/

# 出力例
# lrwxrwxrwx 1 user user 20 Jun 19 10:00 mylink -> /old/path/target
# リンク先が存在しない場合、多くのターミナルでは赤色で表示される

# リンク切れだけを検索する
find /path/to/ -xtype l

# 特定ディレクトリ配下のリンク切れを再帰的に検索
find / -xtype l 2>/dev/null

リンク先パスの確認・修正

# シンボリックリンクの指す先を確認
readlink /path/to/mylink

# 絶対パスとして完全に解決した結果を確認
readlink -f /path/to/mylink

# リンクを張り直す
ln -sf /correct/path/to/target /path/to/mylink

相対パスのシンボリックリンクが「移動」によって壊れるケース

# 相対パスで作成されたリンクは、リンク自体やリンク先を移動すると簡単に壊れる
ln -s ../data/file.txt mylink

# このリンクを別ディレクトリに移動すると相対パスの基準がズレて壊れる
mv mylink /other/directory/
ls -la /other/directory/mylink   # 壊れている可能性が高い

# 対策: 絶対パスでリンクを作成する
ln -s /absolute/path/to/data/file.txt mylink

アーキテクチャ不一致・バイナリ実行時の問題

実行ファイルの形式を確認する

# バイナリのアーキテクチャ・形式を確認
file /path/to/binary

# 出力例
# binary: ELF 64-bit LSB executable, x86-64, ...
# 実行環境のアーキテクチャと一致しているか確認

# 実行環境自体のアーキテクチャ確認
uname -m
# x86_64 や aarch64 等

x86_64用にビルドされたバイナリをARM環境（Apple SiliconのDocker、Raspberry Pi等）で実行しようとすると、ファイルは確実に存在するにもかかわらずNo such file or directoryになることがあります。これはバイナリ自体ではなく、対応するインタプリタ（ローダー）が見つからないことが原因です。

動的リンクライブラリの不足を確認する

# 実行ファイルが依存するライブラリの確認
ldd /path/to/binary

# 出力例（不足している場合）
# libsomething.so.1 => not found

# 不足ライブラリを探す
find / -name "libsomething.so*" 2>/dev/null

# パッケージマネージャーで該当ライブラリをインストール
sudo apt search libsomething   # Debian/Ubuntu
sudo yum search libsomething   # RHEL/CentOS

32bit/64bitの不一致

# 32bit実行ファイルを64bit環境で動かそうとして失敗する例
file ./old_32bit_binary
# old_32bit_binary: ELF 32-bit LSB executable, Intel 80386

# 32bit互換ライブラリのインストール（Debian/Ubuntu）
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libc6:i386

strace でシステムコールレベルから原因を特定する

最も確実で強力な調査方法が strace です。プログラムが実際にどのパスを探しに行って失敗しているかを直接観測できます。

基本の使い方

# straceがインストールされていなければ導入
sudo apt install strace   # Debian/Ubuntu
sudo yum install strace   # RHEL/CentOS

# コマンド実行時のシステムコールを全て表示
strace ./myprogram

# ファイル関連のシステムコールのみに絞る
strace -e trace=open,openat,stat,access ./myprogram

# ENOENT（No such file or directory）が発生した行だけ抽出
strace -f -e trace=open,openat ./myprogram 2>&1 | grep ENOENT

出力の読み方

openat(AT_FDCWD, "/etc/myapp/config.yml", O_RDONLY) = -1 ENOENT (No such file or directory)

この場合、プログラムが/etc/myapp/config.ymlを開こうとして失敗していることが一目で分かります。「プログラムのエラーメッセージには出てこない、本当に探しているパス」が判明するため、設定ファイルの探索パスがドキュメントと違う場合などに非常に有効です。

既に動いているプロセスにアタッチして調査

# 実行中プロセスのPIDを指定してリアルタイム追跡
strace -f -p <PID> -e trace=open,openat

スクリプト内のどの行でエラーが出ているか特定する

bash の -x オプションでトレース実行

# スクリプト全体を1行ずつ表示しながら実行
bash -x script.sh

# 出力例（+ から始まる行が実際に実行されたコマンド）
# + cd /home/user/missing_dir
# script.sh: line 5: cd: /home/user/missing_dir: No such file or directory

line 5のようにエラー発生行が明示されるため、どの操作が失敗の原因か即座に特定できます。

set -e と set -x を併用する

#!/bin/bash
set -ex   # エラーで即終了 + 実行コマンドを逐次表示

cd /home/user/project
source ./config.sh
./deploy.sh

# 実行
./script.sh
# どの行で止まったかが明確になる

PS4 でより詳細なトレース情報を出す

# 行番号も含めて表示する設定
PS4='+ [${BASH_SOURCE}:${LINENO}] ' bash -x script.sh

PATH・コマンド実行時の問題

コマンド自体が見つからない場合

# コマンドの実体がどこにあるか確認
which mycommand
type mycommand

# PATHに含まれていない場合の確認
echo $PATH

# 一時的にPATHへ追加
export PATH=$PATH:/path/to/bin

# 永続化
echo 'export PATH=$PATH:/path/to/bin' >> ~/.bashrc
source ~/.bashrc

cronやsystemdなど別実行環境でだけ発生する場合

対話シェルでは動くのに、cronやsystemd経由ではNo such file or directoryになるケースは、実行環境のPATHが対話シェルと異なることが原因であることが多いです。

# crontab内ではフルパスを使う
0 3 * * * /usr/local/bin/myscript.sh
# ❌ 0 3 * * * myscript.sh

# スクリプト内のコマンド呼び出しもフルパスで書くと確実
#!/bin/bash
/usr/bin/python3 /home/user/app.py

詳細はcrontabの環境変数の扱いについても合わせて確認してください。

コンテナ環境（Docker/Kubernetes）での確認

イメージ内にファイルが存在するか確認

# コンテナに入って直接確認
docker exec -it <container_id> sh
ls -la /path/to/file

# 起動せずイメージの中身だけ確認
docker run --rm -it <image_name> sh -c "ls -la /path/to/file"

# レイヤーごとの差分を確認（dive等のツールも有効）
docker history <image_name>

ビルド時の COPY/ADD ミスを確認する

# Dockerfileのビルドコンテキストとパスのズレが頻出原因
COPY ./app /app
# ビルドコンテキスト基準のパスになっているか確認

# ビルドコンテキストに該当ファイルが含まれているか確認
docker build --no-cache -t myimage . 2>&1 | grep -i "no such file"

# .dockerignoreで誤って除外していないか確認
cat .dockerignore

マルチステージビルドでのCOPY元ミス

FROM golang:1.22 AS builder
# ビルド成果物のパス
RUN go build -o /app/bin/server

FROM alpine
# ❌ ステージ名の指定ミスでファイルが見つからない
COPY --from=build /app/bin/server /usr/local/bin/server
# ✅ 正しいステージ名（builder）を指定
COPY --from=builder /app/bin/server /usr/local/bin/server

ボリュームマウント漏れ

# マウントが正しく行われているかコンテナ内から確認
docker exec -it <container_id> mount | grep /path/to/mount

# docker-compose.yml のvolumes指定を再確認
# volumes:
#   - ./host-path:/container-path

Alpine LinuxでのGlibc依存バイナリ実行エラー

# Alpine（musl libc採用）でglibc依存バイナリを動かそうとして失敗する典型例
docker run --rm -it alpine /path/to/glibc_binary
# exec /path/to/glibc_binary: no such file or directory

# 原因確認: 動的リンク先のローダーが存在しない
file /path/to/glibc_binary
# Interpreter: /lib64/ld-linux-x86-64.so.2 のようなglibc用ローダーが指定されている

# Alpineにはこのローダーが標準で存在しないため発生する
ls -la /lib64/ld-linux-x86-64.so.2
# No such file or directory

# 対策1: Debian/Ubuntuベースイメージに変更する
# 対策2: glibc互換パッケージを追加する
apk add gcompat

このパターンは「バイナリ自体は存在するのに、実行しようとすると No such file or directory になる」という、初見では非常に分かりにくい原因の代表例です。

中間ディレクトリの不在を確認する

ファイル作成・コピー時に親ディレクトリが無い

# ❌ /data/backup/2026/06/ が存在しないとエラーになる
touch /data/backup/2026/06/file.txt
# touch: cannot touch '/data/backup/2026/06/file.txt': No such file or directory

# ✅ 親ディレクトリを再帰的に作成してから
mkdir -p /data/backup/2026/06/
touch /data/backup/2026/06/file.txt

cp / mv で多階層コピーする際の注意

# コピー先の親ディレクトリが存在しないとエラー
cp file.txt /new/deep/path/file.txt
# cp: cannot create regular file '/new/deep/path/file.txt': No such file or directory

# 事前にディレクトリ作成
mkdir -p /new/deep/path/
cp file.txt /new/deep/path/file.txt

プログラミング言語別の補足確認

Python の場合

# カレントディレクトリを確認
import os
print(os.getcwd())

# ファイルの存在を実行前に確認
print(os.path.exists('/path/to/file'))

# 絶対パスに変換して確認
print(os.path.abspath('relative/path/file.txt'))

# Pythonスクリプト実行時のカレントディレクトリに注意
# ❌ 実行場所によって相対パスの基準が変わる
cd /some/other/dir && python3 /home/user/script.py

# ✅ スクリプト自身の場所を基準にする書き方をコード側で行う
# import os; BASE_DIR = os.path.dirname(os.path.abspath(__file__))

Node.js の場合

# require/importのパス解決確認
node -e "console.log(require.resolve('./module.js'))"

# 実行時のカレントディレクトリ確認
node -e "console.log(process.cwd())"

gcc / コンパイル系の場合

# インクルードファイルが見つからない場合
gcc -v -E - < /dev/null 2>&1 | grep -A 20 "search starts here"
# コンパイラが探索しているインクルードパス一覧が表示される

# コンパイル時に-Iオプションで明示的にパス追加
gcc -I/path/to/headers main.c

トラブルシューティング

ファイルはlsで見えるのにプログラムからは見えない

# 名前空間（マウントネームスペース）の違いを疑う（コンテナ・chroot環境）
ls -la /proc/<PID>/root/path/to/file

# プロセスが実際に見ているファイルシステムのルートを確認
sudo ls -la /proc/<PID>/root/

コンテナ化された別プロセスやchroot環境のプロセスは、ホストとは異なるファイルシステム空間を見ているため、ホスト側のlsで見えても対象プロセスからは見えないことがあります。

権限的には見えるはずなのにエラーが出る

# 親ディレクトリの実行権限(x)が無いと、中のファイルが見えていてもアクセス不可になる
ls -la /path/to/parent_dir
# d--------- のように x が抜けていないか確認

# 親ディレクトリすべてに通過権限(x)があるか確認
namei -l /path/to/deep/file

⚠️ No such file or directoryは実は**Permission deniedと紛らわしいケース**があります。親ディレクトリの実行権限（x）が欠けていると、ファイル自体は存在してもアクセスできず、環境によってはNo such file or directory相当のエラーとして扱われることがあります。namei -lで全階層の権限を一括確認できます。

NFS・ネットワークマウント環境での一時的なエラー

# マウント状態を確認
mount | grep nfs
df -h

# NFSサーバー側の応答状況を確認
showmount -e <nfsサーバーIP>

# stale file handle（リンク切れ的な状態）を疑う場合は再マウント
sudo umount /mnt/nfs_share
sudo mount -a

Dockerビルドキャッシュが古いままで発生する

# キャッシュを使わず再ビルド
docker build --no-cache -t myimage .

# ビルドコンテキストに該当ファイルが含まれているか確認
tar -czvf - . | tar -tzvf - | grep "filename"

find できない／予期せず除外される

# シンボリックリンクをfindがデフォルトで辿らないことが原因の場合がある
find /path/to/ -name "target_file"
# 何も出ない場合、リンクを辿るオプションを追加
find -L /path/to/ -name "target_file"

実用パターン集

実務でよく使う調査・対策コマンドを網羅します。

デプロイ・CI/CD系

# デプロイスクリプト内の各コマンドの直前にファイル存在確認を仕込む
#!/bin/bash
set -e
TARGET="/opt/app/config.yml"
if [ ! -f "$TARGET" ]; then
    echo "ERROR: $TARGET が見つかりません" >&2
    exit 1
fi
cp "$TARGET" /opt/app/config.yml.bak

# CI環境でのパス問題切り分け（GitHub Actions等）
- name: Debug path
  run: |
    pwd
    ls -la
    find . -name "target_file" 2>/dev/null

バッチ処理・cron連携系

# cron実行時に発生しがちなパス問題のデバッグスクリプト
#!/bin/bash
{
    echo "=== $(date) ==="
    echo "PWD: $(pwd)"
    echo "PATH: $PATH"
    ls -la /expected/path/file.txt 2>&1
} >> /tmp/cron-debug.log

一括調査系

# システム全体のリンク切れを一括検出
find / -xtype l 2>/dev/null

# 全実行可能ファイルのシバン行を一括チェック
for f in $(find /usr/local/bin -type f -executable); do
    head -1 "$f" | grep -q "^#!" && echo "$f: $(head -1 "$f")"
done

# CRLF混入ファイルを一括検出
grep -rl $'\r' /path/to/scripts/ 2>/dev/null

コンテナ調査系

# イメージ内のファイル一覧をホストから確認（コンテナ起動なし）
docker create --name temp_check myimage
docker export temp_check | tar -tv | grep "filename"
docker rm temp_check

# マルチアーキテクチャイメージの中身を確認
docker buildx imagetools inspect myimage:latest

よくある質問（FAQ）

Q1. ファイルは確実に存在するのに No such file or directory が出ます

最頻出原因と確認順:

1. シバン行の問題: head -1 script.shでインタプリタの実在確認
2. 改行コード（CRLF）: file script.shで確認
3. 権限的に親ディレクトリへ侵入できない: namei -lで確認
4. コンテナ/chroot環境で見ているファイルシステムが違う: /proc/<PID>/root/から確認
5. straceで実際に探しているパスを直接確認

Q2. シェルスクリプトを実行すると No such file or directory になりますが、catでは中身が見えます

ほぼ確実にシバン行か改行コードの問題です。

file script.sh
head -1 script.sh | cat -A

^M$が見えればCRLFが原因、シバン行のパスが実在しなければそちらが原因です。

Q3. cpやmvで No such file or directory になります

コピー先の親ディレクトリが存在しないことが最頻出原因です。

mkdir -p /path/to/destination/
cp file.txt /path/to/destination/

Q4. straceを使う権限がありません

# straceにはCAP_SYS_PTRACE相当の権限が必要な場合がある
sudo strace -f ./myprogram

# Dockerコンテナ内で使う場合はseccompの制限緩和が必要なことも
docker run --cap-add=SYS_PTRACE --security-opt seccomp=unconfined myimage strace ./app

Q5. Macで書いたスクリプトをLinuxサーバーに持っていくとエラーになります

シバン行のインタプリタパスがMac特有（Homebrew経由の/usr/local/bin/...等）になっていないか確認してください。

head -1 script.sh
# 例: #!/usr/local/bin/bash （Macにはあるが、Linuxサーバーには無いことが多い）

# 環境を選ばない書き方に修正
#!/usr/bin/env bash

env経由で起動する書き方にすると、PATH上にあるインタプリタを動的に探すため移植性が上がります。

Q6. Dockerのマルチステージビルドで COPY --from が失敗します

ステージ名の指定ミス、またはビルド元ステージでのファイル生成パスのミスが典型的です。

# 各ステージのビルド成果物を個別確認
docker build --target builder -t debug-builder .
docker run --rm debug-builder ls -la /app/bin/

Q7. ARM環境（Apple Silicon Mac、Raspberry Pi等）でだけエラーになります

file ./binary
# x86-64 など実行環境と異なるアーキテクチャの場合、実行は試みられても
# 対応するローダーが見つからず No such file or directory になることがある

uname -m

x86_64用バイナリをARM環境で動かす場合は、エミュレーション環境（QEMU、binfmt_misc）の導入か、ARM用バイナリの再ビルドが必要です。

Q8. Alpine LinuxのDockerコンテナでだけ特定のバイナリが動きません

Alpineはmusl libcを採用しており、glibc依存でビルドされたバイナリは動的リンカが見つからずNo such file or directoryになります。

file ./binary
ldd ./binary

# 対策: gcompatパッケージの追加、またはDebian/Ubuntuベースイメージへの変更
apk add gcompat

Q9. find や grep で「そんなファイルはない」と出るのに、ls では確かに見えます

シンボリックリンクの扱いの違いが原因のことがあります。

# -L オプションでシンボリックリンクを辿らせる
find -L /path/to/ -name "target"

Q10. NFSマウントしたディレクトリで突然エラーが出るようになりました

mount | grep nfs
showmount -e <NFSサーバーIP>

NFSサーバー側のファイル削除・再作成によって「stale file handle」状態になっていることがあります。再マウントで解消することが多いです。

sudo umount /mnt/nfs_share && sudo mount -a

参考リンク・関連資料

公式ドキュメント

• errno(3) manページ – ENOENT等エラーコード一覧
• strace(1) manページ – straceコマンド詳細
• bash(1) manページ – bash・シバン行関連仕様
• symlink(7) manページ – シンボリックリンクの仕様

関連記事（本サイト）

• crontabの書き方と実用例まとめ – cron実行時のPATH・環境変数問題
• tarコマンドの使い方と実用例まとめ – アーカイブ展開時のパス問題
• Linux OOM Killerの確認方法まとめ – プロセスが突然消える別の原因
• Linux find オプション一覧 – findコマンドリファレンス

まとめ

No such file or directoryはLinuxで最も頻出するエラーの1つですが、原因は「ファイルが無い」だけに留まりません。要点を再整理します。

• 基本確認: ls -la、pwd、タイプミスや大文字小文字の違いをまず疑う
• 実行ファイル特有の原因: シバン行のインタプリタ実在確認（head -1）
• 改行コード問題: fileコマンドでCRLF混入を確認、dos2unixやsedで修正
• シンボリックリンク: ls -laでリンク切れ確認、find -xtype lで一括検出
• アーキテクチャ・依存関係: fileでバイナリ形式確認、lddで動的リンクライブラリ不足を確認
• 最終手段はstrace: strace -e trace=open,openatでプログラムが実際に探しているパスを直接観測
• スクリプト内の特定: bash -xでどの行が原因か特定
• コンテナ特有の原因: COPY元パスミス、ボリュームマウント漏れ、Alpine×glibcバイナリの不整合
• 権限との混同に注意: 親ディレクトリの実行権限（x）欠如も似た症状を引き起こす

これらの知識は、Linuxサーバー運用・スクリプト開発・コンテナ化・CI/CD構築など、システム管理や開発のあらゆる場面で必須です。本記事をブックマークしておけば、No such file or directoryに遭遇しても落ち着いて原因を切り分けられるようになります。

本記事は2026年6月時点の情報をもとに、bash（GNU bash 5.x系）、GNU/Linux環境（Debian/Ubuntu、RHEL系）、Docker環境での動作確認に基づき作成しています。シェルやディストリビューションによって挙動が一部異なる場合があるため、最新の情報は公式マニュアルもあわせてご確認ください。