Linux용 Windows 하위 시스템 문제 해결

아티클
08/08/2024

아래에 WSL과 관련된 몇 가지 일반적인 문제 해결 시나리오가 나와 있지만, GitHub의 WSL 제품 리포지토리에 제출된 문제도 검색해 보는 것이 좋습니다.

문제, 버그 보고서, 기능 요청 제출

WSL 제품 리포지토리 문제를 통해 다음을 수행할 수 있습니다.

기존 문제를 검색하여 현재 발생하는 문제와 관련된 문제가 있는지 확인합니다. 검색 창에서 "is:open"을 제거하여 이미 해결된 문제를 검색에 포함할 수 있습니다. 미해결 문제 중에서 우선적으로 해결되기를 원하는 관심을 표시하려는 문제에 주석을 달거나 좋아요를 눌러 주시기 바랍니다.
새 문제를 제출합니다. WSL에서 문제를 발견했는데 기존 문제가 아닌 것으로 보이는 경우 녹색 새 문제 단추를 선택한 다음, WSL - 버그 보고서를 선택하면 됩니다. 문제의 제목, Windows 빌드 번호(현재 빌드 번호를 보려면 cmd.exe /c ver 실행), WSL 1 또는 2 중에 현재 실행하고 있는 버전, 현재 Linux 커널 버전 번호(wsl.exe --status 또는 cat /proc/version 실행), 배포판의 버전 번호(lsb_release -r 실행), 관련된 기타 소프트웨어 버전, 재현 단계, 예상 동작, 실제 동작 및 진단 로그(사용 가능하고 적절한 경우)를 포함해야 합니다. 자세한 내용은 WSL에 기여를 참조하세요.
녹색 새 문제 단추를 선택하고 기능 요청을 선택하여 기능 요청을 제출합니다. 요청을 설명하는 몇 가지 질문에 답해야 합니다.

다음도 가능합니다.

WSL 문서 리포지토리를 사용하여 설명서 문제를 제출합니다. WSL 문서에 기여하려면 Microsoft Docs 기여자 가이드를 참조하세요.
문제가 Windows 터미널, Windows 콘솔 또는 명령줄 UI와 더 관련이 있는 경우 Windows 터미널 제품 리포지토리를 사용하여 Windows 터미널 문제를 제출합니다.

설치 문제

0x80070003 오류로 인한 설치 실패
- Linux용 Windows 하위 시스템은 시스템 드라이브(일반적으로 C: 드라이브)에서만 실행됩니다. 배포가 시스템 드라이브에 저장되어 있는지 확인합니다.
- Windows 10에서 설정 ->시스템 ->스토리지 ->더 많은 스토리지 설정: 새 콘텐츠가 저장되는 위치 변경 열기
- Windows 11에서 설정 ->시스템 ->스토리지 ->고급 스토리지 설정 ->새 콘텐츠가 저장되는 위치 열기
0x8007019e 오류로 인한 WslRegisterDistribution 실패
- 선택적인 Linux용 Windows 하위 시스템 구성 요소가 실행되지 않습니다.
- 제어판 ->프로그램 및 기능 ->Windows 기능 사용/사용 안 함 ->을 열어 Linux용 Windows 하위 시스템을 선택하거나 이 문서의 시작 부분에서 설명한 PowerShell cmdlet을 사용합니다.
0x80070003 오류 또는 0x80370102 오류로 인해 설치하지 못했습니다.
- 컴퓨터 BIOS 내에서 가상화를 사용하도록 설정했는지 확인합니다. 이 방법에 대한 지침은 컴퓨터마다 다르며, CPU 관련 옵션에 있을 가능성이 높습니다.
- WSL2를 사용하려면 CPU가 Intel Nehalem 프로세서(Intel Core 1세대) 및 AMD Opteron에 도입된 SLAT(두 번째 수준 주소 변환) 기능을 지원해야 합니다. 이전 CPU(예: Intel Core 2 Duo)는 Virtual Machine 플랫폼을 성공적으로 설치하더라도 WSL2를 실행할 수 없습니다.
업그레이드 시도 중 오류: Invalid command line option: wsl --set-version Ubuntu 2
- Linux용 Windows 하위 시스템을 사용하도록 설정했고 Windows 빌드 버전 18362 이상을 사용하고 있는지 확인합니다. WSL을 실행하도록 하려면 관리자 권한(Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux)으로 PowerShell 프롬프트에서 이 명령을 실행합니다.
가상 디스크 시스템 제한으로 인해 요청한 작업을 완료할 수 없습니다. 가상 하드 디스크 파일은 압축이 풀려 있는 상태이고 암호화되지 않아야 하며 스파스가 아니어야 합니다.
- 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 Docs GitHub 스레드 #4103을 확인하세요.

cmdlet, 함수, 스크립트 파일 또는 실행 프로그램의 이름에는 'wsl'이라는 단어가 들어갈 수 없습니다.
- Linux용 Windows 하위 시스템 옵션 구성 요소가 설치되었는지 확인하세요. 또는 ARM64 디바이스를 사용 중이고 PowerShell에서 이 명령을 실행하는 경우 이 오류가 표시됩니다. PowerShell Core 또는 명령 프롬프트에서 wsl.exe를 대신 실행하세요.
오류: Linux용 Windows 하위 시스템에 설치된 배포가 없습니다.
- WSL 배포를 이미 설치한 후 이 오류가 표시되는 경우 다음을 수행합니다.
1. 명령줄에서 호출하기 전에 배포를 한 번 이상 실행합니다.
2. 별도의 사용자 계정을 실행할 수 있는지 여부를 확인합니다. 상승된 권한(관리 모드)으로 기본 사용자 계정을 실행하면 이 오류가 발생하지 않지만, Windows와 함께 제공되는 기본 관리자 계정을 실수로 실행하지 않도록 해야 합니다. 이 계정은 별도의 사용자 계정이며 설치된 WSL 배포는 디자인 별로 표시되지 않습니다. 자세한 내용은 기본 제공 관리자 계정 사용 및 사용 안 함을 참조하세요.
3. WSL 실행 파일은 네이티브 시스템 디렉터리에만 설치됩니다. 64비트 Windows(또는 ARM64, 비 네이티브 조합)에서 32비트 프로세스를 실행하는 경우 호스트된 비 네이티브 프로세스에는 실제로 다른 System32 폴더가 표시됩니다. (x64 Window에서 볼 수 있는 32비트 프로세스는 \Windows\SysWOW64의 디스크에 저장됩니다.) 가상 폴더를 확인하여 호스트된 프로세스에서 “네이티브” system32에 액세스할 수 있습니다: \Windows\sysnative. 실제로 디스크에는 존재하지 않지만 파일 시스템 경로 확인자가 찾을 것입니다.
오류: 이 업데이트는 Linux용 Windows 하위 시스템을 사용하는 컴퓨터에만 적용됩니다.
- Linux 커널 업데이트 MSI 패키지를 설치하려면 WSL이 필요하며, 먼저 이를 사용하도록 설정해야 합니다. 실패하면 This update only applies to machines with the Windows Subsystem for Linux 메시지가 표시됩니다.
- 이 메시지가 표시되는 세 가지 가능한 원인은 다음과 같습니다.
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 설정으로 이동하여 '업데이트 확인'을 클릭하여 시스템에 최신 업데이트를 설치하는 것입니다. 백포트에 대한 전체 지침을 확인하세요.

'업데이트 확인'을 눌렀는데도 업데이트를 아직 받지 못한 경우 KB KB4566116을 수동으로 설치할 수 있습니다.

오류: 0x1bc when `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`

사용자는 Linux에서 직접 notepad.exe와 같은 Windows 실행 파일을 실행할 수 있습니다. 경우에 따라 다음과 같이 "명령을 찾을 수 없음" 오류가 발생할 수 있습니다.

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

$PATH에 Win32 경로가 없는 경우 interop에서 .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를 참조하세요.

"오류: 0x80370102 필요한 기능이 설치되어 있지 않아 가상 머신을 시작할 수 없습니다."

가상 머신 플랫폼 Windows 기능을 활성화하고 BIOS에서 가상화가 사용되고 있는지 확인하세요.

Hyper-V 시스템 요구 사항을 확인합니다.
컴퓨터가 VM인 경우 중첩된 가상화를 수동으로 사용하도록 설정합니다. 관리자와 함께 powershell을 시작하고 다음 명령을 실행하여 호스트 시스템에서 가상 머신의 이름으로 바꿉 <VMName> 니다(Hyper-V 관리자에서 이름을 찾을 수 있음).
```
Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
```
가상화를 사용하도록 설정하는 방법에 대한 자세한 지침은 PC 제조업체의 지침을 따르세요. 일반적으로 이는 시스템 BIOS를 사용하여 이러한 기능이 CPU에서 활성화되도록 할 수 있습니다. 이 프로세스에 대한 지침은 머신마다 다를 수 있습니다. 예는 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 Virtual Machine에서 이 오류를 수신하는 경우 신뢰할 수 있는 시작이 비활성화되었는지 확인합니다. 중첩 가상화는 Azure 가상 머신에서 지원되지 않습니다.

Virtual Machine에서 Hyper-V를 실행할 때 중첩된 가상화를 구성하는 방법에 대해 자세히 알아봅니다.

내 작업 컴퓨터 또는 엔터프라이즈 환경에서 WSL에 네트워크 연결이 없음

비즈니스 또는 엔터프라이즈 환경에는 무단 네트워크 트래픽을 차단하도록 구성된 Windows Defender 방화벽 설정이 있을 수 있습니다. 로컬 규칙 병합이 "아니요"로 설정된 경우 WSL 네트워킹은 기본적으로 작동하지 않으며 관리자는 이를 허용하기 위해 방화벽 규칙을 추가해야 합니다.

로컬 규칙 병합 설정은 다음 단계에 따라 확인할 수 있습니다.

Windows 방화벽 설정 스크린샷

"고급 보안이 포함된 Windows Defender 방화벽"을 엽니다(제어판의 "Windows Defender 방화벽"과 다름).
"로컬 컴퓨터의 고급 보안이 포함된 Windows Defender 방화벽" 탭을 마우스 오른쪽 단추로 클릭합니다.
"속성"을 선택합니다.
열리는 새 창에서 "공개 프로필" 탭을 선택합니다.
"설정" 섹션에서 "사용자 지정"을 선택합니다.
"규칙 병합"이 "아니요"로 설정되어 있는지 확인하려면 열리는 "공개 프로필에 대한 설정 사용자 지정" 창을 확인합니다. 그러면 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. 위 (1)의 DNS 항목을 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 2023년 9월 업데이트에서 자세히 알아보세요.

일부 VPN은 다음을 포함하여 WSL과 호환되지 않는 것으로 테스트되고 확인되었습니다.

"Bitdefender" 버전 26.0.2.1
"OpenVPN" 버전 2.6.501
"Mcafee Safe Connect" 버전 2.16.1.124

WSL에서 HttpProxy 미러링에 autoProxy를 사용할 때 고려 사항

WSL 구성 파일의 실험적 섹션에 있는 autoProxy 설정을 사용하여 HTTP/S 프록시 미러 구성할 수 있습니다. 이 설정을 적용할 때 다음 사항을 고려합니다.

PAC 프록시: WSL은 "WSL_PAC_URL" 환경 변수를 설정하여 Linux에서 설정을 구성합니다. Linux는 기본적으로 PAC 프록시를 지원하지 않습니다.
WSLENV와의 상호 작용: 사용자 정의 환경 변수가 이 기능에서 지정한 변수보다 우선합니다.

사용하도록 설정하면 Linux 배포판의 프록시 설정에 다음이 적용됩니다.

Linux 환경 변수 HTTP_PROXY는(은) Windows HTTP 프록시 구성에 설치된 하나 이상의 HTTP 프록시로 설정됩니다.
Linux 환경 변수 HTTPS_PROXY는(은) Windows HTTPS 프록시 구성에 설치된 하나 이상의 HTTP 프록시로 설정됩니다.
Linux 환경 변수 NO_PROXY는 Windows 구성 대상에 있는 HTTP/S 프록시를 무시하도록 설정됩니다.
WSL_PAC_URL를(을) 제외한 모든 환경 변수는 소문자와 대문자로 설정됩니다. 예: HTTP_PROXY 및 http_proxy

ZScaler 구성으로 인해 알려진 문제가 있습니다. 여기서 ZScaler는 Windows 프록시 구성을 반복적으로 사용하도록 설정하고 사용하지 않도록 설정하므로 WSL은 "호스트에서 Http 프록시 변경이 검색되었습니다." 알림을 반복적으로 표시합니다.

명령줄 블로그: WSL 2023년 9월 업데이트에서 자세히 알아보세요.

DNS 터널링을 사용하는 네트워킹 고려 사항

WSL이 인터넷에 연결할 수 없는 경우 Windows 호스트에 대한 DNS 호출이 차단되었기 때문일 수 있습니다. 이는 WSL VM에서 Windows 호스트로 보낸 DNS에 대한 네트워킹 패킷이 기존 네트워킹 구성에 의해 차단되기 때문입니다. DNS 터널링에서는 가상화 기능을 사용하여 Windows와 직접 통신하여 네트워킹 패킷을 보내지 않고 DNS 이름을 확인할 수 있도록 하여 이 문제를 해결합니다. 이 기능은 네트워크 호환성을 향상시키고 VPN, 특정 방화벽 설정 또는 기타 네트워킹 구성이 있는 경우에도 더 나은 인터넷 연결을 얻을 수 있도록 해야 합니다.

WSL 구성 파일의 실험적 섹션에 있는 dnsTunneling 설정을 사용하여 DNS 터널링을 구성할 수 있습니다. 이 설정을 적용할 때 다음 사항을 고려합니다.

WSL에서 VPN을 사용하는 경우 DNS 터널링을 켭니다. 대부분의 VPN은 NRPT 정책을 사용합니다. 이 정책은 DNS 터널링을 사용하는 경우에만 WSL DNS 쿼리에 적용됩니다.
Linux 배포의 파일에는 /etc/resolv.conf 최대 3개의 DNS 서버 제한이 있지만 Windows는 3개 이상의 DNS 서버를 사용할 수 있습니다. DNS 터널링을 사용하면 이러한 제한이 제거됩니다. 이제 Linux에서 모든 Windows DNS 서버를 사용할 수 있습니다.
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은 Docker 컨테이너의 DNS 쿼리에 호스트 DNS 설정 및 정책을 적용하는 고유한 방식(DNS 터널링과는 다른)을 가집니다.
DNS 터널링을 완벽하게 사용하도록 설정하려면 wsl.conf 파일의 generateResolvConf 옵션을 사용하지 않도록 설정하면 안 됩니다.
DNS 터널링을 사용하도록 설정하면 wsl.conf 파일의 generateHosts 옵션이 무시됩니다(Windows DNS 호스트 파일은 Linux /etc/hosts 파일에 복사되지 않음). Windows 호스트 파일의 정책은 Linux에서 파일을 복사할 필요 없이 Linux의 DNS 쿼리에 적용됩니다.

명령줄 블로그: WSL 2023년 9월 업데이트에서 자세히 알아보세요.

Windows 호스트가 WSL Virtual Machine으로 수신한 인바운드 트래픽을 조정하는 문제

미러된 네트워킹 모드(실험적 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)
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) 프로토콜을 통해 수행됩니다.

networkingMode를 NAT로 설정:

현재 이 기능은 DNS 터널링을 사용하는 경우 지원되지 않습니다. .local 이름의 확인을 사용하도록 설정하려면 다음 솔루션을 사용하는 것이 좋습니다.

DNS 터널링을 사용하지 않도록 설정합니다.
미러된 네트워킹 모드를 사용합니다.

networkingMode가 미러링됨으로 설정됨:

참고: 아래 기능을 얻으려면 WSL 빌드 2.3.17 이상에 있어야 합니다.

미러 모드는 멀티캐스트 트래픽을 지원하므로 mDNS(멀티캐스트 DNS) 프로토콜을 사용하여 .local 이름을 확인할 수 있습니다. Linux는 기본적으로 지원되지 않으므로 mDNS를 지원하도록 구성해야 합니다. 구성하는 한 가지 방법은 다음 두 단계를 사용하는 것입니다.

"libnss-mdns" 패키지 설치

sudo apt-get install libnss-mdns

*"libnss-mdns" 패키지는 mDNS(멀티캐스트 DNS)를 통해 호스트 이름 확인을 제공하는 GNU C 라이브러리(glibc)의 GNU NSS(이름 서비스 스위치) 기능에 대한 플러그 인입니다. 이 패키지를 사용하면 일반적인 Unix/Linux 프로그램이 임시 mDNS 도메인 .local에서 이름을 확인할 수 있습니다.

/etc/nsswitch.conf"호스트" 섹션에서 "mdns_minimal" 설정을 사용하도록 파일을 구성합니다. 파일의 콘텐츠 예제:

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 접미사는 /etc/resolv.conf의 "검색" 설정에서 Linux에서 구성됩니다.

접미사는 다음 순서로 /etc/resolv.conf로 구성되며, 이름을 확인할 때 Windows DNS 클라이언트가 접미사를 시도하는 순서와 유사합니다. 전역 DNS 접미사를 먼저 접미사로 추가한 다음 인터페이스별 DNS 접미사를 추가합니다.

Windows DNS 접미사가 변경되면 해당 변경 내용이 Linux에 자동으로 반영됩니다.

사례 3) DNS 터널링이 비활성화되고 SharedAccess DNS 프록시가 비활성화된 경우(dnsTunneling이 false로 설정되고 dnsProxy가 .wslconfig에서 false로 설정됨) 단일 DNS 접미사가 Linux에서 /etc/resolv.conf의 "도메인" 설정으로 구성됩니다.

Windows DNS 접미사가 변경되면 해당 변경 내용이 Linux에 반영되지 않습니다.

Linux에서 구성된 단일 DNS 접미사는 인터페이스별 DNS 접미사에서 선택됩니다(전역 및 추가 접미사는 무시됨).

Windows에 여러 인터페이스가 있는 경우 추론을 사용하여 Linux에서 구성할 단일 DNS 접미사를 선택합니다. 예를 들어 Windows에 VPN 인터페이스가 있는 경우 해당 인터페이스에서 접미사가 선택됩니다. VPN 인터페이스가 없으면 인터넷 연결을 제공할 가능성이 가장 큰 인터페이스에서 접미사가 선택됩니다.

networkingMode가 미러링됨으로 설정된 경우:

모든 Windows DNS 접미사는 /etc/resolv.conf의 "검색" 설정에서 Linux에서 구성됩니다.

접미사는 NAT 모드의 경우 2와 동일한 순서로 /etc/resolv.conf로 구성됩니다.

Windows DNS 접미사가 변경되면 해당 변경 내용이 Linux에 자동으로 반영됩니다.

참고: SetInterfaceDnsSettings를 사용하여 Windows에서 추가 DNS 접미사를 구성할 수 있습니다. - Win32 앱 | 설정 매개 변수에 플래그 DNS_SETTING_SUPPLEMENTAL_SEARCH_LIST 설정된 Microsoft Learn

WSL에서 DNS 문제 해결

WSL이 NAT 모드에서 컨테이너를 시작할 때 기본 DNS 구성은 Windows 호스트의 NAT 디바이스가 WSL 컨테이너에 대한 DNS '서버'로 사용되도록 하는 것입니다. DNS 쿼리가 WSL 컨테이너에서 Windows 호스트의 해당 NAT 디바이스로 전송되면 DNS 패킷이 NAT 디바이스에서 호스트의 공유 액세스 서비스로 전달됩니다. 응답은 역방향으로 WSL 컨테이너로 다시 전송됩니다. 공유 액세스에 대한 이 패킷 전달 프로세스에는 WSL이 처음에 WSL 컨테이너에 대한 NAT 가상 네트워크를 만들도록 HNS에 요청할 때 HNS 서비스에서 만든 인바운드 DNS 패킷을 허용하는 방화벽 규칙이 필요합니다.

이 NAT - 공유 액세스 디자인으로 인해 WSL에서 이름 확인을 중단 할 수있는 몇 가지 알려진 구성이 있습니다.

1. 엔터프라이즈는 로컬로 정의된 방화벽 규칙을 허용하지 않고 엔터프라이즈 정책 정의 규칙만 허용하는 정책을 푸시할 수 있습니다.

엔터프라이즈에서 설정하면 로컬로 정의된 규칙이므로 HNS에서 만든 방화벽 규칙이 무시됩니다. 이 구성이 작동하려면 엔터프라이즈에서 UDP 포트 53을 공유 액세스 서비스에 허용하도록 방화벽 규칙을 만들어야 합니다. 그렇지 않으면 WSL이 DNS 터널링을 사용하도록 설정할 수 있습니다. 다음을 실행하여 로컬로 정의된 방화벽 규칙을 허용하지 않도록 구성되어 있는지 확인할 수 있습니다. 도메인, 프라이빗 및 퍼블릭의 3개 프로필 모두에 대한 설정이 표시됩니다. 모든 프로필에 설정된 경우 WSL vNIC에 해당 프로필이 할당되면 패킷이 차단됩니다(기본값은 공용). 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에서 만든 방화벽 규칙이 차단됩니다.

WSL 에서 작동하려면 NAT DNS 프록시 구성을 선택 취소해야 합니다. 또는 DNS 터널링을 사용하도록 WSL을 설정할 수 있습니다.

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(Virtual Machine)에서 WSL을 실행할 때 고스트 어댑터가 표시되는 경우 다음 수동 단계에 따라 이러한 가상 PnP 디바이스를 찾아 삭제합니다. Microsoft는 수동 개입이 필요하지 않은 자동화된 솔루션을 연구하고 있습니다. 자세한 내용은 곧 제공될 예정입니다.

디바이스 관리자를 엽니다.
숨겨진 디바이스 표시 보기 >

숨겨진 디바이스 메뉴 표시 장치 관리자 스크린샷

네트워크 어댑터 열기

네트워크 어댑터 목록의 스크린샷

고스트 네트워크 어댑터를 마우스 오른쪽 단추로 클릭하고 디바이스 제거를 선택합니다 .

네트워크 목록에서 가상 pnp를 마우스 오른쪽 단추로 클릭하고 디바이스 제거를 선택하는 스크린샷

WSL을 시작하거나 배포를 설치하면 오류 코드가 반환됨

지침에 따라 GitHub의 WSL 리포지토리에 WSL 로그를 수집하여 자세한 로그를 수집하고 GitHub에 문제를 제출합니다.

WSL 업데이트

Linux용 Windows 하위 시스템에는 업데이트가 가능한 두 가지 구성 요소가 있습니다.

Linux용 Windows 하위 시스템 자체를 업데이트하려면 PowerShell 또는 CMD에서 wsl --update 명령을 사용합니다.
특정 Linux 배포판 사용자 바이너리를 업데이트하려면 업데이트하려는 Linux 배포판에서 apt-get update | apt-get upgrade 명령을 사용합니다.

apt-get upgrade 오류

일부 패키지는 아직 구현하지 않은 기능을 사용합니다. 예를 들어 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

"오류: 0x80040306" - 설치 시

이 오류는 레거시 콘솔을 지원하지 않는다는 사실과 관련이 있습니다. 레거시 콘솔을 해제하려면 다음을 수행합니다.

cmd.exe를 엽니다.
마우스 오른쪽 단추로 제목 표시줄 -> 속성 ->를 클릭하고, 레거시 콘솔 사용의 선택을 취소합니다.
확인을 클릭합니다.

"오류: 0x80040154" - Windows 업데이트 후

Windows 업데이트 중에 Linux용 Windows 하위 시스템 기능이 사용하지 않도록 설정될 수 있습니다. 이 문제가 발생하면 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 기능을 사용하도록 설정합니다(아직 사용하지 않는 경우).
Reboot
lxrun /uninstall /full을 실행합니다
Bash를 설치합니다.

WSL에서 인터넷에 액세스할 수 없음

일부 사용자가 WSL에서 인터넷 액세스를 차단하는 특정 방화벽 애플리케이션의 문제를 보고했습니다. 보고된 방화벽은 다음과 같습니다.

Kaspersky
AVG
Avast
Symantec Endpoint Protection

방화벽을 해제하면 액세스가 허용되는 경우도 있습니다. 단순히 방화벽을 설치하면 경우에 따라 액세스가 차단되는 것처럼 보입니다.

Microsoft Defender 방화벽을 사용하는 경우 "허용되는 앱 목록에 있는 연결을 포함하여 들어오는 연결을 모두 차단합니다"를 선택 취소하면 액세스가 허용됩니다.

ping 사용 시의 권한 거부 오류

Windows 1주년 업데이트, 버전 1607의 경우 WSL에서 ping을 실행하려면 Windows의 관리자 권한이 필요합니다. ping을 실행하려면 Windows의 Ubuntu에서 관리자 권한으로 Bash를 실행하거나 CMD/PowerShell 프롬프트에서 관리자 권한으로 bash.exe를 실행합니다.

이후 버전의 Windows인 빌드 14926 이상의 경우 관리자 권한이 더 이상 필요하지 않습니다.

Bash가 중지됨

Bash로 작업하는 동안 Bash가 중지되거나 교착 상태가 되어 입력에 응답하지 않는 경우 메모리 덤프를 수집하고 보고하여 문제를 진단하는 데 도움이 됩니다. 다음 단계를 수행하면 시스템의 작동이 중단됩니다. 편안하지 않으면 이 작업을 수행하지 않거나 해당 작업을 저장한 후에 수행하세요.

메모리 덤프를 수집하려면 다음을 수행합니다.

메모리 덤프 유형을 "전체 메모리 덤프"로 변경합니다. 덤프 유형을 변경하는 동안 현재 유형을 적어 둡니다.
이 단계를 사용하여 키보드 컨트롤을 사용하는 시스템 작동 중단을 구성합니다.
중지 또는 교착 상태를 재현합니다.
(2)의 키 시퀀스를 사용하여 시스템의 작동을 중단시킵니다.
시스템의 작동이 중단되고 메모리 덤프가 수집됩니다.
시스템이 다시 부팅되면 memory.dmp를 secure@microsoft.com에 보고합니다. 덤프 파일의 기본 위치는 %SystemRoot%\memory.dmp 또는 C:\Windows\memory.dmp(C:가 시스템 드라이브인 경우)입니다. 이메일에서 덤프는 Windows 팀의 WSL 또는 Bash에 대한 것입니다.
메모리 덤프 유형을 원래 설정으로 복원합니다.

빌드 번호 확인

PC의 아키텍처 및 Windows 빌드 번호를 확인하려면
설정>시스템>정보를 차례로 엽니다.

OS 빌드 및 시스템 종류 필드를 찾습니다.
빌드 및 시스템 종류 필드의 스크린샷

Windows Server 빌드 번호를 확인하려면 PowerShell에서 다음을 실행합니다.

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

WSL이 사용하도록 설정되었는지 확인

관리자 권한 PowerShell 창에서 다음을 실행하여 Linux용 Windows 하위 시스템을 사용하도록 설정했는지 확인할 수 있습니다.

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

OpenSSH 서버 연결 문제

SSH 서버를 연결하려고 하면 "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
```

시작 로그를 확인하고, HostKeys를 사용할 수 있고 다음과 같은 로그 메시지가 표시되지 않는지 확인합니다.

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/ 아래에 없으면 해당 키를 다시 생성하거나 OpenSSH 서버를 제거 후 설치해야 합니다.

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

"참조 된 어셈블리를 찾을 수 없습니다." WSL 선택적 기능을 사용하도록 설정하는 경우

이 오류는 잘못된 설치 상태와 관련이 있습니다. 이 문제를 시도해 보고 해결하려면 다음 단계를 수행하세요.

PowerShell에서 WSL 기능 사용 명령을 실행하는 경우 [시작] 메뉴를 열고, 'Windows 기능 사용/사용 안 함'을 검색하여 GUI를 대신 사용해 본 다음, 목록에서 선택적 구성 요소를 설치할 'Linux용 Windows 하위 시스템'을 선택합니다.
[설정], [업데이트]로 차례로 이동하고, '업데이트 확인'을 클릭하여 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.

WSL의 스토어 버전을 사용하는 경우 알려진 문제입니다. 현재 WSL 1을 사용하거나 WSL의 Windows 버전을 사용하여 이 문제를 해결할 수 있습니다. 자세한 내용은 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가 없는지 확인합니다. 있는 경우에는 주석 처리합니다.
wsl -t 다음에 배포 이름을 입력하여 배포를 다시 시작하거나 cmd 또는 PowerShell에서 wsl --shutdown을 실행합니다.

WSL 2를 설치한 후 부팅할 수 없음

사용자가 WSL 2를 설치한 후 부팅할 수 없는 문제에 대해 알고 있습니다. 현재 이러한 문제를 철저하게 진단하고 있으며, 버퍼 크기를 변경하거나 적절한 드라이버를 설치하면 이 문제를 해결하는 데 도움이 된다는 사용자들의 제보가 있었습니다. GitHub 문제에서 이 문제에 대한 최신 업데이트를 확인하세요.

ICS를 사용하지 않는 경우 WSL 2 오류

ICS(인터넷 연결 공유)는 WSL 2의 필수 구성 요소입니다. ICS 서비스는 HNS(호스트 네트워크 서비스)에서 WSL 2가 NAT, DNS, DHCP 및 호스트 연결 공유에 의존하는 기본 가상 네트워크를 만드는 데 사용됩니다.

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 크리에이터 업데이트(2017년 10월, 빌드 16299) 또는 1주년 업데이트(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 명령을 사용한 다음, C:\> bash.exe 명령으로 Bash.exe를 실행하여 로그인합니다. 배포판 암호 명령 $ passwd username을 사용하여 암호를 다시 설정한 다음, $ exit 명령을 사용하여 Linux 명령줄을 닫습니다. Windows 명령 프롬프트 또는 Powershell에서 C:\> lxrun.exe /setdefaultuser username 명령을 사용하여 기본 사용자를 다시 일반 Linux 사용자 계정으로 설정합니다.

기존 버전의 WSL 제거

크리에이터 업데이트(2017년 10월, 빌드 16299) 이전 버전의 Windows 10에 WSL을 설치한 경우 설치된 이전 Linux 배포판에서 꼭 필요한 파일, 데이터 등을 Microsoft Store를 통해 설치한 최신 배포판으로 마이그레이션하는 것이 좋습니다. 머신에서 기존 배포판을 제거하려면 명령줄 또는 PowerShell 인스턴스에서 wsl --unregister Legacy 명령을 실행합니다. Windows 파일 탐색기 또는 PowerShell에서 rm -Recurse $env:localappdata/lxss/ 명령으로 %localappdata%\lxss\ 폴더(및 모든 하위 콘텐츠)를 삭제하여 이전 배포판을 수동으로 제거하는 방법도 있습니다.

다음을 통해 공유