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

このページに含む情報は、どのようにして原因を追及し、問題を解決し、Docker Desktop のサポート要求、ログを送信し、Docker Desktop のチームとやりとりし、フォーラムやナレッジ・ハブで使ったり、GitHub 上で問題を見たり記録したり、既知の問題に対する回避策を発見する方法です。

トラブルシュート ¶

メニューバーにある Docker のアイコン > Troubleshoot を選択し、トラブルシュートのオプションを表示します。

トラブルシュートのページには、以下のオプションを含みます。

Restart Docker Desktop （Docker Desktop の再起動）: 選択すると、Docker Desktop を再起動します。

Support ：有償 Docker サブスクリプション利用者は、このオプションを使ってサポートリクエストを送信できます。他の利用者がこのオプションを使うと、Docker Desktop 上のあらゆる問題を診断します。診断に関する詳細情報は、 win-diagnose-and-feedback をご覧ください。

Reset Kubernetes cluster （Kubernetes クラスタのリセット）: このオプションを選択すると、全てのスタックと Kubernetes リソースを削除します。詳しい情報は Kubernetes を御覧ください。

Clean / Purge data （データ除去 / 削除）：設定などを初期値のデフォルトに戻さず、全ての Docker データをリセットします。 Hyper-V 、 WSL 2 、 Windows コンテナーから、削除したいものを選び、確認してから Delete をクリックします。

Reset to factory defaults （初期値のデフォルトにリセット）: このオプションを選択すると、Docker Desktop の全てのオプションを初期値にリセットし、Docker Desktop が始めてインストールされたのと同じ状態にします。

診断とフィードバック ¶

アプリ内診断 ¶

発生した問題が、このページ内のドキュメントで解決できない場合は、 GitHub の Docker Desktop や Docker Desktop for Mac forum で、ログデータのトラブルシュートに役立つ可能性があります。issue を報告する前に、いくつかの一般的に知られた問題を修正するため、このページが提供する情報を読むのをお勧めします。

メニュー > Troubleshoot を選択します。

オプション： Docker Desktop にサインイン。加えて、自分の Docker アカウントで入っているのを確認します。

Get support をクリック。これはアプリ内の Support ページを開き、診断情報の収集を開始します。

診断情報の収集が終われば、 Upload to get a Diagnostic ID をクリックします。

診断情報のアップロードが完了すると、 Docker Desktop は Diagnostic ID（診断 ID）を表示します。この ID をコピーします。

有償 Docker サブスクリプションを持っている場合は、 Contact Support をクリック。これは Docker Desktop サポートフォームを開きます。必要な情報を入力し、Diagnostics ID フィールドには先ほどコピーした ID を入れます。Docker Desktop サポートをリクエストするには Submit をクリックします。

注釈

サポートフォームにアクセスするには、Docker Desktop に Pro、Team、Business いずれかの認証賞情報でサインインしている必要があります。Docker Desktop サポートで扱う情報については、サポートをご覧ください。

有償 Docker サブスクリプションが無い場合、既存のアカウントをアップグレードするために Upgrade to benefit from Docker Support がクリック出来ます。あるいは、 Report a Bug をクリックし、GitHub に新しい Docker Desktop の issue を開きます。これは、GitHub 上の Docker Desktop for Mac をブラウザで開き、「New issue」テンプレートを使います。必要情報を入力し、先ほどコピーした診断 ID を追加します。新しい issue を作成するには submit new issue をクリックします。

ターミナルから診断 ¶

例えば Docker Desktop for Windows が開始できないなど、場合によっては自分での診断実行が役立つ場合もあります。

まず com.docker.diagnose を探します。大抵は C:Program FilesDockerDockerresourcescom.docker.diagnose.exe にあるでしょう。

診断の作成とアップロードをするには、次のコマンドを実行します：

PS C:\> & "C:\Program Files\Docker\Docker\resources\com.docker.diagnose.exe" gather -upload

診断が終了したら、以下のように診断 ID を含む出力になります。

Diagnostics Bundle: C:\Users\User\AppData\Local\Temp\CD6CF862-9CBD-4007-9C2F-5FBE0572BBC2\20180720152545.zip
Diagnostics ID:     CD6CF862-9CBD-4007-9C2F-5FBE0572BBC2/20180720152545 (uploaded)

有償 Docker サブスクリプションを持っている場合は、 Contact Support をクリック。これは Docker Desktop サポートフォームを開きます。必要な情報を入力し、Diagnostics ID フィールドには先ほどコピーした ID を入れます。Docker Desktop サポートをリクエストするには Submit をクリックします。

Docker Desktop には、共通する問題を確認するのに役立つ自己診断ツールが入っています。自己診断ツールを実行する前に、 com.docker.diagnose を探します。アプリケーションのディレクトリ内に Docker Desktop をインストールしている場合は、自己診断ツールの場所は C:\Program Files\Docker\Docker\resources\com.docker.diagnose.exe です。

自己診断ツールを実行するには、次のように実行します。

PS C:\> & "C:\Program Files\Docker\Docker\resources\com.docker.diagnose.exe" check

ツールはチェックの一式を実行し、それぞれのチェックごとに PASS か FAIL を表示します。何らかのエラーがあれば、レポートの最後で最も関連する情報をハイライトで表示します。

注釈

フィードバック

自己診断ツールのフィードバックを、 GitHub の for-mac リポジトリで issue を作成して教えてください。

トラブルシューティング ¶

証明書の正しいセットアップを確実にする ¶

Docker Desktop は安全ではないレジストリ（insecure registry）上にある証明書を無視します。また、そちらに対してクライアント証明書も送りません。 docker run のようなコマンドでは、レジストリからの取得（pull）を試みても、次のようなコマンドライン上のエラーメッセージを表示します。

Error response from daemon: Get http://192.168.203.139:5858/v2/: malformed HTTP response "\x15\x03\x01\x00\x02\x02"

レジストリ側でも同様にエラーが出ます。こちらが例です。

2017/06/20 18:15:30 http: TLS handshake error from 192.168.203.139:52882: tls: client didn't provide a certificate
2017/06/20 18:15:30 http: TLS handshake error from 192.168.203.139:52883: tls: first record does not look like a TLS handshake

クライアントとサーバ側証明書の使用に関しては、導入ガイドのトピックにある win-add-custom-ca-certificates-server-side と win-add-client-certificates: を御覧ください。

ボリューム ¶

共有ボリュームにおける、データディレクトリ上の権限（permission）エラー ¶

Docker Desktop は共有ボリューム上の権限（パーミッション）をデフォルトで 0777 （ ユーザ 及び グループ に対して、 読み込み ・ 書き込み ・ 実行 の権限）に設定します。

共有ボリューム上におけるデフォルトの権限は、変更できません。もしも、アプリケーションの動作上、デフォルトの共有ボリューム上でコンテナ実行時に異なる権限が必要となる場合は、ホストをマウントしないボリュームを使用するか、アプリケーション側が初期設定の権限で動作する設定を見つける必要があります。

また、 can-i-change-permissions-on-shared-volumes-for-container-specific-deployment-requirements もご覧ください。

共有ドライブ上へのボリュームマウントが Linux コンテナに必要です ¶

マウントボリュームを使用中に、アプリケーションファイルが見つからないというランタイムエラーが表示される場合は、ボリュームマウントに対するアクセスが拒否されているか、あるいは、 :doc:` Docker Compose </compose/gettingstarted>` などを使っていてサービスが開始できない場合には、共有フォルダの有効化が必要でしょう。

Hyper-V バックエンドで、Windows から Linux コンテナにボリュームをマウントするには、共有フォルダが必要です。Docker アイコンをクリックし、それから Settings > Shared Folders を選び、Dockerfile とボリュームを置くためのフォルダを共有します。

シンボリックリンク（symlinks）のサポート ¶

シンボリックリンクはコンテナ間および横断して機能します。詳しく学ぶには、 FAQ の how-do-symlinks-work-on-windows をご覧ください。

予期しない構文エラー（unexpected syntax error）を避けるため、コンテナ内でファイルの行末を unix 風にする ¶

コンテナ内で実行するあらゆるファイルは、 Unix 風の行末 n を使う必要があります。これをファイルに含むのは、ビルド用のコマンドラインや Dockerfile における RUN 命令で参照するからです。

Docker コンテナと docker build の実行は Unix 環境のため、コンテナ内のファイルは Unix 風の行末 n を使うのが必須です。 Window 風の rn ではありません。シェルスクリプトのようなファイルを作成するときは、Windows ツールを使うとデフォルトで Windows 風の行末になるので、気に留めておいてください。各コマンドは、最終的には Unix をベースするコンテナ内の Unix コマンドに渡されます（例えば、シェルスクリプトは /bin/sh に渡されます）。もしも Windows 風の行末が用いられると、 docker run は構文エラーになり失敗します。

この問題と解決方法の例は、GitHub 上の issue を御覧ください： Docker RUN でシェルスクリプトの実行に失敗する（英語）

Windows 上でのパス変換 ¶

Linux 上では、マウントしているパスを、他のパスへと管理しています。たとえば、Linux 上で以下のコマンドを実行するとします。

$ docker run --rm -ti -v /home/user/work:/work alpine

これは対象のコンテナに /work ディレクトリを追加し、指定したパスの内容をミラーします。

しかしながら、Windows 上では、元のパス（ソースパス）を変更する必要があります。たとえば、レガシーの Windows シェル（ cmd.exe ）を使っている場合、以下のコマンドが使えます。

$ docker run --rm -ti -v C:\Users\user\work:/work alpine

これはコンテナを起動し、ボリュームを利用可能な状態にします。Docker Desktop は Windows 形式のパスを見つけると、ディレクトリをマウントするため、適切に変換する場合があります。

Docker Desktop でも適切な形式で Unix 風のパスを指定できます。例：

$ docker run --rm -ti -v /c/Users/user/work:/work alpine ls /work

Git Bash で動かす ¶

$ docker run --rm -ti -v C:\Users\user\work:/work alpine
docker: Error response from daemon: mkdir C:UsersUserwork: Access is denied.

エラーになるのは、 Git Bush では \ 記号が特別な意味を持つためです。Bit Bash を使う場合は、無効化する \\ を使う必要があります。

$ docker run --rm -ti -v C:\\Users\\user\\work:/work alpine

また、スクリプト内で pwd コマンドを使う場合は、ファイルシステムの場所をハードコーディングしないように使われます。出力は Unix 風のパスです。

$ pwd
/c/Users/user/work

$() 構文を組み合わせる場合、 Linux では以下のコマンドは動作しますが、 Git Bash では失敗します。

$ docker run --rm -ti -v $(pwd):/work alpine
docker: Error response from daemon: OCI runtime create failed: invalid mount {Destination:\Program Files\Git\work Type:bind Source:/run/desktop/mnt/host/c/Users/user/work;C Options:[rbind rprivate]}: mount destination \Program Files\Git\work not absolute: unknown.

この問題に対応するには、追加の / を使います。

$ docker run --rm -ti -v /$(pwd):/work alpine

Linux は複数の / を１つの入力として扱うため、スクリプトの互換性には影響ありません。１行でパスを扱う場合は、無効化する必要があります。

$ docker run --rm -ti -v /$(pwd):/work alpine ls /work
ls: C:/Program Files/Git/work: No such file or directory

この例では、 / が先にあるため、 $(pwd) は変換されません。ですが、２つめの /work は Docker Desktop で処理する前に、 POSIX レイヤーによって変換されます。これを正しく動作するには、 / を追加します。

$ docker run --rm -ti -v /$(pwd):/work alpine ls //work

スクリプトや他のソースでエラーが発生する場合、どこか原因かを確認するには、環境変数が使えます。例：

$ MSYS_NO_PATHCONV=1 docker run --rm -ti -v $(pwd):/work alpine ls /work

ここでは、環境変数そのものを想定しています。（環境変数の）値は関係ありません。

場合によっては、 MSYS もコロンをセミコロンに変換します。 ~ を使う時、 POSIX レイヤーが DOS のパスに変更する時に発生する状況と似ています。この場合、 MSYS_NO_PATHCONV も動作します。

仮想化 ¶

Docker Desktop を正しく機能するには、マシンには以下の機能が必要です。

WSL 2 と Windows Home ¶

仮想マシンプラットフォーム
Linux 用 Windows サブシステム (WSL)
BIOS で仮想化を有効
Windows 起動時にハイパーバイザーを有効化

Hyper-V ¶

Windows 10 Pro や Enterprise では、以下の機能を有効にして Hyper-V も使えます。

Hyper-V をインストールして、動作させる
BIOS で仮想化の有効化
Windows 起動時にハイパーバイザーを有効化

Docker Desktop をインストールして有効化するには、 Hyper-V と同様に Windows Powershell 用 Hyper-V モジュールも必要です。Docker Desktop インストーラは、これらを有効化します。

また、Docker Desktop は Hyper-V を使うために2つの CPU 機能を使います。すなわち、仮想化と Rapid Virtualization Indexing (RVI) とも呼ばれる Second Level Address Translation (SLAT) です。同じシステムの BIOS 上で、Virtualization （仮想化）の有効化が必須です。必要な手順はベンダによって異なりますが、典型的な BIOS オプションは Virtualization Technology (VTx) と呼ばれるものか、似たようなものです。Hyper-V 機能が必要とする全てを確認するには、 systeminfo コマンドを実行します。詳細は Windows 10 Hyper-V のシステム要件を御覧ください。

Hyper-V を手動でインストールするには、 Windows 10 上に Hyper-V をインストールするを御覧ください。インストール後は再起動が必要です。Hyper-V をインストールしても再起動をしないと、 Docker Desktop は正しく動作しません。

スタートメニューから、 Windows 機能の有効化又は無効化 を入力し、エンターを押します。以下の画面のようになっていると、Hyper-V は有効です。

仮想化を必ず有効化 ¶

Hyper-V や WSL 2 を追加するには、仮想化の有効化が必要です。タスクマネージャー上のパフォーマンスタブをクリックします。

もしも Hyper-V を手動でアンインストールするか、仮想化を無効にしたら、Docker Desktop は起動できません。 [Windows 10 Enterprise では Docker for Windows を実行できません（英語）](https://github.com/docker/for-win/issues/74) を御覧ください。

Windows のスタートアップでハイパーバイザを有効化 ¶

前述の手順を全て実施しても Docker Desktop の起動に問題が出ている場合は、ハイパーバイザーはインストールされているものの、Windows のスタートアップ（起動処理）中に起動できていない可能性があります。同様のツール（Virtual Box の古いバージョン）やビデオゲームのインストーラが、起動時にハイパーバイザーを無効化します。再度、有効化するには、次の手順をします。

管理者としてコマンドプロンプトを開く。
bcdedit /set hypervisorlaunchtype auto を実行
Windows 再起動

また、 Microsoft TechNet の記事にある Code flow guard (CFG) 設定もご覧ください。

Windows コンテナーと Windows Server ¶

Windows Server 上での Docker Desktop はサポート外です。Windows 10 上で Windows コンテナの実行に関する疑問があれば、 switch-between-windows-and-linux-containers を御覧ください。

docker/labs の Getting Started with Windows Container に全てのチュートリアルがあります。 .. .. You can install a native Windows binary which allows you to develop and run Windows containers without Docker Desktop. However, if you install Docker this way, you cannot develop or run Linux containers. If you try to run a Linux container on the native Docker daemon, an error occurs:

ネイティブな Windows バイナリをインストールしたら、Windows Desktop がなくても Windows コンテナの開発と実行が可能です。しかし、この方法で Docker をインストールしたら、Linux コンテナの開発と実行ができません。もしもネイティブな Docker デーモンで Linux コンテナの実行を試みても、次のようなエラーが発生します。

C:\Program Files\Docker\docker.exe:
 image operating system "linux" cannot be used on this platform.
 See 'C:\Program Files\Docker\docker.exe run --help'.

ネストした仮想化環境で Docker Desktop を実行 ¶

Paralles や VMware Fusion a Mac 上で動く Windows 10 仮想マシン内で、適切な設定をすると Docker Desktop を実行可能です。しかしながら、ハードウェア仮想化アプリの手法によって、問題や一時的な問題が発生する可能性があります。そのため、 Docker Desktop はネストした仮想化環境での実行をサポートしません 。動く場合もあれば、動かない場合もあります。

最良の結果を出すには、Windows システム上で Docker Desktop をネイティブに実行するのを推奨します（Windows コンテナも Linux コンテナも動作します）。また Mac では Linux コンテナのみ動作します。

それでもネスト化した仮想化環境を使いたい場合には ¶

VMware や Paralles でネスト化した仮想化サポートが有効になっているかどうかを確認します。設定の Hardware > CPU & Memory > Advanced Options > Enable nested virtualization を確認します（展開するメニュー順番は、若干変わるかもしれません）。
仮想マシンが最小 2 CPU と、ワークロードを実行するための十分なメモリを使うように設定します。
システムは多少のアイドル（余裕）があるようにします。
Windows OS を最新版へ確実に更新します。insider ビルドによっては、複数の問題があります。
適切なプロセッサも必要です。例えば、Westmere ベースの Mac Pro は、Nehalem ベースの Mac Pro よりもハードウェア仮想化機能が追加されていますし、更に新しい世代のインテルプロセッサもそうでしょう。

ネスト化した仮想化環境で起こる典型的な問題 ¶

Linux 仮想マシンのブート時に確認します。ログを見て、 Moby を先頭に含む行がないかどうか調べます。実在のハードウェアでは、Linux 仮想マシンのブートにかかる時間は 5 ～ 10 秒です。つまり、おおよその時間は、 Connected のログ記録から * Starting Docker ... [OK] ログ記録までです。もしも Windows 仮想マシン内で Linux 仮想マシンをブートするのであれば、この処理にかかる時間はより長くなります。タイムアウトは 60 秒以上です。もし VM が時間までに起動しなければ、リトライします。リトライに失敗したら、エラーを表示します。Windows 仮想マシンに対し、更にリソースを提供することで回避可能な場合があります。

ブート時、タイムスタンプ・カウンタ（TSC）の補正を Linux が行うとき、仮想マシンが落ちる場合があります。この処理はタイミングがセンシティブなため、仮想マシン内で仮想マシンを実行する場合に落ちるかもしれません。また、 CPU 使用率も高くなります。

Paralles on Mac では "PMU Virtualizatoin" が無効かどうかを確認します。設定の Hardware > CPU & Memory > Advanced Settings > PMU Virtualization を確認します。

ネットワーク機能の問題 ¶

Docker Desktop は（まだ） IPv6 をサポートしていません。

回避策（ワークアラウンド）¶

再起動 ¶

PC を再起動し、以前にインストールしたバージョンで動いているデーモンの残骸を、停止・削除します。

`DOCKER_HOST` のリセット（unset）¶

DOCKER_HOST 環境変数の設定は不要です。 bash を使用する場合は、リセットのために unset ${!DOCKER_*} コマンドを使います。他のシェルの場合は、シェルのドキュメントをご確認ください。

ウェブサーバの例で Docker が動作しているのを確認 ¶

hello-world-nginx サンプルなどを使い、 Docker Desktop で https://localhost 上にウェブサーバを起動します。メニューバー上に Docker 鯨（のアイコン）があるのを確認し、シェル上の Docker コマンドが Docker Desktop エンジンに接続しているのを確認します（Toolbox のエンジンではありません）。そうしなければ、ウェブサーバ・コンテナは実行できるかもしれませんが、 docker は "web page not available"（ウェブページが表示できません）というエラーを返すでしょう。

`port already allocated` （ポートが既に割り当てられています）エラーを解決するには ¶

Bind for 0.0.0.0:8080 failed: port is already allocated や listen tcp:0.0.0.0:8080: bind: address is already in use ... のようなエラーが出ることがあるでしょう。

これらのエラーは、Windows 上の他のソフトウェアが各ポートを使っている場合によく発生します。どのソフトウェアが使っているかを見つけるか、 resmon.exe の GUI を使い "Network" と "listening Ports" をクリックするか、 Powershell 上では netstat -aon | find /i "listening " を使って、対象ポートを現在使っているプロセスの PID を見つけます（PID の値は行の右端です）。他のプロセスの停止を決めるか、あるいは、docker アプリで別のポートを使うかを決めます。

アンチウィルスソフトウェアをインストールしていると、Docker Desktop の起動に失敗 ¶

いくつかのアンチウィルスソフトウェアは、Hyper-V と Microsoft Windows 10 ビルドによっては互換性がない場合があります。典型的に発生するのは Windows update 直後で、Docker デーモンからエラーの反応が表示され、Docker Desktop の起動に失敗します。

一時的な回避策としては、アンチウィルスソフトウェアをアンインストールするか、Docker Desktop フォーラム上での他の回避策をお探しください。

サポート ¶

このセクションでは、サポートを得る手順と、 Docker Desktop のサポート範囲を扱います。

注釈

この機能は有償 Docker サブスクリプションが必要です

Docker Desktop は Pro、Team、Business を契約している開発者向けにサポートを提供します。Docker サポートの利点を得るには、いますぐアップグレードしましょう。

いますぐアップグレード

Docker Desktop のサポートを得るには ¶

有償 Docker サブスクリプションがあれば、 Docker Desktop support を通してチケットを上げてください。

Docker Community 利用者は、 Github リポジトリ for-win と for-mac を通してサポートを得られますが、対応は基本的にベストエフォートです。

何のサポートを得られるのか ¶

有償 Docker サブスクリプションを持っていれば、以下の種類の問題に対するサポートを要求できます。

Desktop アップグレードの問題
Desktop インストールの問題
- インストールのクラッシュ
- Docker Desktop 初回実行時のエラー
利用に関係する問題
- クラッシュによってソフトウェアが閉じる
- Docker Desktop が期待通りの挙動をしない
設定に関する問題
基本的なプロダクトの「使い方」の質問

何がサポートされないか ¶

Docker Desktop のサポートから、以下の種類の問題は対象外です。

ドキュメントで対象としていないハードウェアやソフトウェアに関連する使い方
サポートしていないオペレーティングシステム上での実行で、オペレーティングシステムのベータもしくはプレビューバージョンも含む
エミュレーションを使用し、異なるアーキテクチャのコンテナを実行
Docker Engine、 Docker CLI 、あるいは他に同梱されている Linux コンポーネントに対するサポート
Kubernetes サポート
実験的と表記されている機能
システムやサーバ管理の取り組み
本番環境での Desktop 実行に関するサポート
Desktop をスケールするデプロイや複数マシンへのインストール
定期的なプロダクトのメンテナンス（データバックアップ、ディスク容量をあけたり、ログローテーションの設定）
Docker によって知恵教されていないサードパーティ製アプリケーション
Docker ソフトウェアの改変や編集
ハードウェア故障、不正利用、不適切な利用による Docker ソフトウェアの不具合
最新バージョンではない、あらゆる古いバージョンの Docker ソフトウェア
Docker が提供していないサードパーティ製サービスに対する補償や費用請求
Docker サポートから、トレーニング、カスタマイズ、インテグレーションは除外

Logs and troubleshooting: https://docs.docker.com/desktop/windows/troubleshoot/Logs and troubleshooting