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

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

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

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

既存のイシューを検索して、自分の問題に関連するものがあるかどうかを確認します。

検索バーでは、"state:open" を削除して、既に解決済みの問題を検索に含めることができます。

優先して進めて欲しいと思う未解決のイシューには、コメントを付けたり賛成したりすることをご検討ください。
新しいイシューを報告します。 WSL に問題が見つかり、既存の問題が見つからない場合は、緑色の [New issue] ボタンを選択し、[WSL - Bug Report] を選択します。

次の情報を入力する必要があります。
- 問題のタイトル
- Windows バージョン: cmd.exe /c ver 実行して、使用している Windows のビルドを取得してください。
- WSL バージョン: Microsoft Store から Linux 用 Windows サブシステムを実行している場合は、 wsl.exe -v実行してください。
- WSL 1 または WSL 2 を使用していますか: 問題が WSL 2 と WSL 1 のどちらにあるかを教えてください。 wsl.exe -l -vを実行してわかります。
- カーネルバージョン: 使用している Linux カーネルのバージョン、またはカスタムカーネルを使用している場合は、お知らせください。そのコマンドを使用できる場合は、 wsl.exe --status を実行するか、ディストリビューションで cat /proc/version を実行します。
- ディストリビューションのバージョン: 使用しているディストリビューションを教えてください (該当する場合)。可能な限りバージョンに関する追加情報を取得できます (例: Debian/Ubuntu、 run lsb_release -r)。
- その他のソフトウェア: WSL の他のアプリケーションとの対話に関するバグを報告している場合は、お知らせください。どのようなアプリケーションですか? どのバージョンですか?
- 再現手順: バグを再現する手順を一覧表示してください。
- 期待される動作: 何が表示される予定でしたか? 関連する例やドキュメントリンクを含めます。
- 実際の動作:代わりに何が起こりましたか?
- 診断ログ: 必要に応じて、追加の診断を提供してください。フィードバックハブのログ、ネットワークログなどを収集する方法については、ガイダンスを参照してください。
詳細については、WSL への投稿に関するページを参照してください。
緑色の [] ボタンを選択し、[New issue] を選択してFeature requestします。

あなたの要求を説明するために、いくつかの質問に答える必要があります。

次のこともできます。

WSL ドキュメントのリポジトリを使用してドキュメントのイシューを報告します。 WSL ドキュメントに投稿するには、Microsoft Docs 共同作成者ガイドを参照してください。
問題が Windows ターミナル、Windows コンソール、またはコマンドライン UI とより密接に関連している場合は、Windows ターミナルの製品リポジトリを使用して Windows ターミナルのイシューを報告してください。

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

エラー 0x80070003 が発生してインストールに失敗しました
- Windows Subsystem for Linux はシステムドライブ (通常、これは C: ドライブ) でのみ実行されます。ディストリビューションがシステムドライブに格納されていることを確認します。
- Windows 10 の場合は [設定] ->[システム] ->[ストレージ] ->[その他のストレージ設定: 新しいコンテンツの保存先を変更する] を開きます。
- Windows 11 の場合は [設定] ->[システム] ->[ストレージ] ->[ストレージの詳細設定] ->[新しいコンテンツの保存先] を開きます。
WslRegisterDistribution failed with error 0x8007019e (エラー0x8007019e で WslRegisterDistribution が失敗しました)
- Windows Subsystem for Linux オプションコンポーネントが有効になっていません。
- コントロールパネルを開く ->プログラムと機能 ->Windows 機能をオンまたはオフにする ->Windows Subsystem for Linux を確認するか、手順 1 で説明した 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 を実行できません。
アップグレード中にエラーが発生しました。コマンドラインオプションが無効です。 wsl --set-version Ubuntu 2
- Linux 用 Windows サブシステムが有効になっていることと、Windows ビルドバージョン 18362 以降を使用していることを確認してください。 WSL を有効にするには、管理者特権を使用して PowerShell プロンプトで次のコマンドを実行します。
```
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
```
仮想ディスクシステムの制限があるため、要求された操作を完了できませんでした。仮想ハードディスクファイルは、圧縮と暗号化が解除されている必要があります。また、スパースにすることはできません。
- Linux ディストリビューションのプロファイルフォルダーを開いて、[コンテンツの圧縮] (チェックされている場合は [コンテンツの暗号化] を選択) の選択を解除します。これは、Windows ファイルシステムのフォルダーにあります (例: %LocalAppData%\Packages\CanonicalGroupLimited...)。
- この Linux ディストリビューションプロファイル内に、LocalState フォルダーが存在します。このフォルダーを右クリックして、オプションのメニューを表示します。 [プロパティ>Advanced] を選択し、[ディスク領域を節約するためにコンテンツを圧縮する] チェックボックスと [データをセキュリティで保護するためにコンテンツを暗号化する] チェックボックスがオフになっていることを確認します (オンではありません)。現在のフォルダーのみに適用するか、すべてのサブフォルダーとファイルに適用するかを確認するメッセージが表示された場合は、圧縮フラグのみをクリアするため、[このフォルダーのみ] を選択します。この操作を実行すると、wsl --set-version コマンドが機能するようになります。
注

私の場合、Ubuntu 18.04 ディストリビューションの LocalState フォルダーは C:\Users\<my-user-name>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc

この問題の最新情報が追跡されている WSL ドキュメント GitHub スレッド #4103 をご確認ください。
"wsl" という用語が、コマンドレット、関数、スクリプトファイル、または操作可能なプログラムの名前として認識されません。
- Linux 用 Windows サブシステムのオプションコンポーネントがインストールされていることを確認してください。また、ARM64 デバイスを使用し、PowerShell からこのコマンドを実行している場合も、このエラーを受け取ります。代わりに、wsl.exePowerShell Core またはコマンドプロンプトからを実行します。
エラー: Linux 用 Windows サブシステムにインストールされたディストリビューションがありません。
- WSL ディストリビューションをインストールした後に、このエラーが表示された場合:
1. コマンドラインから呼び出す前に、ディストリビューションを少なくとも 1 回実行します。
2. 別のユーザーアカウントを実行している可能性があるかどうかを確認します。管理者アクセス許可で (管理者モードで) プライマリユーザーアカウントを実行するとこのエラーは発生しませんが、Windows に付属する組み込みの Administrator アカウントを誤って実行していないか確認する必要があります。これは別のユーザーアカウントであり、インストールされている WSL ディストリビューションは設計上表示されません。詳細については、「ビルトイン Administrator アカウントの有効化と無効化」を参照してください。
3. WSL 実行可能ファイルは、ネイティブのシステムディレクトリにのみインストールされます。 64 ビットの Windows 上 (または ARM64 上など、ネイティブではない組み合わせ) で 32 ビットのプロセスを実行すると、ホストされているネイティブではないプロセスでは、実際には別の System32 フォルダーが認識されます (x64 Windows で 32 ビットプロセスで確認されるプロセスは、%SystemRoot%\SysWOW64 のディスクに格納されます)。ホストされたプロセスから "ネイティブ" system32 にアクセスするには、仮想フォルダー ( \Windows\sysnative) を参照します。これは実際にはディスク上に存在しませんが、ファイルシステムパスリゾルバーによって見つかります。
Error:この更新プログラムは、Linux 用 Windows サブシステムを搭載したマシンにのみ適用されます。
- Linux カーネル更新プログラム MSI パッケージをインストールするには、WSL が必要であり、最初に有効にする必要があります。失敗した場合は、次のメッセージが表示されます。この更新プログラムは、Linux 用 Windows サブシステムを持つマシンにのみ適用されます。
- このメッセージが表示される理由として、次の 3 つが考えられます。
1. WSL 2 をサポートしていない古いバージョンの Windows を使用しています。「手順 2 - WSL 2 を実行するための要件を確認する」を参照してください。
2. WSL が有効になっていません。手順 1 に戻り、オプションの WSL 機能がコンピューターで有効になっていることを確認する必要があります。
3. WSL を有効にした後、再起動しないと、効力が発しません。マシンを再起動してから、もう一度お試しください。
エラー: WSL 2 のカーネルコンポーネントを更新する必要があります。詳細については、手順 4 を参照してください
- %SystemRoot%\system32\lxss\tools フォルダーに Linux カーネルパッケージがない場合は、このエラーが発生します。この問題を解決するには、次のインストール手順の手順 4 で Linux カーネル更新 MSI パッケージをインストールします。場合によっては、[プログラムの追加と削除] から MSI をアンインストールし、もう一度インストールする必要があります。

一般的な問題

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

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

[更新プログラムの確認] をクリックしても更新プログラムを受け取らない場合は、 KB KB4566116を手動でインストールできます。

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

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

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

0x1bcの実際のエラーは、WSL 2 のカーネルコンポーネントの更新が必要です。詳細はこちらをご覧ください。 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

この問題の詳細については、問題 #5307 を参照してください。

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

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

PS C:\> wsl.exe
WSL 2

この問題を解決するには、手順 4 を参照し、そのドキュメントページの指示に従ってカーネルを手動でインストールしてください。

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 で仮想化が有効になっていることを確認してください。

Hyper-V のシステム要件を確認
マシンが VM の場合は、入れ子になった仮想化を手動で有効にしてください。 powershell を管理者権限で起動し、以下のコマンドを実行します。その際、<VMName> はホストシステム上の仮想マシンの名前（Hyper-V マネージャーで見つけることができます）で置き換えてください。
```
Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
```
仮想化を有効にする方法については、お使いの PC の製造元のガイドラインに従ってください。一般に、これらの機能が CPU で確実に有効になるようにするには、システム BIOS の使用が必要になる場合があります。このプロセスの手順は、コンピューターによって異なる場合があります。 Windows での仮想化の有効化に関する記事を参照してください。
仮想マシンプラットフォームのオプションコンポーネントを有効にした後、マシンを再起動します。
ブート構成でハイパーバイザーの起動が有効になっていることを確認してください。これを検証する場合は、管理者特権の PowerShell を実行します。
```
bcdedit /enum | findstr -i hypervisorlaunchtype
```
hypervisorlaunchtype Off が表示された場合、ハイパーバイザーは無効になっています。これを有効にするには、管理者特権の PowerShell で以下を実行します。
```
bcdedit /set hypervisorlaunchtype Auto
```
また、サードパーティ製ハイパーバイザーをインストールしている場合 (VMware や VirtualBox など) は、それらが HyperV をサポートできる最新バージョン (VMware 15.5.5+ および VirtualBox 6+) であるか、オフになっていることを確認してください。
Azure 仮想マシンでこのエラーが発生した場合は、トラステッド起動が無効になっていることを確認します。入れ子になった仮想化は、トラステッド起動を使用する Azure 仮想マシンではサポートされません。

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

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

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

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

Windows ファイアウォール設定のスクリーンショット

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

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

IPv6 を無効にしたときに WSL にネットワーク接続がない

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters (REG_DWORD) DisabledComponentsレジストリ値を使用して IPv6 を無効にすると、WSL ネットワーク接続が失敗する可能性があります。上級ユーザー向けに Windows で IPv6 を構成するためのガイダンスを参照してください。

ホストシステムで IPv6 を無効にする必要がある場合は、PowerShell を使用して IPv6 プロトコルバインドを直接削除することをお勧めします。 (例: Disable-NetAdapterBinding -Name "<MyAdapter>" -ComponentID ms_tcpip[6])。

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

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

VPN の DNS サーバーを書き留めます。
```
ipconfig.exe /all
```
既存の resolv.confのコピーを作成します。
```
sudo cp /etc/resolv.conf /etc/resolv.conf.bak
```
現在の resolv.confのリンクを解除します。
```
sudo unlink /etc/resolv.conf
```

走れ

sudo mv /etc/resolv.conf.bak /etc/resolv.conf

/etc/wsl.conf を編集し、このコンテンツをファイルに追加します。 (この設定の詳細については、「詳細設定の構成」を参照してください)
```
[network]
generateResolvConf=false
```
/etc/resolv.confを開き、
1. 自動生成を記述するコメントがあるファイルから最初の行を削除します。
2. DNS サーバーの一覧の最初のエントリとして、上記 (1) の DNS エントリを追加します。
3. ファイルを閉じます。

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

sudo mv /etc/resolv.conf /etc/resolv.conf.bak
sudo ln -s /run/resolvconf/resolv.conf /etc/resolv.conf

WSL に関するグローバルセキュアアクセスクライアントの問題

グローバルセキュアアクセスクライアント (/entra/global-secure-access/how-to-install-windows-client) は、名前を解決するときに一時アドレスを返す機能があるため、WSL 接続に影響する可能性があります。その後、ネットワーク接続が確立されると、アドレスが実際のアドレスにスワップされます。これは、WSL トラフィックが GSA クライアントフックの大部分を下回って転送されるため、WSL を中断する可能性があります。

DNS トンネリング (dnsTunneling=false) を無効にするか、ミラーリングモード (networkingMode=nat) を無効にすることをお勧めします。

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

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

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

ミラー化ネットワークモードは、現在、WSL 構成の実験的設定です。 WSL の従来の NAT ネットワークアーキテクチャは、"ミラー化されたネットワークモード" と呼ばれるまったく新しいネットワークモードに更新できます。実験的な networkingMode が mirroredに設定されている場合、互換性を向上させるために、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 プロキシミラーリングは、autoProxyの設定を使用して構成できます。この設定を適用する場合は、これらの考慮事項に注意してください。

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

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

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

ZScaler 構成によって発生する既知の問題があります。この場合、ZScaler は Windows プロキシ構成の有効化と無効化を繰り返し、WSL に "ホストで Http プロキシの変更が検出されました" という通知が繰り返し表示されます。

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

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

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

DNS トンネリングは、dnsTunnelingの設定を使用して構成できます。この設定を適用する場合は、これらの考慮事項に注意してください。

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 Desktop によって管理される Docker コンテナーからの DNS クエリは、DNS トンネリングをバイパスします。 Docker Desktop には、ホスト DNS 設定とポリシーを Docker コンテナーからの DNS クエリに適用する独自の方法 (DNS トンネリングとは異なる) があります。
DNS トンネリングを正常に有効にするには、wsl.conf ファイルで generateResolvConf オプションを無効にしないでください。
DNS トンネリングが有効になっている場合、wsl.conf ファイルの generateHosts オプションは無視されます (Windows DNS ホストファイルは Linux /etc/hosts ファイルにコピーされません)。 Windows ホストファイル内のポリシーは、Linux でそのファイルをコピーする必要なく、Linux からの DNS クエリに適用されます。

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

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

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

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

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

設定の名前	価値
`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)
アドレス生成モード	無効 (0)
disable_ipv6（IPv6無効化）	無効 (0)
`https://sysctl-explorer.net/net/ipv4/arp_filter/`	有効 (1)

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

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

ネットワークマネージャーの実行中に Docker コンテナーの問題が発生する

ネットワークマネージャーサービスが実行されている Docker コンテナーには既知の問題があります。ホストへのループバック接続を試行するときのエラーといった現象があります。 WSL ネットワークが正しく構成されるようにするには、ネットワークマネージャーサービスを停止することをお勧めします。

sudo systemctl disable network-manager.service

WSL の .local 名を解決する

従来の DNS サーバーを必要とせずにローカルネットワーク内でホスト名を IP アドレスに解決するには、.local 名がよく使用されます。これは、マルチキャストトラフィックを利用して機能する mDNS (マルチキャスト DNS) プロトコルによって実現されます。

networkingMode NATに設定します。

現在、DNS トンネリングが有効な場合、この機能はサポートされていません。 .local 名の解決を有効にするには、次の解決策をお勧めします。

DNS トンネリングを無効にします。
ミラー化ネットワークモードを使用します。

networkingMode Mirroredに設定します。

注: 以下の機能を使用するには、WSL ビルド 2.3.17 以降を使用する必要があります。

ミラー化モードはマルチキャストトラフィックをサポートしているため、mDNS (マルチキャスト DNS) プロトコルを使用して .local 名を解決できます。 Linux は既定では mDNS をサポートしないため、サポートするように構成する必要があります。構成する方法の 1 つは、次の 2 つの手順を使用することです。

libnss-mdns パッケージをインストールする
```
sudo apt-get install libnss-mdns
```
* libnss-mdns パッケージは、GNU C ライブラリ (glibc) の GNU Name Service Switch (NSS) 機能のプラグインであり、マルチキャスト DNS (mDNS) を介してホスト名解決を提供します。このパッケージにより、一般的な Unix/Linux プログラムがアドホック mDNS ドメイン .local 内の名前を効果的に解決できるようになります。

/etc/nsswitch.conf ファイルを構成して、mdns_minimal セクションのhosts設定を有効にします。ファイルの内容の例:

/>cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat systemd
group:          compat systemd
shadow:         compat
gshadow:        files

hosts:          files mdns_minimal [NOTFOUND=return] dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

WSL の DNS サフィックス

.wslconfig ファイルの設定に応じて、WSL はDNSサフィックスに関して以下の動作を行います。

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

ケース 1: 既定では、Linux で DNS サフィックスが構成されていない

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

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

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

ケース 3: DNS トンネリングが無効で、SharedAccess DNS プロキシが無効になっている場合 (dnsTunneling 、 dnsProxy は .wslconfig で false に設定されています)。 Linux では、/etc/resolv.conf の "domain" 設定で 1 つの DNS サフィックスが構成されます

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

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

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

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

すべての Windows DNS サフィックスは、/etc/resolv.conf の search 設定で Linux で構成されます

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

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

注

補足 DNS サフィックスは、Windows で次を使用して構成できます。

setInterfaceDnsSettings 関数 (netioapi.h)、DNS_SETTING_SUPPLEMENTAL_SEARCH_LISTパラメーターにフラグ Settingsが設定されています。

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 からの名前解決を中断する可能性がある既知の構成がいくつか存在します。

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 は、HNS と同様に、ローカルで定義されたファイアウォール規則が適用または使用されないことを意味します。
また、Enterprise では、すべての受信規則をブロックするグループポリシーと 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/シールド済み

以下を実行して、受信ファイアウォール規則を許可しないように構成されているかどうかを確認できます (ファイアウォールプロファイルに関する上記の注意事項を参照)。これは、PowerShell で返される最初のファイアウォールプロファイルのスニペットにすぎません。
```
PS C:\> Get-NetFirewallProfile -PolicyStore ActiveStore
Name                  : Domain
Enabled               : True
DefaultInboundAction  : Block
DefaultOutboundAction : Allow
AllowInboundRules     : False
...
```
AllowInboundRules: False は、受信ファイアウォール規則が適用されていないことを意味します。
ユーザーが Windows セキュリティ設定アプリを通過し、"許可されているアプリの一覧に含まれるすべての受信接続をブロックする" コントロールをチェックします。

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

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

NAT DNS プロキシ構成を WSL から機能させるには、このチェックを外しておく必要があります。 または WSL が DNS トンネリングを使用するように設定しておくこともできます。
共有アクセスへの 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 インターフェイスを正しくターゲットします。

Windows でのネットワークアクセスに関する問題のトラブルシューティング

ネットワークにアクセスできない場合は、構成の誤りが原因であると考えられます。 FSE ドライバーが実行されているかどうかを確認してください。

Get-Service FSE

実行中の FSE が表示されない場合は、 PortTrackerEnabledMode レジストリ値がこのレジストリキーの下で終了するかどうかを確認してください。

Get-ItemProperty HKLM:\System\CurrentControlSet\Services\Tcpip\Parameters

FSE が実行またはインストールされておらず、 PortTrackerEnabledMode が存在する場合は、そのレジストリ値を削除して再起動してください

ファントムアダプターを削除する手動の方法

"ゴーストアダプター"、またはファントムプラグアンドプレイ (PnP) デバイスとは、システムに表示されるが物理的に接続されていないハードウェアコンポーネントを指します。これらの"ゴースト"デバイスは、システム設定で混乱や混乱を引き起こす可能性があります。仮想マシン (VM) で WSL を実行しているときにゴーストアダプターが表示される場合は、以下の手動の手順に従ってそのようなファントム PnP デバイスを見つけ、削除してください。 Microsoft では、手動の介入を必要としない自動化されたソリューションに取り組んでいます。詳細については近日公開予定です。

デバイスマネージャーを開きます
[表示] > [隠されたデバイスを表示]
[ネットワークアダプター] を開きます
ゴーストのネットワークアダプターを右クリックし、[デバイスのアンインストール] を選びます

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

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

WSL の更新

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

Linux 用 Windows サブシステム自体を更新するには、次のコマンドを使用してください。
```
wsl.exe --update
```
特定の Linux ディストリビューションユーザーバイナリを更新するには、更新する Linux ディストリビューションで次のコマンドを使用してください。
```
apt-get update | apt-get upgrade
```

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

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

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

次の内容を /usr/sbin/policy-rc.d に記述して、変更を保存します。
```
#!/bin/sh
exit 101
```
実行のアクセス許可を /usr/sbin/policy-rc.d に追加します。
```
chmod +x /usr/sbin/policy-rc.d
```

次のコマンドを実行します。

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

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

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

cmd.exe を開きます。
タイトルバーを右クリックして、[プロパティ] を選択し、[従来のコンソールを使う] をオフにします
[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 システムの復元後のインストールの問題

%SystemRoot%\System32\Tasks\Microsoft\Windows\Windows Subsystem for Linux フォルダーを削除します。

Warnung

オプション機能が完全にインストールされ、動作している場合は、この操作を行わないでください。
WSL オプション機能を有効にします (まだ有効にされていない場合)
再起動します
lxrun /uninstall /full
Bash をインストールします

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

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

カスペルスキー
平均
アバスト
Symantec Endpoint Protection

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

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

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

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

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

Bash がハングしている

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

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

メモリダンプの種類を "完全なメモリダンプ" に変更します。ダンプの種類を変更するときに、現在の種類をメモしておきます。
こちらの手順を使用して、キーボードコントロールを使ってクラッシュを構成します。
ハングまたはデッドロックを再現します。
(2) のキーシーケンスを使用してシステムをクラッシュさせます。
システムはクラッシュし、メモリダンプを収集します。
システムが再起動したら、 memory.dmp を secure@microsoft.comに報告します。ダンプファイルの既定の場所は%SystemRoot%\memory.dmpか、システムドライブC:\Windows\memory.dmp場合はC:。メールには、ダンプは WSL or Bash on Windows チーム向けであることを記載します。
メモリダンプの種類を元の設定に戻します。

ビルド番号を確認する

PC のアーキテクチャと Windows ビルド番号を確認するには、[>> を開きます。

[OS ビルド] フィールドと [システムの種類] フィールドを探します。ビルドとシステムの種類のフィールドのスクリーンショット

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 によって接続は閉じられました)。

OpenSSH サーバーが実行されていることを確認します。
```
sudo service ssh status
```
そして、このチュートリアルに従ったことを確認してください。 https://ubuntu.com/server/docs/service-openssh
sshd サービスを停止し、デバッグモードで sshd を開始します。
```
sudo service ssh stop
sudo /usr/sbin/sshd -d
```

スタートアップログを調べて、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 にリモートでアクセスしようとすると、多くの場合、次のエラーが表示されます。このファイルはシステムからアクセスできません。

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

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

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

WSL ディストリビューション内で echo $PATH を実行します。 /mnt/c/Windows/system32 が含まれていない場合は、何かによって標準の PATH 変数が再定義されています。
cat /etc/profile を使用してプロファイル設定を確認します。 PATH 変数の割り当てが含まれている場合は、ファイルを編集し、 # 文字を使って PATH の割り当てブロックをコメントアウトします。
wsl.conf が存在するかどうかをチェックし (cat /etc/wsl.conf)、appendWindowsPath=false が含まれていないことを確認します。含まれていた場合はコメントアウトします。
ディストリビューション名 wsl -t <Distro> 入力するか、PowerShell で 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 に変換しようとすると、次のエラーが発生します。エンドポイントマッパーから使用できるエンドポイントがこれ以上ありません。

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.exe は wsl.exe に置き換えられました。 Linux コマンドは 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\ フォルダー (とそのすべてのサブコンテンツ) を削除することで、古いレガシディストリビューションを手動で削除することもできます: Remove-Item -Recurse $env:localappdata/lxss/。

予期しないエラー 0x8000FFFFエラーコード

通常、このエラーコードは、WSL で Linux ディストリビューション (Ubuntu など) をインストールまたは使用しようとしたときに、システム操作中に予期しないエラー ("致命的") が発生したことを意味します。このエラーの原因には、多くの理由があります。まず、次のチェックを行います。

これはアクセス許可の問題ですか? コマンドラインで想定されるユーザーとしてログインしていることを確認し、WSL を使用して Linux ディストリビューションをインストールするときに必要な管理者特権を持っていることを確認します。 (ターミナルまたはコマンドラインのタスクバーアイコンを右クリックして、[管理者として実行] を選択します)。
WSL を最新バージョンに更新しましたか? wsl --updateコマンドを使用して、最新バージョンに更新します。最新バージョンの Windows に更新することもできます。
wsl --install コマンドを正しく使用し、インストールする Linux ディストリビューションを指定していることを確認します。
コマンドを使用して、WSL をシャットダウンして再起動してみてください: wsl --shutdown。
Windows Server を使用している場合は、バージョンが最新であることを確認し、 Windows Server インストールガイドに従ってください。
管理者特権のコマンドプロンプト (管理者として実行) から、システムファイルが見つからないか破損していると思われる場合は、システムファイルをスキャンして修復したり、Windows オペレーティングシステムイメージを修復したりできます。破損または不足している Windows システムファイルをスキャンして修復するには、次のコマンドを使用します: SFC /SCANNOW。 Windows イメージ自体を修復するには、次のコマンドを使用します: DISM /Online /Cleanup-Image /RestoreHealth。
関連する WSL 製品リポジトリの問題 9420 を参照してください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-10-03