メインコンテンツまでスキップ

第57章：権限トラブル（読めない/書けない）🔒😣

「EACCES: permission denied」「EPERM: operation not permitted」みたいなエラー、Docker学習でほぼ全員が踏みます😂 でも安心してOK！これは“しくみ”を知ると、わりと機械的に直せるタイプです🛠️✨

1) まずは“権限エラーっぽい匂い”を覚える👃💥​

よく出るメッセージ例📌​

  • EACCES: permission denied, open '/app/data/db.sqlite'
  • EACCES: permission denied, mkdir '/app/uploads'
  • EPERM: operation not permitted, rename ...
  • chmod: Operation not permitted
  • chown: Operation not permitted

ざっくり言うと👇

  • EACCES：読む/書く許可がない（権限が足りない）😣
  • EPERM / Operation not permitted：そもそもその操作が“できないファイルシステム”に当たってることが多い（特に Windows 側マウント絡み）🪤

2) 最短で理解する「権限」の超ざっくり基礎🧠✨​

Linux（コンテナの中）は基本これ👇

  • ファイル/フォルダには 所有者（owner） と グループ（group） がいる
  • さらに r/w/x（読む/書く/実行） の許可がある
  • 実は「ユーザー名」より UID/GID（数字） が本体

そしてDockerは何もしないと root（UID 0）で動きがち。でも安全のためには 非rootで動かすのが推奨です🔐 非rootで動かすと、今度は「書き込み先の所有者/権限」が合ってなくてコケやすい…というのが第57章の正体です😇 (Docker)

3) Windows＋WSL2の“権限沼”が起きやすい理由🪟🌀​

ポイントはこれ👇

✅ ファイル置き場が2種類ある​

  • WSLのLinux側（例：/home/...）：Linux権限が自然に効く👍
  • Windowsドライブ側（例：/mnt/c/...）：権限や属性が別物で、chmod/chown が効きにくい/効かないことがある😵

Docker Desktop（WSL2 backend）でも、Windows側のパスをバインドマウントするとトラブルが増えがちで、公式も「Linux側に置くのが基本おすすめ」と言っています📣 (Docker Documentation)

4) 権限トラブルの“デバッグ手順”テンプレ（これだけで勝率上がる）✅🔍​

困ったらこの順番でいきましょ👇（機械的でOK）

Step A：どこで失敗してる？（パスを特定）🧭​

エラー文に出てる パス を拾う 例：/app/data なのか、/app/node_modules なのか、/var/lib/postgresql/data なのか

Step B：コンテナは“誰として”動いてる？👤​

docker compose exec api id
docker compose exec api whoami

Step C：そのパスの所有者・権限は？📄​

docker compose exec api sh -lc "ls -ld /app /app/data && ls -ln /app/data | head"

Step D：それ、マウント（bind）？それともコンテナ内？📦​

  • volumes: でホストから入れてるなら ホスト側の所有者/権限が効く
  • 特に /mnt/c 由来だと “操作不能”系が混ざりやすい🪤

5) ハンズオン：わざと「書けない」を作って、直す💪😄🧪​

ここでは Todo API の api サービスを例にします（Compose前提）🧩

5-1. 再現：/app/data に書き込めず死亡させる😵​

ホスト側に data を作って、マウントします。

services:
  api:
    # build や image は既存のままでOK
    volumes:
      - ./:/app
      - ./data:/app/data
    # 非root運用（例：node公式イメージの node ユーザー）
    user: "node"

次に、書き込みテスト👇

mkdir -p data
docker compose up -d
docker compose exec api sh -lc "echo hello > /app/data/test.txt"

ここで permission denied が出たら成功です🎯（出ない場合は次へ）

5-2. 観察：原因は“所有者のミスマッチ”が多い👀​

docker compose exec api id
docker compose exec api sh -lc "ls -ldn /app/data && ls -ln /app/data"
  • id が uid=1000(node) なのに
  • /app/data が root:root だったり、書き込みビットが無かったりするとアウト🙅

※ node公式イメージには node ユーザーが用意されていて、非root運用の例も示されています。(GitHub)

6) 解決パターン集：安全寄りの直し方だけ持って帰ろう🛡️✨​

パターンA：WSLのLinux側（/home/...）に置いてて、所有者がズレた🧷​

いちばん素直に直るケースです👍

ホスト（WSL）側で data の所有者を合わせます👇

## WSLのプロジェクト直下で
sudo chown -R "$(id -u)":"$(id -g)" data
chmod -R u+rwX,g+rwX data

これで再テスト👇

docker compose exec api sh -lc "echo ok > /app/data/test.txt && cat /app/data/test.txt"

“777にする”は最後の最後にしましょ（クセになると危ない😇） Dockerも「可能なら非rootで」を推してます。(Docker Documentation)

パターンB：プロジェクトが Windows 側（/mnt/c/...）にある😵‍💫🪟​

これ、権限・監視イベント・速度、全部でしんどくなりがちです😂 なので基本方針はこれ👇

✅ プロジェクトを WSL の Linux ファイルシステム（~/...）に置く （Docker公式・Microsoft・VS Code側のおすすめもこの方向です） (Docker Documentation)

移動のやり方（イメージ）🚚​

  1. WSLで作業用ディレクトリを作る
mkdir -p ~/src
  1. そこにリポジトリを置く（clone でも move でもOK）
  2. WSL側で code . して VS Code を開く（WSL拡張でスムーズ） (Visual Studio Code)

パターンC：どうしても /mnt/c を使いたい（chmod/chown効かない問題）🪤​

「Operation not permitted」で詰まるとき、WSLの マウント設定で改善できることがあります。 代表が metadata オプションです🧩

/etc/wsl.conf に automount の options を設定する例👇

[automount]
options = "metadata"

反映には WSL の再起動（例：PowerShellで wsl --shutdown）が必要です🔁 (Microsoft Learn)

※ただし、これでも“完全にLinuxと同じ”にはならないことがあるので、やっぱり 最終的には Linux側（~/...）へ寄せるのが安定です🙏

パターンD：node_modules やビルド成果物が rename できない/消せない📦💥​

Windows系マウントが絡むと、ツールの一時ファイル操作でコケることがあります（rename/lock系）😇 この手は node_modules をバインドマウントしない（volumeに逃がす）と楽になることが多いです🏃‍♂️💨

例👇（node_modules だけボリューム化）

services:
  api:
    volumes:
      - ./:/app
      - api_node_modules:/app/node_modules

volumes:
  api_node_modules:

7) 事故りにくい“設計ルール”（初心者向けの最小セット）📏✨​

ルール1：書き込みが必要な場所を決め打ちする🗂️​

  • 例：/app/data、/app/uploads だけ書く
  • それ以外は基本読み取り（意図がはっきりする😄）

ルール2：コンテナの実行ユーザーを固定する👤​

  • user: "node"（公式イメージの想定に乗る）
  • もしくは user: "1000:1000" みたいに UID/GID を明示（混乱が減る） ユーザー指定やUID/GIDの考え方はDocker側でも推奨されています。(Docker)

ルール3：Windows側マウントを避ける（可能なら）🪟➡️🐧​

  • パフォーマンスも権限も、WSLのLinux側が安定 (Microsoft Learn)

8) AI活用：権限トラブルは“質問テンプレ”で勝てる🤖✨​

ログ＋状況を貼って聞くテンプレ📋​

  • 「このエラーは権限？それともファイルシステム都合？どっちっぽい？」
  • 「id と ls -ln の結果から、最短の修正案を3つ。安全順に」
  • 「rootに逃げずに直すなら、Compose/Dockerfileどこをどう変える？」

貼ると強い情報セット👇

1) エラー全文
2) docker compose exec api id
3) docker compose exec api ls -ldn /app/data
4) プロジェクトが /home/... か /mnt/c/... か
5) compose.yml の該当 volumes/user 部分

9) 章末ミニチェック✅🎉​

できたら勝ちです🏆

  • EACCES と EPERM の“匂いの違い”が言える👃
  • id と ls -ln で「誰が誰のファイルを触ってるか」を見れる👀
  • 直し方を root化以外で2つ以上言える🛡️
  • プロジェクトを WSLのLinux側に置くメリットを説明できる🐧✨

必要なら、あなたの 今の compose.yml / エラー全文 / id と ls -ln 結果を貼ってくれたら、最短で「どのパターンか」判定して、修正案を安全順に並べますよ😄🔧