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

[アーティクル]
08/08/2024

以下では 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](機能要求) を選択します。いくつかの問題に対処して、要求を説明する必要があります。

次のこともできます。

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 の機能の有効化または無効化] を開いて、[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 コマンドが機能するようになります。

WSL ディストリビューションのプロパティ設定のスクリーンショット

注意

この例では、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 ビットプロセスが認識するものは、ディスクの \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 で仮想化が有効になっていることを確認してください。

Hyper-V のシステム要件を確認
マシンが VM の場合は、入れ子になった仮想化を手動で有効にしてください。 powershell を管理者権限で起動し、以下のコマンドを実行します。その際、<VMName> はホストシステム上の仮想マシンの名前（Hyper-V マネージャーで見つけることができます）で置き換えてください。
```
Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
```
仮想化を有効にする方法については、お使いの PC の製造元のガイドラインに従ってください。一般に、これらの機能が CPU で確実に有効になるようにするには、システム BIOS の使用が必要になる場合があります。このプロセスの手順は、マシンによって異なる場合があります。一例として、Bleeping Computer によるこの記事を参照してください。
Virtual Machine Platform のオプションのコンポーネントを有効にしたら、コンピューターを再起動してください。
ブート構成でハイパーバイザーの起動が有効になっていることを確認してください。これを検証するには、以下を実行します (管理者特権の 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 ファイアウォールの構成」を参照してください。

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

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

ipconfig.exe /all を実行して、VPN の DNS サーバーをメモします
sudo cp /etc/resolv.conf /etc/resolv.conf.new で、既存の resolv.conf のコピーを作成します
sudo unlink /etc/resolv.conf で、現在の resolv.conf のリンクを解除します
sudo mv /etc/resolv.conf.new /etc/resolv.conf
/etc/wsl.conf を編集し、このコンテンツをファイルに追加します。 (この設定の詳細については、「詳細設定の構成」を参照してください)

[network]
generateResolvConf=false

/etc/resolv.conf を開きます。そして、
a. 自動生成を記述するコメントがあるファイルから最初の行を削除します。
b. DNS サーバーの一覧の最初のエントリとして、上記 (1) の DNS エントリを追加します。
c. ファイを閉じます。

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

cd /etc
sudo mv resolv.conf resolv.conf.new
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 ネットワークアーキテクチャは、''ミラー化ネットワークモード'' と呼ばれるまったく新しいネットワークモードに更新できます。実験的な 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 プロキシミラーリングは、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_PROXY と http_proxy などです。

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

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

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

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

DNS トンネリングは、WSL 構成ファイルの実験的セクションの 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 によって構成される設定のリストを以下に示します。

設定名	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 設定で、公開ポート番号を一覧表示します。

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

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

sudo systemctl disable network-manager.service

WSL の .local 名を解決する

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

NAT に設定された networkingMode:

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

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

ミラー化に設定された networkingMode:

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

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

"libnss-mdns" パッケージをインストールします

sudo apt-get install libnss-mdns

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

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

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 は以下のビヘイビアー 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 が Mirrored に設定されている場合:

すべての 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 インターフェイスを正しくターゲットします。

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

ネットワークにアクセスできない場合は、構成の誤りが原因であると考えられます。 FSE ドライバーが実行されているかどうかを確認してください: ‘sc queryex FSE’。 FSE が実行中でないことが分かった場合は、次のレジストリキーの下に PortTrackerEnabledMode レジストリ値が存在するかどうかを確認してください: reg query HKLM\System\CurrentControlSet\Services\Tcpip\Parameters。 FSE が実行またはインストールされていなくて、PortTrackerEnabledMode が存在する場合は、そのレジストリ値を削除して再起動してください

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

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

デバイスマネージャーを開きます
[表示] > [非表示のデバイスの表示]

デバイスマネージャーの [非表示のデバイスの表示] メニューのスクリーンショット

[ネットワークアダプター] を開きます

ネットワークアダプターの一覧のスクリーンショット

ゴーストのネットワークアダプターを右クリックし、[デバイスのアンインストール] を選びます

ネットワークの一覧からファントム PnP を右クリックし、[デバイスのアンインストール] を選択しているスクリーンショット

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

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

WSL の更新

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

Linux 用 Windows サブシステム自体を更新するには、PowerShell または CMD でコマンド wsl --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 システムの復元後のインストールの問題

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

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

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

Kaspersky
AVG
Avast
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 が問題を診断できるようにメモリダンプを収集して報告してください。次の手順によりシステムがクラッシュすることに注意してください。それが問題である場合は、この操作を行わないでください。または、これを行う前に作業を保存してください。

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

メモリダンプの種類を "完全なメモリダンプ" に変更します。ダンプの種類を変更するときに、現在の種類をメモしておきます。
こちらの手順を使用して、キーボードコントロールを使ってクラッシュを構成します。
ハングまたはデッドロックを再現します。
(2) のキーシーケンスを使用してシステムをクラッシュさせます。
システムはクラッシュし、メモリダンプを収集します。
システムが再起動したら、memory.dmp を secure@microsoft.com に報告します。ダンプファイルの既定の場所は、%SystemRoot%\memory.dmp です。つまり、C: がシステムドライブである場合は、C:\Windows\memory.dmp になります。メールには、ダンプは 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 にアクセスしようとすると、こちらのエラーが表示されることがあります。

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 が発生した場合は、次の手順に従って解決できます。

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

次の方法で共有