Stable Difusion WebUI で画像生成してみた – Podman に躓く編

[質問]

docker 向けに作られたコンテナを podman で実行してる。このエラーはどう解消する？

[+] Running 2/2ilt 54bb72397ff2
 ✔ Service auto-cpu  Built                                                                               5.7s 
 ✔ auto-cpu          Built                                                                               0.0s 
Attaching to auto-cpu-1
auto-cpu-1  | mkdir: cannot create directory '/data/config': Permission denied

[回答]

お使いのエラーメッセージから、コンテナ内のプロセスが /data/config ディレクトリを作成しようとした際に「Permission denied（アクセス拒否）」が発生し、その結果コンテナが終了コード1で終了していることがわかります。

これは、Docker向けに作成されたコンテナイメージをPodmanで実行する際によくあるユーザー権限（UID/GID）の不一致またはセキュリティ設定に起因する問題である可能性が高いです。

以下の手順で問題の解消を試みてください。

権限エラーの解消方法

1. podman run に --userns=keep-id を追加する (最も一般的)

Dockerコンテナは通常、コンテナ内のユーザー（多くの場合UID:0のroot）として実行されることを想定していますが、Podmanはデフォルトで非特権ユーザーとしてコンテナを実行し、ホスト側のユーザーIDとコンテナ内のユーザーIDをマッピング（ユーザー名前空間、User Namespace）します。このマッピングが原因で、コンテナ内のプロセスがホスト側の特定のボリュームやマウントされたディレクトリへの書き込み権限を持てなくなることがあります。

--userns=keep-id オプションを使用すると、コンテナ内のユーザーIDを、Podmanを実行しているホスト側のユーザーIDと一致させるように試みます。これにより、権限問題が解決することがあります。

# 例: 既存の podman run コマンドにオプションを追加
podman run --userns=keep-id <その他のオプション> <イメージ名>

2. コンテナのユーザーを変更する

DockerイメージのDockerfile内で明示的にコンテナ内のユーザーを変更するか、podman run 時に --user オプションを使用してコンテナを実行するユーザーを指定します。

• podman run でユーザーを指定する: コンテナ内でディレクトリを作成する権限を持つユーザー（例: root や、Dockerfileで定義されている特定のユーザー）を指定します。

# root で実行する場合 (非推奨の場合もあるが、テストとして試す価値あり)
podman run --user root <その他のオプション> <イメージ名>

# ユーザーID (UID) を指定する場合 (例: 1000)
podman run --user 1000 <その他のオプション> <イメージ名>

3. マウント先のディレクトリの権限を調整する

もし /data/config がホストからボリュームとしてマウントされているディレクトリである場合、ホスト側でそのディレクトリの所有者またはパーミッションを、コンテナ内のプロセスが書き込めるように変更する必要があります。

1. ホスト側のディレクトリの所有者を確認/変更する: コンテナ内のプロセスが非rootユーザーで実行されている場合、そのホスト側のUID/GIDに合わせて、マウント先のディレクトリの所有者を変更します。

# ホスト側で実行
sudo chown -R <ユーザー名またはUID>:<グループ名またはGID> /path/to/data/config_on_host

2. 一時的に緩いパーミッションを設定する: テスト目的で、一時的にパーミッションを緩めることもできます。

# ホスト側で実行
sudo chmod -R 777 /path/to/data/config_on_host

4. SELinux の設定を確認する (RHEL系OSの場合)

RHEL/CentOS/FedoraなどのSELinuxが有効なOSを使用している場合、SELinuxがコンテナからのファイルシステムアクセスをブロックしている可能性があります。

ボリュームマウントを行う際に、:z または :Z オプションを追加することで、PodmanがSELinuxコンテキストを自動で修正し、アクセスを許可するようにできます。

# 例: ボリュームマウントオプションに :Z を追加
# -v /path/on/host:/data/config:Z
podman run -v /path/to/data/config_on_host:/data/config:Z <その他のオプション> <イメージ名>

多くの場合、--userns=keep-id オプションを追加するか、ホスト側のマウントディレクトリの権限を調整することで問題は解決します。 まずは 1. --userns=keep-id を試すことをお勧めします。

[質問]

$ podman compose --profile auto-cpu up --build --userns=keep-id
>>>> Executing external compose provider "/usr/local/sbin/docker-compose". Please see podman-compose(1) for how to disable this message. <<<<

unknown flag: --userns
Error: executing /usr/local/sbin/docker-compose --profile auto-cpu up --build --userns=keep-id: exit status 1

[回答]

これは、あなたが実行しようとしているのがPodman Composeではなく、/usr/local/sbin/docker-composeという外部のdocker-composeプロバイダーであり、そのdocker-composeが--usernsオプションを認識しないために発生しているエラーです。

この問題を解消するためのアプローチは2つあります。

1. podman-compose を使うように設定を変更する

podman composeコマンドは、デフォルトで外部のdocker-compose (通常はdocker-composeやdocker-compose-v2) を使用するように設定されていることがあります。この挙動を止め、Podmanネイティブなpodman-composeを使用するように設定を変更します。

a. compose_provider を podman-compose に設定する

podmanの設定ファイル（通常は$HOME/.config/containers/containers.conf）を編集し、compose_providerをpodman-composeに設定します。

# $HOME/.config/containers/containers.conf 内
[engine]
# 外部のdocker-composeを使用しないように設定を上書き
# 'podman-compose' または 'none' に設定します
compose_provider = "podman-compose"

b. 環境変数 CONTAINERS_COMPOSE_PROVIDER を設定する

一時的にpodman-composeを使用するように環境変数を設定できます。

# podman-compose を明示的に指定
export CONTAINERS_COMPOSE_PROVIDER="podman-compose"

# 再度実行
podman compose --profile auto-cpu up --build --userns=keep-id

c. podman-compose がインストールされているか確認する

そもそもpodman-composeがインストールされていない場合は、インストールが必要です。Podmanは公式のpodman-composeツールと連携しますが、多くのディストリビューションではPythonベースのコミュニティツール（pip install podman-compose）も使われています。

2. --userns オプションを使わずに権限問題を解決する

podman composeまたは使用されているdocker-composeが--usernsをサポートしない場合に、以前のエラーで指摘されていた権限問題を解決します。

Podmanで--userns=keep-idが最も推奨される解決策ですが、podman composeがそれに対応しない場合は、以下の方法で代用します。

a. podman コマンドで User Namespace を有効にする

podman runであれば--userns=keep-idを使用できますが、podman composeではpodman runに渡すための設定が必要です。

docker-compose.ymlファイル内のサービス定義に、Podmanがコンテナを実行する際に使用するユーザーを設定します。

# docker-compose.yml
services:
  auto-cpu:
    build: .
    # ... その他の設定
    # コンテナ内の root ユーザー (UID 0) を使用する
    # Podmanがホストの非特権ユーザーにマッピングするため、これが最も一般的な解決策
    user: "0"

    # または、ホスト側でボリュームの権限を変更する（マウントしている場合）
    # 例: ホストのユーザーID (通常 1000) に合わせてコンテナユーザーを指定する
    # user: "1000"

b. ホスト側の SELinux を無効にする (:z を追加する)

ボリュームをマウントしている場合、SELinuxが原因でアクセス拒否が発生していることがあります。volumes:設定に:zを追加してSELinuxコンテキストを自動で修正させます。

# docker-compose.yml
services:
  auto-cpu:
    # ...
    volumes:
      # /path/to/host/data をコンテナの /data/config にマウントしている場合
      - /path/to/host/data:/data/config:z

[質問]

2 で進める。docker-compose.yml はこうなってる

 x-base_service: &base_service

    ports:

      - "${WEBUI_PORT:-7860}:7860"

    volumes:

      - &v1 ./data:/data

      - &v2 ./output:/output

    stop_signal: SIGKILL

    tty: true

    deploy:

      resources:

        reservations:

          devices:

              - driver: nvidia

                device_ids: ['0']

                capabilities: [compute, utility]


name: webui-docker


services:

  download:

    build: ./services/download/

    profiles: ["download"]

    volumes:

      - *v1


  auto: &automatic

    <<: *base_service

    profiles: ["auto"]

    build: ./services/AUTOMATIC1111

    image: sd-auto:78

    environment:

      - CLI_ARGS=--allow-code --medvram --xformers --enable-insecure-extension-access --api


  auto-cpu:

    <<: *automatic

    profiles: ["auto-cpu"]

    deploy: {}

    environment:

      - CLI_ARGS=--no-half --precision full --allow-code --enable-insecure-extension-access --api


  comfy: &comfy

    <<: *base_service

    profiles: ["comfy"]

    build: ./services/comfy/

    image: sd-comfy:7

    environment:

      - CLI_ARGS=



  comfy-cpu:

    <<: *comfy

    profiles: ["comfy-cpu"]

    deploy: {}

    environment:

      - CLI_ARGS=--cpu 

[回答]

提示されているdocker-compose.ymlファイルと以前のエラー（/data/config': Permission denied）に基づき、「2. --userns オプションを使わずに権限問題を解決する」を進めるための最も適切な修正方法を提案します。

ターゲットとなるサービスはauto-cpuで、問題のディレクトリはマウントされている/data内にある/data/configです。

修正案：user と volumes に権限設定を追加する

docker-compose.ymlのauto-cpuサービス、および参照元であるx-base_serviceとautoに以下の設定を追加します。

1. auto-cpu サービスに user: "0" を設定する

Podmanはデフォルトで非特権ユーザー（ホスト側のUID/GID）としてコンテナを実行しようとします。これにより、コンテナ内のプロセスがマウントされたボリュームに書き込めないことが多いため、コンテナ内をroot (UID 0) で実行するよう明示的に指定します。

注意点: auto-cpuサービスは<<: *automaticで設定を継承していますが、automaticの参照元であるx-base_serviceにuserを追加すると他のサービスにも影響するため、ここではauto-cpuに直接追加します。

# docker-compose.yml の修正案

  auto-cpu:
    <<: *automatic
    profiles: ["auto-cpu"]
    deploy: {}
    environment:
      - CLI_ARGS=--no-half --precision full --allow-code --enable-insecure-extension-access --api
    # --- ここを追加 ---
    user: "0"  # コンテナ内のrootユーザーで実行する
    # ------------------

2. ボリュームマウントに :z オプションを追加する (SELinux対策)

SELinuxが有効なシステム（RHEL、CentOS、Fedoraなど）の場合、マウントされたディレクトリへのコンテナからのアクセスをブロックすることがあります。これを回避するため、ボリューム定義に :z オプションを追加します。

auto-cpuはx-base_serviceを継承しており、ボリュームは&v1で定義されているため、&v1の定義を修正するのが最も効率的です。

# docker-compose.yml の修正案

x-base_service: &base_service
    ports:
      - "${WEBUI_PORT:-7860}:7860"
    volumes:
      # --- ここを修正 ---
      - &v1 ./data:/data:z    # :z を追加
      - &v2 ./output:/output:z # :z を追加
      # ------------------
    stop_signal: SIGKILL
    # ... (後略)

修正後の auto-cpu の定義（確認用）

x-base_service: &base_service
    ports:
      - "${WEBUI_PORT:-7860}:7860"
    volumes:
      - &v1 ./data:/data:z
      - &v2 ./output:/output:z
    stop_signal: SIGKILL
    tty: true
    # ... (後略)

# ... (中略)

  auto-cpu:
    <<: *automatic
    profiles: ["auto-cpu"]
    deploy: {}
    environment:
      - CLI_ARGS=--no-half --precision full --allow-code --enable-insecure-extension-access --api
    user: "0" # <- 追加

実行コマンド

podman composeコマンドはそのまま実行できます。

podman compose --profile auto-cpu up --build

もしそれでも解決しない場合

auto-cpuサービスは、ホストの./dataディレクトリ内の/data/configを作成しようとしています。もしコンテナがroot (UID 0) で実行されても失敗する場合、ホスト側の./dataディレクトリ、または./dataディレクトリ内のconfigサブディレクトリの所有者とパーミッションを、コンテナから書き込み可能にする必要があります。

# ホスト側で実行
sudo chmod 777 ./data 
# または
# sudo chown -R <ホスト側のpodman実行ユーザー>:<グループ> ./data

// ここから別の日の実行
こんなエラーが出てる。直すには？

 $ podman compose --profile auto-cpu up --build

>>>> Executing external compose provider "/usr/local/sbin/docker-compose". Please see podman-compose(1) for how to disable this message. <<<<


unable to get image 'sd-auto:78': Cannot connect to the Docker daemon at unix:///run/user/1000/podman/podman.sock. Is the docker daemon running? 

[回答]

このエラーは、podman composeが外部のdocker-composeプロバイダー（/usr/local/sbin/docker-compose）を実行しようとした結果、そのdocker-composeがPodmanのソケットに接続できずに失敗していることを示しています。

Docker用に作られたdocker-composeは、通常、Dockerデーモン（/var/run/docker.sock）に接続しようとしますが、Podman環境で実行されているため、Podmanのソケット（unix:///run/user/1000/podman/podman.sock）を探しています。

この問題を解決し、Podman環境でコンテナを正常に起動するには、以下の手順でPodmanネイティブなComposeを使用するように設定を変更する必要があります。

🚀 根本的な解決策：Podman Composeの使用

最も確実な解決策は、外部のdocker-composeを使わず、Podman専用の**podman-compose**を使用するように設定を変更することです。

ステップ 1: podman-compose がインストールされているか確認する

まず、podman-composeがシステムにインストールされているか確認してください。インストールされていない場合は、多くの場合Pythonのpipコマンドでインストールできます。

Bash

# podman-composeがインストールされているか確認
podman-compose version

# (もしインストールされていなければ)
# pip install podman-compose  # コミュニティ版を使用する場合
# または、お使いのディストリビューションのパッケージマネージャを使用

ステップ 2: Podmanに podman-compose を使用するよう指示する

以前の実行で表示されたメッセージの通り、Podmanは現在外部のdocker-composeを呼び出しています。この挙動を停止し、PodmanのCompose機能（podman-compose）を使用するように設定します。

a. 環境変数で一時的に設定する (推奨)

最も簡単な方法は、一時的に環境変数CONTAINERS_COMPOSE_PROVIDERを設定することです。

Bash

# podman-compose を明示的に指定
export CONTAINERS_COMPOSE_PROVIDER="podman-compose"

# 再度実行
podman compose --profile auto-cpu up --build

b. 設定ファイル (containers.conf) で永続的に設定する

$HOME/.config/containers/containers.conf ファイルを編集し、compose_providerを設定します。

# $HOME/.config/containers/containers.conf の [engine] セクション
[engine]
compose_provider = "podman-compose"

🛠️ 代替案：ソケット接続の確認

上記の根本的な解決策が機能しない場合、あるいは何らかの理由で外部docker-composeの使用を継続する必要がある場合は、Podmanのソケットサービスが起動していることを確認します。

docker-composeが接続を試みているソケット（unix:///run/user/1000/podman/podman.sock）は、**podman.socket**サービスが提供しています。

# 1. podman.socket のステータスを確認
systemctl --user status podman.socket

# 2. podman.socket が停止している場合、起動する
# ユーザーセッションで実行されるため、必ず --user をつける
systemctl --user start podman.socket

# 3. 再度 podman compose を実行
podman compose --profile auto-cpu up --build