RunPodでOllama+Open WebUIを構築しようとしたらunshareエラーで詰まった話 — Dockerを使わない代替構築法

クラウドGPU（RunPod）を借りてローカルLLM環境を構築しようとしたら、Open WebUI・Difyのセットアップで unshare: operation not permitted というエラーに当たり、結局Dockerを使わない構成に切り替えて解決したという記録です。同じ壁にぶつかった方の参考になれば幸いです。

※本記事の内容は2026年9月時点の検証に基づいています。RunPodの仕様やUIは変更されることがあるため、実際に試す際は最新の公式ドキュメントもご確認ください。

こんな方向けの記事です

RunPod（や同様のクラウドGPUの共有環境）上で、Ollama + Open WebUI や Dify を動かそうとしている
docker build や docker-compose up の途中で unshare: operation not permitted や failed to register layer といったエラーで止まった
原因が分からず、公式ドキュメント通りにやっているのになぜか失敗する、という状態

先に結論だけ知りたい方向けにまとめると、「借りたクラウド環境がDocker-in-Dockerを許可していない」のが原因で、対処法は「Dockerを諦めて、Ollamaとアプリをネイティブ（直接）インストールする」ことです。以下、実際に踏んだ手順を書きます。

やろうとしたこと

RunPodでGPU付きのPod（仮想サーバー）を借りて、以下の構成を作ろうとしていました。

Ollama：ローカルでLLMを動かすためのランタイム
Open WebUI または Dify：ChatGPTのような対話画面を提供するツール（通常はDockerコンテナとして提供される）

Ollama自体のインストールは問題なく完了しました。つまずいたのは、Open WebUIをDockerコンテナとして起動しようとした段階です。

実際に出たエラー

公式ドキュメント通りに、Open WebUIのDockerイメージをビルドしようとしたところ、以下のようなエラーで止まりました。

failed to register layer: unshare: operation not permitted

docker-compose up でも同様に、コンテナの起動処理の途中で権限エラーが発生し、先に進めませんでした。

原因の切り分け

まず疑ったのは、自分のコマンドの打ち間違いや、Dockerfileの記述ミスでした。しかし、公式のサンプルそのままでも同じエラーが出たため、環境側の制約を疑い始めました。

調べていく中で分かったのは、次のような事情です。

RunPodのPod（特にCommunity Cloud）自体が、すでに一種のコンテナ環境として動いている
その中でさらにDockerを動かそうとすると、いわゆるDocker-in-Dockerの状態になる
Docker-in-Dockerを正常に動かすには、コンテナに --privileged 権限や CAP_SYS_ADMIN といった特権が必要
RunPodのPod作成画面には、この特権を有効にする設定項目が見当たらない

つまり、「借りている仮想サーバー自体に、Dockerを内側でフルに動かすための権限が与えられていない」状態でした。

unshare は、Linuxでプロセスに新しい名前空間（namespace）を作るためのシステムコールです。イメージとしては、ワンルームの部屋の中にさらに間仕切りを立てて「専用の個室」を作るような機能で、Dockerはこれを使ってコンテナごとに隔離された環境を作っています。今回のエラーは、この「間仕切りを立てる権限」自体がブロックされていた、というのが正体でした。

そもそも、RunPodのPod自体がすでにホスト側から見れば一つの「個室（コンテナ）」です。その個室の中で、さらに新しい個室を作ろうとする＝Docker-in-Dockerは、マトリョーシカ人形の中にもう一つ人形を作ろうとするようなもので、外側の個室（RunPodのPod）に「中に個室を増設していいですよ」という管理者権限（--privileged や CAP_SYS_ADMIN）が渡されていないと実現できません。この管理者権限は、アパートで言えば「建物全体の合鍵」のようなもので、セキュリティ上の理由から入居者（＝借りているPod）には簡単には渡されない、と考えると分かりやすいかもしれません。

なお、以前は一部環境でDocker-in-Dockerが使えた時期もあったが、現在は制限される方向にあるようです。実際、RunPod公式ドキュメントでも「Runpodがユーザーに代わってDockerを実行するため、Pod内で自前のDockerインスタンスやDocker Composeを立ち上げることはできない」と明記されており、以前Kataベースの一部Podで提供されていたDocker-in-Docker機能も、現行の新しいランタイムでは廃止されています。今後さらに制限が強まる可能性もあるため、Dockerを前提とした構成を組む際は事前に公式ドキュメントで最新の対応状況を確認することをおすすめします。

試して、諦めたこと

Pod作成時のGPU・テンプレート選択画面で特権モードの項目を探したが、見当たらなかった
--privileged フラグを手動で渡そうとしたが、RunPod側のPod実行環境自体が対応しておらず効果なし
rootlessモード（合鍵なしで何とかDockerを動かす工夫）でのDocker起動も試したが、同様のエラーが解消しなかった

ここで、「このクラウド環境では、Dockerベースのセットアップ手順は諦める」という判断をしました。

代替策：Dockerを使わずにネイティブでインストールする

Open WebUIやDifyは便利な反面、Dockerでの配布が前提になっているツールです。そこで方針を変え、同じ機能を、Dockerを使わずにPythonで直接組み立てることにしました。

1. Ollama自体はそのままネイティブインストール

Ollamaは公式インストールスクリプトでDockerなしにインストールできます。

curl -fsSL https://ollama.com/install.sh | sh

これはRunPod上でも問題なく完了しました（そもそもOllama自体はDocker必須のツールではありません）。

2. モデルのダウンロード

ollama pull qwen2.5:7b

3. 対話画面は自作する（Python + Flask）

Open WebUIの代わりに、Flaskで簡易的なWeb画面を自作しました。Ollamaはローカルで簡単なHTTP API（決まった書式でリクエストを送ると答えを返してくれる「受付窓口」のようなもの）を提供しているため、それを叩くだけの薄いアプリで十分に「ブラウザから質問できる画面」は作れます。

from flask import Flask, request, render_template_string
import requests

app = Flask(__name__)

@app.route("/", methods=["GET", "POST"])
def index():
    answer = ""
    if request.method == "POST":
        question = request.form["question"]
        res = requests.post(
            "http://localhost:11434/api/generate",
            json={"model": "qwen2.5:7b", "prompt": question, "stream": False},
        )
        answer = res.json().get("response", "")
    return render_template_string(TEMPLATE, answer=answer)

TEMPLATE = """
<form method="post">
  <textarea name="question"></textarea>
  <button type="submit">送信</button>
</form>
<p>{{ answer }}</p>
"""

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8080)

これだけでも、ブラウザから質問を送ってOllamaの応答を受け取る画面としては十分に機能します。Open WebUIほど高機能ではありませんが、Dockerの権限問題に阻まれることなく、目的（社内文書を参照しながら対話する仕組み）は達成できました。

まとめ

RunPodのようなクラウドGPUの共有環境では、Docker-in-Dockerが権限的に許可されていないことがある
unshare: operation not permitted は、その制約が原因で発生する典型的なエラー
Pod作成画面に特権モードの設定項目がない場合、Docker前提のツール（Open WebUI、Difyなど）のセットアップは詰む可能性が高い
対処法は、Dockerに依存しないネイティブインストールに切り替えること。Ollama自体はDocker不要で動くので、対話画面だけ自作すれば代替できる

同じ環境で同じ壁にぶつかっている方の参考になれば幸いです。

この記事は、個人的な検証（クラウドGPU上でのローカルLLM構築）の記録として、2026年9月時点の情報をもとに書いています。RunPodの仕様・UI・料金体系は今後変更される可能性があるため、実際に試す際は必ず最新の公式ドキュメントもあわせてご確認ください。

出典

Overview – Runpod Documentation — 「Runpod runs Docker for you, so you cannot spin up your own Docker instance or use Docker Compose on Pods.

Enhanced CPU Pods Now Support Docker and Network Volumes（2026年9月13日付） — 以前のKataベースPodではDocker-in-Dockerが使えたが、現行ランタイムでは廃止されたという記述の出典

Docker in Docker: ‘unshare: operation not permitted’ when running GitHub Actions Runner on Azure Container Apps · Issue #513
Docs feedback: Troubleshoot buildah: Error during unshare(CLONE_NEWUSER): Operation not permitted

E: Failed to unshare: Operation not permitted – CircleCI Discuss Linux – Ollama Docs — curl -fsSL https://ollama.com/install.sh | sh の確認

Introduction – Ollama API Docs — /api/generate エンドポイントの確認元 qwen2.5:7b – Ollama Library — モデル実在の確認

ollama/scripts/install.sh at main