Windows Subsystem for Linux のトラブルシューティング

以下では WSL に関連するいくつかの一般的なトラブルシューティング シナリオについて説明していますが、GitHub 上の WSL 製品リポジトリに報告されているイシューを検索することもご検討ください。

イシュー、バグ レポート、機能要求を報告する

WSL 製品リポジトリのイシューを使用すると、次のことが行えます。

  • 既存のイシューを検索して、自分の問題に関連するものがあるかどうかを確認します。 検索バーで "is:open" を削除すると、既に解決されているイシューを検索に含めることができることに注意してください。 優先して進めて欲しいと思う未解決のイシューには、コメントを付けたり賛成したりすることをご検討ください。
  • 新しいイシューを報告します。 WSL で問題が見つかり、既存のイシューが存在していないようである場合は、緑色の [New issue](新しいイシュー) ボタンを選択した後、 [WSL - Bug Report](WSL - バグ レポート) を選択します。 イシューのタイトル、お使いの Windows のビルド番号 (現在のビルド # を確認するには cmd.exe /c ver を実行します)、WSL 1 と 2 のどちらを実行しているか、現在の Linux カーネル バージョン # (wsl.exe --status または cat /proc/version を実行)、ディストリビューションのバージョン # (lsb_release -r を実行)、関連するその他のソフトウェアのバージョン、再現手順、想定される動作、実際の動作、および診断ログを含める必要があります (使用可能かつ適切な場合)。 詳細については、WSL への投稿に関するページを参照してください。
  • 機能要求を報告します。それには、緑色の [New issue](新しいイシュー) ボタンを選択してから、 [Feature request](機能要求) を選択します。 いくつかの問題に対処して、要求を説明する必要があります。

次のこともできます。

インストールに関する問題

  • エラー 0x80070003 が発生してインストールに失敗しました

    • Windows Subsystem for Linux はシステム ドライブ (通常、これは C: ドライブ) でのみ実行されます。 ディストリビューションがシステム ドライブに格納されていることを確認します。
    • Windows 10 の場合は [設定] ->[システム] ->[ストレージ] ->[その他のストレージ設定: 新しいコンテンツの保存先を変更する] を開きます。Picture of system settings to install apps on C: drive (Windows 10)
    • Windows 11 の場合は [設定] ->[システム] ->[ストレージ] ->[ストレージの詳細設定] ->[新しいコンテンツの保存先] を開きます。Picture of system settings to install apps on C: drive (Windows 11)
  • WslRegisterDistribution failed with error 0x8007019e (エラー0x8007019e で WslRegisterDistribution が失敗しました)

    • Windows Subsystem for Linux オプション コンポーネントが有効になっていません。
    • [コントロール パネル] ->[プログラムと機能] ->[Windows の機能の有効化または無効化] を開いて、[Linux 用 Windows サブシステム] をチェックするか、この記事の冒頭に記載された PowerShell コマンドレットを使用します。
  • インストールがエラー 0x80070003 またはエラー 0x80370102 で失敗した

    • コンピューターの BIOS 内部で仮想化が有効になっていることを確認してください。 これを行う方法の手順は、コンピューターによって異なりますが、最も可能性が高いのは CPU 関連のオプションの下です。
    • WSL2 を使用するには、CPU で Second Level Address Translation (SLAT) 機能がサポートされている必要があります。これは Intel Nehalem プロセッサ (Intel Core 第 1 世代) と AMD Opteron で導入されました。 以前の CPU (Intel Core 2 Duo など) では、仮想マシン プラットフォームが正常にインストールされていても、WSL2 を実行できません。
  • アップグレードしようとしたときに次のエラーが発生する: Invalid command line option: wsl --set-version Ubuntu 2

    • Linux 用 Windows サブシステムが有効になっていることと、Windows ビルド バージョン 18362 以降を使用していることを確認してください。 WSL を有効にするには、PowerShell プロンプトで管理者特権を使用してこのコマンドを実行します: Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
  • 仮想ディスク システムの制限があるため、要求された操作を完了できませんでした。 仮想ハード ディスク ファイルは、圧縮と暗号化が解除されている必要があります。また、スパースにすることはできません。

    • Linux ディストリビューションのプロファイル フォルダーを開いて、[内容を圧縮] ([内容を暗号化] のチェックボックスがオンになっている場合はこれも) を選択解除します。 これは、Windows ファイル システムのフォルダーにあります (例: %USERPROFILE%\AppData\Local\Packages\CanonicalGroupLimited...)。
    • この Linux ディストリビューション プロファイル内に、LocalState フォルダーが存在します。 このフォルダーを右クリックして、オプションのメニューを表示します。 [プロパティ] > [詳細設定] の順に選び、[内容を圧縮してディスク領域を節約する] と [内容を暗号化してデータをセキュリティで保護する] のチェックボックスを確実にオフにします。 これを現在のフォルダーのみに適用するか、すべてのサブフォルダーとファイルに適用するかを確認するメッセージが表示された場合は、圧縮フラグをクリアしようとしているだけなので、[このフォルダーのみ] を選びます。 この操作を実行すると、wsl --set-version コマンドが機能するようになります。

Screenshot of WSL distro property settings

Note

この例では、Ubuntu 18.04 ディストリビューションの LocalState フォルダーの場所は次のとおりです。C:\Users<my-user-name>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc

この問題の最新情報が追跡されている WSL ドキュメント GitHub スレッド #4103 をご確認ください。

  • "wsl" という用語が、コマンドレット、関数、スクリプト ファイル、または操作可能なプログラムの名前として認識されません。

  • エラー: Linux 用 Windows サブシステムにインストールされたディストリビューションがありません。

    • WSL ディストリビューションをインストールした後に、このエラーが表示された場合:
    1. コマンド ラインから呼び出す前に、ディストリビューションを少なくとも 1 回実行します。
    2. 別のユーザー アカウントを実行している可能性があるかどうかを確認します。 管理者アクセス許可で (管理者モードで) プライマリ ユーザー アカウントを実行するとこのエラーは発生しませんが、Windows に付属する組み込みの Administrator アカウントを誤って実行していないか確認する必要があります。 これは別のユーザー アカウントであり、インストールされている WSL ディストリビューションは設計上表示されません。 詳細については、「ビルトイン Administrator アカウントの有効化と無効化」を参照してください。
    3. WSL 実行可能ファイルは、ネイティブのシステム ディレクトリにのみインストールされます。 64 ビットの Windows 上 (または ARM64 上など、ネイティブではない組み合わせ) で 32 ビットのプロセスを実行すると、ホストされているネイティブではないプロセスでは、実際には別の System32 フォルダーが認識されます (x64 Windows で 32 ビット プロセスが認識するものは、ディスクの \Windows\SysWOW64 に格納されています。)仮想フォルダー \Windows\sysnative を参照すると、ホストされているプロセスから "ネイティブ" system32 にアクセスできます。 これは実際にはディスク上に存在しませんが、ファイル システム パス リゾルバーによって見つかります。
  • Error:この更新プログラムは、Linux 用 Windows サブシステムを搭載したマシンにのみ適用されます。

    • Linux カーネル更新プログラム MSI パッケージをインストールするには、WSL が必要であり、最初に有効にする必要があります。 失敗した場合は、"This update only applies to machines with the Windows Subsystem for Linux" というメッセージが表示されます。
    • このメッセージが表示される理由として、次の 3 つが考えられます。
    1. WSL 2 をサポートしていない古いバージョンの Windows を使用しています。 バージョン要件と更新プログラムへのリンクについては、手順 2 を参照してください。

    2. WSL が有効になっていません。 手順 1 に戻り、お使いのマシンでオプションの WSL 機能が有効になっていることを確認する必要があります。

    3. WSL を有効にした後、再起動しないと、効力が発しません。マシンを再起動してから、もう一度お試しください。

  • エラー: WSL 2 のカーネル コンポーネントを更新する必要があります。 詳細については、https://aka.ms/wsl2kernel にアクセスします。

    • Linux カーネル パッケージが %SystemRoot%\system32\lxss\tools フォルダーにない場合、このエラーが発生します。 このインストール手順の手順 4 に従って Linux カーネル更新プログラム MSI パッケージをインストールすることにより、このエラーを解決できます。 [プログラムの追加と削除] から MSI をアンインストールして、インストールし直すことが必要な場合があります。

一般的な問題

Windows 10 バージョン 1903 を使用しているものの、WSL 2 のオプションがまだ表示されない

これはおそらく、お客様のマシンが WSL 2 のバックポートをまだ取得していないことが原因です。 これの最も簡単な解決方法は、Windows 設定に移動し、[更新プログラムの確認] をクリックして最新の更新プログラムをお客様のシステムにインストールすることです。 バックポート取得の詳細な手順をご覧ください。

[更新プログラムの確認] を押しても更新プログラムが届かない場合は、手動で KB4566116 をインストールすることができます。

エラー: 0x1bc (wsl --set-default-version 2 の場合)

これは、[表示言語] または [システム ロケール] の設定が英語ではない場合に発生する可能性があります。

wsl --set-default-version 2
Error: 0x1bc
For information on key differences with WSL 2 please visit https://aka.ms/wsl2

0x1bc の実際のエラーは次のとおりです。

WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kernel

詳細については、問題 5749 を参照してください。

Windows から WSL ファイルにアクセスできない

9P プロトコル ファイル サーバーは、Linux 側のサービスを提供して、Windows が Linux ファイル システムにアクセスできるようにします。 Windows で \\wsl$ を使用して WSL にアクセスできない場合は、9P が正常に開始されなかった可能性があります。

これを確認するには、dmesg |grep 9p によってスタートアップ ログをチェックして、エラーを表示します。 正常な出力は次のようになります。

[    0.363323] 9p: Installing v9fs 9p2000 file system support
[    0.363336] FS-Cache: Netfs '9p' registered for caching
[    0.398989] 9pnet: Installing 9P2000 support

この問題の詳細については、この GitHub スレッドを参照してください。

WSL 2 ディストリビューションを開始できず、出力で 'WSL 2' のみが表示される

表示言語が英語でない場合は、切り捨てられたエラー テキストが表示される可能性があります。

C:\Users\me>wsl
WSL 2

この問題を解決するには、https://aka.ms/wsl2kernel にアクセスし、そのドキュメント ページの指示に従って手動でカーネルをインストールしてください。

Linux で Windows の .exe を実行すると、command not found と表示される

ユーザーは、notepad.exe などの Windows の実行可能ファイルを Linux から直接実行できます。 場合によっては、次のように "command not found" と表示されることがあります。

$ notepad.exe
-bash: notepad.exe: command not found

$PATH に Win32 パスがないと、相互運用によって .exe が検出されません。 これを確認するには、Linux で echo $PATH を実行します。 出力に Win32 パス (たとえば、/mnt/c/Windows) が表示されるはずです。 Windows パスが表示されない場合は、Linux シェルによって PATH が上書きされている可能性があります。

次に、Debian 上で /etc/profile が原因でこの問題が起こった例を示します。

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi

Debian での正しい方法は、上記の行を削除することです。 以下に示すように、割り当て時に $PATH を追加することもできますが、これは WSL と VSCode に関連するその他の問題につながります。

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$PATH"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:$PATH"
fi

詳細については、問題 5296 と問題 5779 を参照してください。

"Error:0x80370102 The virtual machine could not be started because a required feature is not installed." (エラー: 0x80370102 必要な機能がインストールされていないため、仮想マシンを起動できませんでした。)

仮想マシン プラットフォームの Windows 機能を有効にし、BIOS で仮想化が有効になっていることを確認してください。

  1. Hyper-V のシステム要件を確認

  2. マシンが VM の場合は、入れ子になった仮想化 を手動で有効にしてください。 powershell を管理者権限で起動し、以下のコマンドを実行します。その際、<VMName> はホスト システム上の仮想マシンの名前(Hyper-V マネージャーで見つけることができます)で置き換えてください。

    Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
    
  3. 仮想化を有効にする方法については、お使いの PC の製造元のガイドラインに従ってください。 一般に、これらの機能が CPU で確実に有効になるようにするには、システム BIOS の使用が必要になる場合があります。 このプロセスの手順は、マシンによって異なる場合があります。一例として、Bleeping Computer によるこの記事を参照してください。

  4. Virtual Machine Platform のオプションのコンポーネントを有効にしたら、コンピューターを再起動してください。

  5. ブート構成でハイパーバイザーの起動が有効になっていることを確認してください。 これを検証するには、以下を実行します (管理者特権の PowerShell)。

     bcdedit /enum | findstr -i hypervisorlaunchtype
    

    hypervisorlaunchtype Off が表示された場合、ハイパーバイザーは無効になっています。 これを有効にするには、管理者特権の PowerShell で以下を実行します。

     bcdedit /set hypervisorlaunchtype Auto
    
  6. また、サード パーティ製ハイパーバイザーをインストールしている場合 (VMware や VirtualBox など) は、それらが HyperV をサポートできる最新バージョン (VMware 15.5.5+ および VirtualBox 6+) であるか、オフになっていることを確認してください。

  7. Azure 仮想マシンでこのエラーが発生した場合は、トラステッド起動が無効になっていることを確認します。 入れ子になった仮想化は、Azure 仮想マシンではサポートされていません

仮想マシンで Hyper-V を実行するときに入れ子になった仮想化の構成を行う方法をご確認ください。

職場のマシンやエンタープライズ環境で WSL からネットワークに接続できない

ビジネスまたはエンタープライズ環境では、承認されていないネットワーク トラフィックをブロックするように Windows Defender ファイアウォール設定が構成されていることがあります。 ローカル規則のマージが [いいえ] に設定されている場合、既定で WSL ネットワークは機能しないので、管理者がそれを許可するファイアウォール規則を追加する必要があります。

ローカル規則のマージの設定は、次の手順で確認できます。

Windows Firewall settings screenshot

  1. [Windows Defender Firewall with advanced security] (セキュリティが強化された Windows Defender ファイアウォール) を開きます (これは [コントロール パネル] の [Windows Defender ファイアウォール] とは別のものです)
  2. [Windows Defender Firewall with advanced security on Local Computer] (ローカル コンピューター上のセキュリティが強化された Windows Defender ファイアウォール) タブを右クリックします
  3. [プロパティ] を選びます
  4. 開いた新しいウィンドウで [パブリック プロファイル] タブを選びます
  5. [設定] セクションの [カスタマイズ] を選びます
  6. 開いた [Customize Settings for the Public Profile] (パブリック プロファイルの設定をカスタマイズする) ウィンドウで、[規則のマージ] が [いいえ] に設定されているかどうかを確認します。 されている場合、WSL へのアクセスはブロックされます。

このファイアウォール設定を変更する方法については、「Hyper-V ファイアウォールの構成」を参照してください。

VPN に接続されると、WSL からネットワークに接続できない

Windows で VPN に接続した後、bash のネットワーク接続が切断される場合は、bash 内からこの回避策を試してください。 この回避策により、/etc/resolv.conf を使用して DNS 解決を手動で上書きできます。

  1. ipconfig.exe /all を実行して、VPN の DNS サーバーをメモします
  2. sudo cp /etc/resolv.conf /etc/resolv.conf.new で、既存の resolv.conf のコピーを作成します
  3. sudo unlink /etc/resolv.conf で、現在の resolv.conf のリンクを解除します
  4. sudo mv /etc/resolv.conf.new /etc/resolv.conf
  5. /etc/wsl.conf を編集し、このコンテンツをファイルに追加します。 (この設定の詳細については、「詳細設定の構成」を参照してください)
[network]
generateResolvConf=false
  1. /etc/resolv.conf を開きます。そして、
    a. 自動生成を記述するコメントがあるファイルから最初の行を削除します。
    b. DNS サーバーの一覧の最初のエントリとして、上記 (1) の DNS エントリ を追加します。
    c. ファイを閉じます。

VPN を切断したら、変更を /etc/resolv.conf に戻す必要があります。 これを行うには、次の手順を実行します。

  1. cd /etc
  2. sudo mv resolv.conf resolv.conf.new
  3. sudo ln -s ../run/resolvconf/resolv.conf resolv.conf

NAT モードでの WSL に関する Cisco Anyconnect VPN の問題

Cisco AnyConnect VPN によって、NAT の動作を妨げる方法でルートが変更されます。 WSL 2 に固有の回避策があります。Cisco AnyConnect Secure Mobility Client 管理者ガイド、リリース 4.10 の AnyConnect のトラブルシューティングに関するページを参照してください。

ミラー化ネットワーク モードがオンの場合の VPN に関する WSL 接続の問題

ミラー化ネットワーク モードは、現在、WSL 構成の実験的設定です。 WSL の従来の NAT ネットワーク アーキテクチャは、''ミラー化ネットワーク モード'' と呼ばれるまったく新しいネットワーク モードに更新できます。 実験的な networkingModemirroredに設定されている場合、互換性を向上させるために、Windows 上にあるネットワーク インターフェイスが Linux にミラー化されます。 詳しくは、WSL September 2023 更新プログラムに関するコマンド ライン ブログを参照してください。

一部の VPN はテストされ、WSL と互換性がないことが確認されています。以下に例を示します。

  • "Bitdefender" バージョン 26.0.2.1
  • "OpenVPN" バージョン 2.6.501
  • "Mcafee Safe Connect" バージョン 2.16.1.124

WSL で HttpProxy ミラーリングに autoProxy を使用する場合の考慮事項

HTTP/S プロキシ ミラーリングは、WSL 構成ファイルの実験的セクションautoProxy 設定を使用して構成できます。 この設定を適用する場合は、これらの考慮事項に注意してください。

  • PAC プロキシ: WSL では、"WSL_PAC_URL" 環境変数を設定することで Linux で設定を構成します。 Linux では、PAC プロキシは既定ではサポートされていません。
  • WSLENV との相互作用: ユーザー定義の環境変数は、この機能で指定された環境変数よりも優先されます。

有効にすると、Linux ディストリビューションのプロキシ設定に次の内容が適用されます。

  • Linux 環境変数 HTTP_PROXY は、Windows HTTP プロキシ構成にインストールされている 1 つまたは複数の HTTP プロキシに設定されます。
  • Linux 環境変数 HTTPS_PROXY は、Windows HTTP プロキシ構成にインストールされている 1 つまたは複数の HTTPS プロキシに設定されます。
  • Linux 環境変数 NO_PROXY は、Windows 構成ターゲットで見つかった HTTP/S プロキシをバイパスするように設定されます。
  • すべての環境変数 (WSL_PAC_URL を除く) は、小文字と大文字の両方に設定されます。 たとえば、HTTP_PROXYhttp_proxy などです。

詳しくは、WSL September 2023 更新プログラムに関するコマンド ライン ブログを参照してください。

DNS トンネリングに関するネットワークの考慮事項

WSL がインターネットに接続できない場合は、Windows ホストへの DNS 呼び出しがブロックされていることが原因である可能性があります。 これは、WSL VM から Windows ホストに送信される DNS のネットワーク パケットが、既存のネットワーク構成によってブロックされるためです。 DNS トンネリングでは、仮想化機能を使用して Windows と直接通信することでこれを修正し、ネットワーク パケットを送信せずに DNS 名を解決できるようにします。 この機能により、ネットワークの互換性が向上し、VPN、特定のファイアウォールのセットアップ、またはその他のネットワーク構成がある場合でも、インターネット接続を向上させることができるはずです。

DNS トンネリングは、WSL 構成ファイルの実験的セクションdnsTunneling 設定を使用して構成できます。 この設定を適用する場合は、これらの考慮事項に注意してください。

  • ネットワークに 8.8.8.8 への DNS トラフィックをブロックするポリシーがある場合、DNS トンネリングが有効になっていると、ネイティブ Docker では、WSL で接続の問題が発生する可能性があります。
  • WSL で VPN を使用する場合は、DNS トンネリングを有効にします。 多くの VPN で NRPT ポリシーが使用されます。これは、DNS トンネリングが有効な場合にのみ WSL DNS クエリに適用されます。
  • Linux ディストリビューションの /etc/resolv.conf ファイルでは DNS サーバーの最大制限は 3 台となっていますが、Windows では 3 台を超える DNS サーバーが使用される場合があります。 DNS トンネリングを使うと、この制限が解除され、すべての Windows DNS サーバーを Linux で使用できるようになりました。
  • WSL では、Windows DNS サフィックスは次の順序で使用されます (Windows DNS クライアントで使用される順序と同様)。
    1. グローバル DNS サフィックス
    2. 補足 DNS サフィックス
    3. インターフェイスごとの DNS サフィックス
    4. Windows で DNS 暗号化 (DoH、DoT) が有効になっている場合、暗号化は WSL からの DNS クエリに適用されます。 ユーザーが Linux 内で DoH、DoT を有効にする場合は、DNS トンネリングを無効にする必要があります。
  • Docker コンテナー (Docker Desktop、または WSL で実行されているネイティブ Docker) からの DNS クエリでは、DNS トンネリングがバイパスされます。 DNS トンネリングを利用して、ホスト DNS の設定とポリシーを Docker DNS トラフィックに適用することはできません。
  • Docker Desktop には、ホスト DNS 設定とポリシーを Docker コンテナーからの DNS クエリに適用する独自の方法 (DNS トンネリングとは異なる) があります。

詳しくは、WSL September 2023 更新プログラムに関するコマンド ライン ブログを参照してください。

Windows ホストによって受信された受信トラフィックを WSL 仮想マシンにステアリングする場合の問題

ミラー化ネットワーク モード (実験的な networkingModemirrored に設定されている) を使用する場合、Windows ホストによって受信された受信トラフィックの一部が Linux VM にステアリングされることはありません。 このトラフィックは次のとおりです。

  • UDP ポート 68 (DHCP)
  • TCP ポート 135 (DCE エンドポイント解決)
  • UDP ポート 5353 (mDNS)
  • TCP ポート 1900 (UPnP)
  • TCP ポート 2869 (SSDP)
  • TCP ポート 5004 (RTP)
  • TCP ポート 3702 (WSD)
  • TCP ポート 5357 (WSD)
  • TCP ポート 5358 (WSD)

WSL では、ミラー化ネットワーク モードを使用すると、特定の Linux ネットワーク設定が自動的に構成されます。 ミラー化ネットワーク モードを使用している間のこれらの設定のユーザー構成はサポートされていません。 WSL によって構成される設定のリストを以下に示します。

設定名 Value
https://sysctl-explorer.net/net/ipv4/accept_local/ 有効 (1)
https://sysctl-explorer.net/net/ipv4/route_localnet/ 有効 (1)
https://sysctl-explorer.net/net/ipv4/rp_filter/ 無効 (0)
https://sysctl-explorer.net/net/ipv6/accept_ra/ 無効 (0)
https://sysctl-explorer.net/net/ipv6/autoconf/ 無効 (0)
https://sysctl-explorer.net/net/ipv6/use_tempaddr/ 無効 (0)
addr_gen_mode 無効 (0)
disable_ipv6 無効 (0)
https://sysctl-explorer.net/net/ipv4/arp_filter/ 有効 (1)

既定のネットワーク名前空間で実行しているときにミラー化ネットワーク モードが有効になっている WSL2 での Docker コンテナーの問題

公開ポート (docker run -publish/-p) を持つ Docker Desktop コンテナーの作成に失敗するという既知の問題があります。 WSL チームは、Docker Desktop チームと協力してこの問題に対処しています。 この問題を回避するには、Docker コンテナーでホストのネットワーク名前空間を使用します。 "docker run" コマンドで使用される "--network host" オプションを使って、ネットワークの種類を設定します。 別の回避策として、WSL 構成ファイルの実験的セクションignoredPorts 設定で、公開ポート番号を一覧表示します。

WSL の DNS サフィックス

.wslconfig ファイル中の構成に応じて、WSL は以下のビヘイビアー wrt DNS サフィックスを持ちます。

networkingMode が NAT に設定されている場合:

ケース 1) 既定では、Linux に DNS サフィックスは構成されていません

ケース 2) DNS トンネリングが有効 (.wslconfig で dnsTunneling が true に設定) の場合、すべての Windows DNS サフィックスが Linux の /etc/resolv.conf の "検索" 設定に構成されます

サフィックスは、名前の解決時に Windows DNS クライアントがサフィックスを試みる順序と同様に、最初にグローバル DNS サフィックス、次に補足 DNS サフィックス、それからインターフェイス毎の DNS サフィックスの順に /etc/resolv.conf に構成されます。

Windows DNS サフィックスに変更がある場合、その変更は Linux にも自動的に反映されます

ケース 3) DNS トンネリングが無効で、SharedAccess DNS プロキシが無効 (.wslconfig で dnsTunneling が false に、 dnsProxy が false に設定) の場合、Linux の /etc/resolv.conf の "ドメイン" 設定に単一の DNS サフィックスが構成されます

Windows DNS サフィックスに変更がある場合、その変更は Linux に反映されません

Linux に含まれる単一の DNS サフィックスは、インターフェイス毎の DNS サフィックスから選択されます (グローバルサフィックスと補足サフィックスは無視されます)

Windows に複数のインターフェイスがある場合は、ヒューリスティックを使用して Linux に含める単一の DNS サフィックスを選択します。 たとえば、Windows に VPN インターフェイスがある場合、そのインターフェイスからサフィックスが選択されます。 VPN インターフェイスが存在しない場合、サフィックスはインターネット接続を提供する可能性が最も高いインターフェイスから選択されます。

networkingMode が Mirrorred に設定されている場合:

すべての Windows DNS サフィックスは、Linux の /etc/resolv.conf の "検索" に構成されます

NAT モードの場合、 サフィックスは 2) と同じ順序で /etc/resolv.conf に構成されます

Windows DNS サフィックスに変更がある場合、その変更は Linux にも自動的に反映されます

注: 補足 DNS サフィックスは、 SetInterfaceDnsSettings - Win32 アプリ | Microsoft Learn を使用して Windows で構成できます。その際、DNS_SETTING_SUPPLEMENTAL_SEARCH_LIST フラグを [設定] パラメーターで設定します。

WSL での DNS のトラブルシューティング

WSL が NAT モードでコンテナーを起動するときの既定の DNS 構成は、Windows ホスト上の NAT デバイスが WSL コンテナーの DNS ‘サーバー’ として機能することです。 WINDOWS ホスト上のその NAT デバイスに WSL コンテナーから DNS クエリが送信されると、DNS パケットは NAT デバイスからホスト上の共有アクセス サービスに転送されます。応答は WSL コンテナーに逆方向に送信されます。 この共有アクセスへのパケット転送プロセスでは、その受信 DNS パケットを許可するファイアウォール規則が必要です。これは、WSL が最初に WSL コンテナーの NAT 仮想ネットワークを作成するように WSL サービスが HNS に要求したときに HNS サービスによって作成されます。

この NAT - 共有アクセスの設計により、WSL からの名前解決を中断する可能性がある既知の構成がいくつか存在します。

1.Enterprise では、ローカルで定義されたファイアウォール規則を許可しないポリシーをプッシュでき、エンタープライズ ポリシーで定義された規則のみが許可されます。

これがエンタープライズによって設定されている場合、HNS によって作成されたファイアウォール規則は、ローカルで定義された規則であるため無視されます。 この構成を機能させるには、エンタープライズは、共有アクセス サービスへの UDP ポート 53 を許可するファイアウォール規則を作成する必要があります。または、WSL を DNS トンネリングを使用するように設定できます。 ローカルで定義されたファイアウォール規則を許可しないように構成されているかどうかは、次のコマンドを実行して確認できます。 ドメイン、プライベート、パブリックの 3 つのプロファイルのすべてに対する設定が表示される点にご留意ください。 いずれかのプロファイルに設定されている場合、WSL vNIC にそのプロファイルが割り当てられているとパケットはブロックされます (既定値は Public です)。 これは、PowerShell で返される最初のファイアウォール プロファイルのスニペットにすぎません。

PS C:\> Get-NetFirewallProfile -PolicyStore ActiveStore
Name                            : Domain
Enabled                         : True
DefaultInboundAction            : Block
DefaultOutboundAction           : Allow
AllowInboundRules               : True
AllowLocalFirewallRules         : False

AllowLocalFirewallRules:False means the locally defined firewall rules, like that by HNS, will not be applied or used.

2.また、エンタープライズでは、すべての受信規則をブロックするグループ ポリシーと MDM ポリシー設定をプッシュダウンできます。

これらの設定は、すべての受信許可ファイアウォール規則をオーバーライドします。 この設定により、HNS によって作成された UDP ファイアウォール規則がブロックされるため、WSL が名前を解決できなくなります。 この構成を機能させるには、DNS トンネリング 使用するように WSL を設定する必要があります。この設定では、常に NAT DNS プロキシがブロックされます。

グループ ポリシーからの:

コンピューターの構成 \ 管理用テンプレート \ ネットワーク \ ネットワーク接続 \ Windows Defender ファイアウォール \ ドメイン プロファイル | 標準プロファイル

"Windows Defender ファイアウォール: 例外を許可しない" - 有効

MDM ポリシーから:

./Vendor/MSFT/Firewall/MdmStore/PrivateProfile/Shielded

./Vendor/MSFT/Firewall/MdmStore/DomainProfile/Shielded

./Vendor/MSFT/Firewall/MdmStore/PublicProfile/Shielded

以下を実行して、受信ファイアウォール規則を許可しないように構成されているかどうかを確認できます (ファイアウォール プロファイルに関する上記の注意事項を参照)。 これは、PowerShell で返される最初のファイアウォール プロファイルのスニペットにすぎません。


PS C:\> Get-NetFirewallProfile -PolicyStore ActiveStore
Name                            : Domain
Enabled                         : True
DefaultInboundAction            : Block
DefaultOutboundAction           : Allow
AllowInboundRules               : False

AllowInboundRules: False means that no inbound Firewall rules will be applied.

3.ユーザーが Windows セキュリティ設定アプリを実行し、"許可されているアプリの一覧に含まれるすべての着信接続をブロックする" コントロールをチェックします

Windows では、上記の #2 で説明したエンタープライズで適用できるのと同じ設定に対するユーザー オプトインがサポートされています。 ユーザーは、[Windows セキュリティ] 設定ページを開き、[ファイアウォールとネットワーク保護] オプションを選択し、構成したいファイアウォール プロファイル (ドメイン、プライベート、またはパブリック) を選択し、[着信接続] にある「許可されたアプリの一覧にあるアプリも含め、すべての着信接続をブロックします。」というラベルの付いたコントロールをチェックします。

これがパブリック プロファイル (WSL vNIC の既定のプロファイル) に設定されている場合、共有アクセスへの UDP パケットを許可するために HNS によって作成されたファイアウォール規則はブロックされます。

NAT DNS プロキシ構成を WSL から機能させるには、このチェックを外しておく必要があります。 または WSL が DNS トンネリングを使用するように設定しておくこともできます。

4.共有アクセスへの DNS パケットを許可する HNS ファイアウォール規則が無効になり、以前の WSL インターフェイス識別子が参照される可能性があります。 これは、最新の Windows 11 リリースで修正された HNS 内の欠陥です。 それ以前のリリースでは、これが発生した場合簡単に検出できませんが、簡単な回避策があります。

  • WSL を停止する

    wsl.exe –shutdown

  • 古い HNS ファイアウォール規則を削除します。 この Powershell コマンドは、ほとんどの場合有効に動作します:

    Get-NetFirewallRule -Name "HNS*" | Get-NetFirewallPortFilter | where Protocol -eq UDP | where LocalPort -eq 53 | Remove-NetFirewallRule

  • すべての HNS エンドポイントを削除します。 注: HNS を使用して MDAG や Windows サンドボックスなどの他のコンテナーを管理する場合は、それらのコンテナーも停止する必要があります。

    hnsdiag.exe delete all

  • HNS サービスを再起動または再起動する

    Restart-Service hns

  • WSL が再起動すると、HNS によって新しいファイアウォール規則が作成され、WSL インターフェイスを正しくターゲットします。

WSL の開始またはディストリビューションのインストールでエラー コードが返される

GitHub の WSL リポジトリの WSL ログの収集手順に従って、詳細なログを収集し、GitHub で Issue を報告します。

WSL の更新

Linux 用 Windows サブシステムには、更新が必要になることがある 2 つのコンポーネントがあります。

  1. Linux 用 Windows サブシステム自体を更新するには、PowerShell または CMD でコマンド wsl --update を使用します。

  2. 特定の Linux ディストリビューション ユーザー バイナリを更新するには、更新する Linux ディストリビューションでコマンド apt-get update | apt-get upgrade を使用します。

apt-get アップグレードのエラー

一部のパッケージでは、まだ Microsoft が実装していない機能が使用されています。 たとえば、udev はまだサポートされていないため、apt-get upgrade エラーがいくつか発生します。

udev に関連する問題を修正するには、次の手順に従います。

  1. 次の内容を /usr/sbin/policy-rc.d に記述して、変更を保存します。

    #!/bin/sh
    exit 101
    
  2. 実行のアクセス許可を /usr/sbin/policy-rc.d に追加します。

    chmod +x /usr/sbin/policy-rc.d
    
  3. 次のコマンドを実行します。

    dpkg-divert --local --rename --add /sbin/initctl
    ln -s /bin/true /sbin/initctl
    

"Error:0x80040306" がインストール時に発生

これは、従来のコンソールがサポートされていないということと関連があります。 従来のコンソールをオフにするには、以下を実行します。

  1. cmd.exe を開きます。
  2. タイトル バーを右クリックして、[プロパティ] を選択し、[従来のコンソールを使う] をオフにします
  3. [OK] をクリックします。

"Error:0x80040154" が Windows Update 後に発生

Windows Update 時に Windows Subsystem for Linux 機能が無効になる可能性があります。 その場合は、この Windows 機能を再度有効にする必要があります。 Linux 用 Windows サブシステムを有効にする手順については、手動インストール ガイドを参照してください。

表示言語の変更

WSL インストールでは、Windows インストールのロケールに合わせて Ubuntu ロケールを自動的に変更しようとします。 この動作が不要な場合は、次のコマンドを実行して、インストールの完了後に Ubuntu ロケールを変更できます。 この変更を有効にするには、bash.exe を再起動する必要があります。

次の例では、ロケールがen-USに変更されます。

sudo update-locale LANG=en_US.UTF8

Windows システムの復元後のインストールの問題

  1. %windir%\System32\Tasks\Microsoft\Windows\Windows Subsystem for Linux フォルダーを削除します。
    注: オプションの機能が完全にインストールされて動作している場合は、この操作を行わないでください。
  2. WSL オプション機能を有効にします (まだ有効にされていない場合)
  3. 再起動します
  4. lxrun /uninstall /full
  5. Bash をインストールします

WSL でインターネットにアクセスできない

一部のユーザーにより、WSL でのインターネット アクセスをブロックする特定のファイアウォール アプリケーションに関する問題が報告されています。 報告されているファイアウォールは次のとおりです。

  1. Kaspersky
  2. AVG
  3. Avast
  4. Symantec Endpoint Protection

ファイアウォールをオフにすると、アクセスできる場合があります。 場合によっては、ファイアウォールをインストールするだけでアクセスがブロックされるようです。

Microsoft Defender ファイアウォールを使用している場合は、[許可されたアプリの一覧にあるアプリも含め、すべての着信接続をブロックします。] をオフにするとアクセスが許可されます。

ping 使用時のアクセス拒否エラー

Windows Anniversary Update (バージョン 1607) では、WSL で ping を実行するには、Windows の 管理者特権 が必要です。 ping を実行するには、管理者として Bash on Ubuntu on Windows を実行するか、管理者特権を使用して CMD/PowerShell プロンプトから bash.exe を実行します。

Windows の最新バージョン (Build 14926 以降) では、管理者特権は不要になりました。

Bash がハングしている

bash を使用しているときに bash がハングしている (またはデッドロックされている) か、入力に応答していないことに気付いた場合は、Microsoft が問題を診断できるようにメモリ ダンプを収集して報告してください。 次の手順によりシステムがクラッシュすることに注意してください。 それが問題である場合は、この操作を行わないでください。または、これを行う前に作業を保存してください。

メモリ ダンプを収集するには

  1. メモリ ダンプの種類を "完全なメモリ ダンプ" に変更します。 ダンプの種類を変更するときに、現在の種類をメモしておきます。

  2. こちらの手順を使用して、キーボード コントロールを使ってクラッシュを構成します。

  3. ハングまたはデッドロックを再現します。

  4. (2) のキー シーケンスを使用してシステムをクラッシュさせます。

  5. システムはクラッシュし、メモリ ダンプを収集します。

  6. システムが再起動したら、memory.dmp を secure@microsoft.com に報告します。 ダンプ ファイルの既定の場所は、%SystemRoot%\memory.dmp です。つまり、C: がシステム ドライブである場合は、C:\Windows\memory.dmp になります。 メールには、ダンプは WSL or Bash on Windows チーム向けであることを記載します。

  7. メモリ ダンプの種類を元の設定に戻します。

ビルド番号を確認する

PC のアーキテクチャと Windows ビルド番号を確認するには、次を開きます。
[設定]>[システム]>[バージョン情報]

[OS ビルド] フィールドと [システムの種類] フィールドを探します。
Screenshot of Build and System Type fields

Windows Server のビルド番号を確認するには、PowerShell で次を実行します。

systeminfo | Select-String "^OS Name","^OS Version"

WSL が有効になっていることを確認する

Linux 用 Windows サブシステムが有効になっていることを確認するには、管理者特権の PowerShell ウィンドウで次を実行します。

Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

OpenSSH サーバーの接続に関する問題

SSH サーバーに接続しようとしましたが、次のエラーで失敗しました。"Connection closed by 127.0.0.1 port 22" (127.0.0.1 ポート 22 によって接続は閉じられました)。

  1. OpenSSH サーバーが実行されていることを確認します。

    sudo service ssh status
    

    次のチュートリアルに従っていることも確認します。 https://ubuntu.com/server/docs/service-openssh

  2. sshd サービスを停止し、デバッグ モードで sshd を開始します。

    sudo service ssh stop
    sudo /usr/sbin/sshd -d
    
  3. スタートアップ ログを調べて、HostKey が使用可能であり、次のようなログ メッセージが表示されていないことを確認します。

    debug1: sshd version OpenSSH_7.2, OpenSSL 1.0.2g  1 Mar 2016
    debug1: key_load_private: incorrect passphrase supplied to decrypt private key
    debug1: key_load_public: No such file or directory
    Could not load host key: /etc/ssh/ssh_host_rsa_key
    debug1: key_load_private: No such file or directory
    debug1: key_load_public: No such file or directory
    Could not load host key: /etc/ssh/ssh_host_dsa_key
    debug1: key_load_private: No such file or directory
    debug1: key_load_public: No such file or directory
    Could not load host key: /etc/ssh/ssh_host_ecdsa_key
    debug1: key_load_private: No such file or directory
    debug1: key_load_public: No such file or directory
    Could not load host key: /etc/ssh/ssh_host_ed25519_key
    

このようなメッセージが表示されていて、/etc/ssh/ の下にそれらのキーがない場合は、キーを再生成するか、単に purge openssh-server と install openssh-server を実行する必要があります。

sudo apt-get purge openssh-server
sudo apt-get install openssh-server

WSL オプション機能を有効にするときの [参照されているアセンブリが見つかりませんでした。]

このエラーは、インストール状態が正しくないことに関係があります。 この問題を解決するには、次の手順を実行してください。

  • PowerShell から WSL 機能を有効にするコマンドを実行している場合、代わりに GUI を使用してみてください。[スタート] メニューを開き、[Windows の機能の有効化または無効化] を検索して、一覧で [Windows Subsystem for Linux] を選択すると、オプションのコンポーネントがインストールされます。

  • [設定]、[更新] の順に移動し、[更新プログラムの確認] をクリックして、Windows のバージョンを更新します

  • 上記の両方が失敗し、WSL にアクセスする必要がある場合は、インプレース アップグレードを検討してください。インストール メディアを使って Windows を再インストールし、[すべて保持] を選ぶことにより、アプリとファイルが確実に保持されます。 これを行うための手順については、「Windows 10 を再インストールする」のページをご覧ください。

以下のエラーが表示される場合:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '/home/user/.ssh/private-key.pem' are too open.

これを修正するには、/etc/wsl.conf ファイルに以下を追加します。

[automount]
enabled = true
options = metadata,uid=1000,gid=1000,umask=0022

このコマンドを追加すると、メタデータが組み込まれ、WSL から見た Windows ファイルに対するファイルのアクセス許可が変更されることにご注意ください。 詳細については、ファイル システムのアクセス許可を参照してください。

Windows で OpenSSH を使用して WSL をリモートで使用できない

Windows で openssh-server を使用している場合、リモートで WSL にアクセスしようとすると、こちらのエラーが表示されることがあります。

The file cannot be accessed by the system.

これは、Store バージョンの WSL を使用している場合の既知の問題です。 これは現在、WSL 1 を使用するか、Windows 内バージョンの WSL を使用すると回避できます。 詳細については、https://aka.ms/wslstoreinfo を参照してください。

ディストリビューション内で Windows コマンドを実行できない

Microsoft Store で入手できる一部のディストリビューションにはまだ完全な互換性がなく、すぐに Windows コマンドを実行することができません。 powershell.exe /c start . や他の Windows コマンドを実行して、エラー -bash: powershell.exe: command not found が発生した場合は、次の手順に従って解決できます。

  1. WSL ディストリビューション内で echo $PATH を実行します。
    /mnt/c/Windows/system32 が含まれていない場合は、何かによって標準の PATH 変数が再定義されています。
  2. cat /etc/profile を使用してプロファイル設定を確認します。
    PATH 変数の割り当てが含まれている場合は、ファイルを編集し、 # 文字を使って PATH の割り当てブロックをコメントアウトします。
  3. wsl.conf が存在するかどうかをチェックし (cat /etc/wsl.conf)、appendWindowsPath=false が含まれていないことを確認します。含まれていた場合はコメントアウトします。
  4. cmd、PowerShell のどちらかで、wsl -t に続けてディストリビューション名を入力するか、wsl --shutdown を実行して、ディストリビューションを再起動します。

WSL 2 のインストール後に起動できない

WSL 2 をインストールした後に起動できない問題が発生しています。 Microsoft がこれらの問題を完全に診断したところ、バッファー サイズの変更または適切なドライバーのインストールによってこの問題に対処できることがユーザーにより報告されました。 この問題の最新の更新プログラムについては、こちらの GitHub イシューを参照してください。

ICS が無効になっている場合の WSL 2 エラー

インターネット接続共有 (ICS) は、WSL 2 の必須コンポーネントです。 ICS サービスは、WSL 2 が NAT、DNS、DHCP、およびホスト接続共有用に依存する基になる仮想ネットワークを作成するために、ホスト ネットワーク サービス (HNS) によって使用されます。

ICS サービス (SharedAccess) を無効にするか、グループ ポリシーを使用して ICS を無効にすると、WSL HNS ネットワークが作成されません。 これにより、新しい WSL バージョン 2 のイメージを作成するときにエラーが発生し、バージョン 1 のイメージをバージョン 2 に変換しようとするときに次のエラーが発生します。

There are no more endpoints available from the endpoint mapper.

WSL 2 を必要とするシステムにより、ICS サービス (SharedAccess) は既定の開始状態である [手動 (トリガー開始)] のままになり、ICS を無効にするポリシーは上書きされるか、削除されます。 ICS サービスを無効にすると WSL 2 が中断されますが、ICS を無効にすることはお勧めしません。これらの手順を使用して ICS の一部を無効にすることができます

従来のバージョンの Windows および WSL の使用

Windows 10 Creators Update (2017 年 10 月、ビルド 16299) や Anniversary Update (2016 年 8 月、ビルド 14393) など、従来のバージョンの Windows および WSL を実行している場合は、注意すべき違いがいくつかあります。 最新の Windows バージョンに更新することをお勧めしますが、それができない場合は、いくつかの相違点について以下で説明します。

相互運用性コマンドの相違点:

  • bash.exewsl.exe に置き換えられました。 Linux コマンドは Windows コマンド プロンプトまたは PowerShell から実行できますが、初期の Windows バージョンでは bash コマンドの使用が必要になる場合があります。 (例: C:\temp> bash -c "ls -la")。 bash -c に渡される WSL コマンドは、変更なしで WSL プロセスに転送されます。 ファイル パスは WSL 形式で指定する必要があり、関連文字をエスケープするように注意する必要があります。 たとえば、C:\temp> bash -c "ls -la /proc/cpuinfo"C:\temp> bash -c "ls -la \"/mnt/c/Program Files\"" などです。
  • 特定のディストリビューションで使用できるコマンドを確認するには、[distro.exe] /? を実行します。 たとえば、Ubuntu の場合は C:\> ubuntu.exe /? です。
  • Windows パスは WSL $PATH に含まれています。
  • 以前のバージョンの Windows 10 の WSL ディストリビューションから Windows ツールを呼び出す場合は、ディレクトリ パスを指定する必要があります。 たとえば、WSL コマンド ラインから Windows のメモ帳アプリを呼び出す場合は、/mnt/c/Windows/System32/notepad.exe を入力します。
  • 既定のユーザーを root に変更するには、PowerShell で次のコマンド: C:\> lxrun /setdefaultuser root を使用してから、Bash.exe を実行してログインします: C:\> bash.exe。 ディストリビューションのパスワード コマンド: $ passwd username を使用してパスワードをリセットしてから、Linux コマンド ラインを閉じます: $ exit。 Windows コマンド プロンプトまたは Powershell から、既定のユーザーを通常の Linux ユーザー アカウントにリセットします: C:\> lxrun.exe /setdefaultuser username

WSL のレガシ バージョンをアンインストールする

Creators Update (2017 年 10 月、ビルド 16299) より前のバージョンの Windows 10 に WSL を最初にインストールした場合は、必要なファイルやデータなどを、インストールした古い Linux ディストリビューションから、Microsoft Store を介してインストールした新しいディストリビューションに移行することをお勧めします。 コンピューターからレガシ ディストリビューションを削除するには、コマンド ラインまたは PowerShell インスタンスから次を実行します: wsl --unregister Legacy。 あるいは、Windows エクスプローラーまたは PowerShell を使用して %localappdata%\lxss\ フォルダー (とそのすべてのサブコンテンツ) を削除することで、古いレガシ ディストリビューションを手動で削除することもできます: rm -Recurse $env:localappdata/lxss/