title: “docker exec で Permission denied が出るときの確認手順” date: 2026-01-17 draft: true categories: [“runbook”] tags: [“runbook”, “docker”, “permission denied”, “docker exec”, “コンテナ”, “権限エラー”] description: “docker exec 実行時に Permission denied エラーが出る場合の原因特定と対処手順。ユーザー権限、SELinux、AppArmor、ファイルパーミッションを順に確認する。”

症状

docker exec でコンテナ内のコマンドを実行しようとすると Permission denied エラーが表示される。

    OCI runtime exec failed: exec failed: unable to start container process: exec: "xxx": permission denied
  

または

    bash: /path/to/file: Permission denied
  

結論：まずこれを確認

1. 実行しようとしているファイルに実行権限があるか確認する
2. コンテナ内のユーザーがそのファイルにアクセスできるか確認する
3. SELinux / AppArmor が有効な環境では、セキュリティコンテキストを確認する

トラブルシューティングフロー

    flowchart TD
    A[docker exec で Permission denied] --> B{どのタイミングでエラー?}
    B -->|exec 自体が失敗| C{実行ファイルに +x 権限あり?}
    B -->|exec 後のコマンドで失敗| D{対象ファイルの権限は?}
    C -->|No| E[chmod +x で権限付与]
    C -->|Yes| F{SELinux/AppArmor 有効?}
    D -->|権限なし| G[chown/chmod で修正]
    D -->|権限あり| H{コンテナ内ユーザーは?}
    F -->|Yes| I[セキュリティコンテキスト確認]
    F -->|No| J[Docker デーモンの権限確認]
    H -->|root 以外| K[--user オプション確認]
    H -->|root| L[ボリュームマウントの権限確認]
  

よくある原因

• 実行ファイルに実行権限がない — シェルスクリプトや実行ファイルに +x がついていない
• コンテナ内ユーザーとファイル所有者の不一致 — non-root ユーザーで実行している場合に発生しやすい
• ボリュームマウント時の権限問題 — ホスト側のファイル権限がコンテナ内ユーザーに適用される
• SELinux が enforcing モード — :z や :Z オプションなしでマウントしている
• AppArmor プロファイルによる制限 — Ubuntu 系で特定の操作がブロックされる
• read-only でマウントされている — :ro オプションや read_only 設定が有効
• シバン行の問題 — スクリプト先頭の #!/bin/bash が正しくない、または改行コードが CRLF

確認手順

ステップ1: エラーメッセージを正確に確認する

    docker exec コンテナ名 コマンド 2>&1
  

🔍 チェックポイント: エラーが exec failed なのか、コマンド実行後の Permission denied なのかを区別する

ステップ2: 実行ファイルの権限を確認する

    # コンテナ内で確認
docker exec コンテナ名 ls -la /path/to/file

# 実行権限がない場合
docker exec コンテナ名 chmod +x /path/to/file
  

🔍 チェックポイント: -rwxr-xr-x のように x が含まれていれば実行権限あり

ステップ3: コンテナ内のユーザーを確認する

    # 現在のユーザーを確認
docker exec コンテナ名 id

# 特定のユーザーで実行する場合
docker exec --user root コンテナ名 コマンド
  

🔍 チェックポイント: uid と gid がファイル所有者と一致しているか確認

ステップ4: ボリュームマウントの権限を確認する

    # ホスト側のファイル権限
ls -la /host/path/to/file

# コンテナ内から見た権限
docker exec コンテナ名 ls -la /container/path/to/file
  

🔍 チェックポイント: ホスト側の UID/GID がコンテナ内ユーザーと一致しているか

ステップ5: SELinux の状態を確認する（RHEL/CentOS/Fedora）

    # SELinux の状態確認
getenforce

# コンテキストを確認
ls -Z /host/path/to/file

# ボリュームマウント時に :z オプションを付与
docker run -v /host/path:/container/path:z イメージ名
  

🔍 チェックポイント: Enforcing の場合はセキュリティコンテキストの修正が必要な可能性あり

ステップ6: AppArmor の状態を確認する（Ubuntu/Debian）

    # AppArmor の状態確認
sudo aa-status

# 特定のプロファイルを無効化（検証用）
docker run --security-opt apparmor=unconfined イメージ名
  

🔍 チェックポイント: unconfined で動作する場合、AppArmor プロファイルが原因

ステップ7: シェルスクリプトの改行コードを確認する

    # 改行コードを確認
docker exec コンテナ名 cat -A /path/to/script.sh | head -1

# CRLF を LF に変換（コンテナ内に dos2unix がある場合）
docker exec コンテナ名 dos2unix /path/to/script.sh
  

🔍 チェックポイント: 行末に ^M が表示される場合は CRLF（Windows形式）

NG行動（やってはいけないこと）

• SELinux を無効化して放置 — 一時的な検証以外では推奨されない、セキュリティリスクになる
• すべてのファイルを 777 にする — セキュリティホールになる、原因特定もできなくなる
• 常に –privileged で実行 — 必要以上の権限を与えることになる
• エラーメッセージを読まずに対処 — 原因が異なると対処も異なる

よくある質問（FAQ）

Q1: docker exec –user root でも Permission denied になる

A: SELinux/AppArmor によるブロック、または read-only マウントの可能性がある。docker inspect コンテナ名 でマウントオプションを確認する。

Q2: ホストでは実行できるのにコンテナ内では実行できない

A: ボリュームマウント時にホストの UID とコンテナ内ユーザーの UID が異なる場合に発生する。--user $(id -u):$(id -g) オプションで UID を揃える。

Q3: Dockerfile で COPY したファイルが実行できない

A: COPY --chmod=755 オプションを使用するか、RUN chmod +x で権限を付与する。Dockerfile 内でのファイル権限は明示的に設定する。

関連するエラー・症状

• docker run で Permission denied が出る
• Docker ボリュームの権限問題
• SELinux が原因で Docker が動かない

解決しない場合

公式ドキュメント

• Docker run reference - Security configuration
• Docker storage - Bind mounts

確認すべきログ

    # Docker デーモンのログ
journalctl -u docker.service -f

# SELinux の拒否ログ
sudo ausearch -m avc -ts recent

# AppArmor のログ
sudo dmesg | grep -i apparmor
  

次に調べるキーワード

• docker exec OCI runtime exec failed
• docker volume permission denied
• docker SELinux context
• docker AppArmor profile