Устранение неполадок подсистемы Windows для Linux

Мы рассмотрели некоторые распространенные сценарии устранения неполадок, связанные с WSL ниже, но рассмотрите возможность поиска проблем, поданных в репозитории продуктов WSL на сайте GitHub.

Отправка файла проблемы, отчета об ошибках, запроса функций

Репозиторий продукта 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, см. в руководстве Документации Майкрософт .
• файл проблемы с терминалом Windows с помощью репозитория продукта терминала Windows, если проблема связана с терминалом Windows, консолью Windows или пользовательским интерфейсом командной строки.

Проблемы с установкой

• сбой установки с ошибкой 0x80070003

  • Подсистема Windows для Linux выполняется только на системном диске (обычно это ваш C: диск). Убедитесь, что дистрибутивы хранятся на системном диске:
  • В Windows 10 откройте настройки —>система —>хранилище —>дополнительные параметры хранилища: Изменение места сохранения нового контента
  • В Windows 11 откройте Параметры —>Система —>Хранилище —>Расширенные параметры хранилища —>Где сохранять новое содержимое

• Сбой WslRegisterDistribution с ошибкой 0x8007019e

  • Необязательный компонент подсистемы Windows для Linux не включен:
  • Откройте Панель управления —>Программы и компоненты —>Включение или отключение компонентов Windows —> отметьте Подсистему Windows для Linux или используйте командлет PowerShell, упомянутый в начале этой статьи.

• Установка завершилась сбоем с ошибкой 0x80070003 или 0x80370102

  • Убедитесь, что виртуализация включена внутри BIOS компьютера. Инструкции по этому способу будут различаться в зависимости от компьютера и, скорее всего, будут находиться в параметрах, связанных с ЦП.
  • WSL2 требует, чтобы ЦП поддерживал функцию преобразования адресов второго уровня (SLAT), которая появилась в процессорах Intel Nehalem (Intel Core 1-го поколения) и AMD Opteron. Старые ЦП (например, Intel Core 2 Duo) не смогут запускать WSL2, даже если платформа виртуальной машины успешно установлена.

• ошибка при попытке обновления: Invalid command line option: wsl --set-version Ubuntu 2

  • Убедитесь, что у вас включена подсистема Windows для Linux, и вы используете сборку 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 не распознается как имя командлета, функции, файла скрипта или оперализуемой программы.

  • Убедитесь, что установлен необязательный компонент подсистемы Windows для Linux . Кроме того, если вы используете устройство ARM64 и выполняете эту команду из PowerShell, вы получите эту ошибку. Вместо этого запустите wsl.exe из PowerShell Coreили командной строки Windows.

• ошибка . Подсистема Windows для Linux не имеет установленных дистрибутивов.

  • Если вы получите эту ошибку после установки дистрибутивов WSL:
  1. Запустите дистрибутив по крайней мере один раз, прежде чем вызывать его из командной строки.
  2. Проверьте, используются ли у вас отдельные учетные записи пользователей. Выполнение основной учетной записи пользователя с повышенными разрешениями (в режиме администрирования) не должно привести к этой ошибке, но убедитесь, что вы не случайно используете встроенную учетную запись администратора, которая поставляется с Windows. Это отдельная учетная запись пользователя и, по задумке, не отображает установленные дистрибутивы WSL. Дополнительные сведения см. в разделе Включение и отключение встроенной учетной записи администратора.
  3. Исполняемый файл WSL устанавливается только в системный каталог по умолчанию. При выполнении 32-разрядного процесса в 64-разрядной версии Windows (или на ARM64, в любом не родном сочетании), запущенный процесс, работающий не в родной среде, фактически видит другую папку System32. (Тот, который 32-разрядный процесс видит на x64 Windows, хранится на диске в \Windows\SysWOW64.) Вы можете получить доступ к "родной" папке system32 из размещенного процесса, проверив в виртуальной папке: \Windows\sysnative. Он на самом деле не будет присутствовать на диске, имейте в виду, но сопоставитель пути файловой системы найдет его.

• ошибка. Это обновление применяется только к компьютерам с подсистемой Windows для Linux.

  • Чтобы установить пакет MSI обновления ядра Linux, необходимо сначала включить WSL. Если это завершится ошибкой, появится сообщение: This update only applies to machines with the Windows Subsystem for Linux.
  • Существует три возможные причины, по которой вы видите это сообщение:

  1. Вы все еще находитесь в старой версии Windows, которая не поддерживает WSL 2. См. шаг 2 для требований к версии и ссылок на обновление.

  2. WSL не включен. Вам потребуется вернуться к шагу 1 и убедиться, что на компьютере включена дополнительная функция WSL.

  3. После включения WSL требуется перезагрузка, чтобы она вступила в силу, перезагрузите компьютер и повторите попытку.

• Ошибка: WSL 2 требует обновления компонента ядра. Дополнительные сведения см. в https://aka.ms/wsl2kernel.

  • Если пакет ядра Linux отсутствует в папке %SystemRoot%\system32\lxss\tools, эта ошибка возникает. Устраните его, установив пакет MSI обновления ядра Linux на шаге 4 из этих инструкций по установке. Возможно, потребуется удалить MSI через "Удаление и установка программ"и затем установить его заново.

Распространенные проблемы

Я на Windows 10 версии 1903, и я по-прежнему не вижу опций WSL 2

Скорее всего, это связано с тем, что ваша машина еще не получила обратный порт для WSL 2. Самый простой способ устранить эту проблему — перейти к параметрам Windows и нажать кнопку "Проверить наличие обновлений", чтобы установить последние обновления в вашей системе. См. полные инструкции по выполнению обратной портировки.

Если вы нажимаете "Проверить наличие обновлений" и по-прежнему не получаете обновления, вы можете установить KB 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

Не удается получить доступ к WSL-файлам из Windows

Файловый сервер протокола 9p предоставляет службу на стороне Linux, чтобы разрешить Windows получить доступ к файловой системе Linux. Если вы не можете получить доступ к WSL с помощью \\wsl$ в Windows, это может быть связано с неправильной запуском 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 и установите ядро вручную, следуя указаниям на этой странице документации.

command not found при выполнении .exe Windows в Linux

Пользователи могут запускать исполняемые файлы Windows, такие как notepad.exe непосредственно из Linux. Иногда вы можете нажать кнопку "команда не найдена", как показано ниже:

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

Если в $PATH нет путей Win32, интероперабельность не сможет найти .exe. Его можно проверить, выполнив echo $PATH в Linux. Ожидается, что в выходных данных появится путь Win32 (например, /mnt/c/Windows). Если вы не видите пути к Windows, скорее всего, ваш ПУТЬ перезаписывается оболочкой Linux.

Вот пример, как /etc/profile в Debian привел к возникновению проблемы:

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.

1. Проверьте системные требования Hyper-V

2. Если ваш компьютер — это виртуальная машина, включите вложенную виртуализацию вручную. Запустите PowerShell с администратором и выполните следующую команду, заменив <VMName> именем виртуальной машины в хост-системе (вы можете найти имя в диспетчере Hyper-V):

   Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
   

3. Следуйте рекомендациям производителя компьютера о том, как включить виртуализацию. Как правило, это может включать использование системного BIOS, чтобы обеспечить включение этих функций на ЦП. Инструкции по этому процессу могут отличаться от компьютера к компьютеру, см. в этой статье от компьютера Bleeping Computer.

4. Перезапустите компьютер после включения необязательного компонента Virtual Machine Platform.

5. Убедитесь, что запуск гипервизора включен в конфигурации загрузки. Это можно проверить, запустив PowerShell с повышенными правами.

    bcdedit /enum | findstr -i hypervisorlaunchtype
   

   Если вы видите hypervisorlaunchtype Off, гипервизор отключен. Чтобы включить его выполнение в powershell с повышенными привилегиями, выполните следующие действия.

    bcdedit /set hypervisorlaunchtype Auto
   

6. Кроме того, если у вас установлены сторонние гипервизоры (например, VMware или VirtualBox), убедитесь, что они доступны в последних версиях, которые могут поддерживать HyperV (VMware 15.5.5+ и VirtualBox 6+) или отключены.

7. Если вы получаете эту ошибку на виртуальной машине Azure, убедитесь, что доверенного запуска отключен. Вложенная виртуализация не поддерживается на виртуальных машинах Azure сдоверенным запуском.

Узнайте больше о том, как настроить вложенную виртуализацию при запуске Hyper-V на виртуальной машине.

WSL не имеет сетевого подключения на рабочем компьютере или в среде Enterprise

Для бизнес-сред или корпоративных сред могут быть настроены параметры брандмауэра Защитника Windows , настроенные для блокировки несанкционированного сетевого трафика. Если объединение локальных правил установлено на "Нет", сеть WSL не будет работать по умолчанию, и администратору потребуется добавить правило брандмауэра, чтобы его разрешить.

Чтобы подтвердить настройки слияния локального правила, выполните следующие действия:

1. Откройте "Брандмауэр Защитника Windows с расширенной безопасностью" (это отличается от брандмауэра Защитника Windows на панели управления)
2. Щелкните правой кнопкой мыши вкладку "Брандмауэр Защитника Windows с расширенной безопасностью на локальном компьютере"
3. Выберите "Свойства"
4. Выберите вкладку "Общедоступный профиль" в открываемом окне
5. Выберите "Настроить" в разделе "Параметры"
6. Проверьте в открывшемся окне "Настройка параметров для общедоступного профиля", установлено ли "Слияние правил" на "Нет". Это заблокирует доступ к WSL.

Инструкции по изменению этого параметра брандмауэра см. в разделе Настройка Hyper-V брандмауэра.

WSL не имеет сетевого подключения после подключения к VPN

Если после подключения к VPN в Windows bash потеряет сетевое подключение, попробуйте выполнить это обходное решение из bash. Это решение позволит вручную переопределить разрешение DNS с помощью /etc/resolv.conf.

1. Обратите внимание на DNS-сервер VPN из выполняемого действия ipconfig.exe /all
2. Сделать копию существующего resolv.conf sudo cp /etc/resolv.conf /etc/resolv.conf.new
3. Отключить текущий resolv.conf sudo unlink /etc/resolv.conf
4. sudo mv /etc/resolv.conf.new /etc/resolv.conf
5. Измените /etc/wsl.conf и добавьте это содержимое в файл. (Более подробную информацию об этой настройке можно найти в конфигурации дополнительных параметров: )

[network]
generateResolvConf=false

6. Откройте /etc/resolv.conf и
   a. Удалите первую строку из файла с комментарием, описывающим автоматическое создание
   b. Добавьте запись DNS из выше (1) как самую первую запись в списке DNS-серверов.
   с. Закройте файл.
   

После отключения VPN необходимо вернуть изменения в /etc/resolv.conf. Для этого выполните указанные ниже действия.

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

Проблемы Cisco Anyconnect VPN с WSL в режиме NAT

VPN Cisco AnyConnect изменяет маршруты таким образом, чтобы предотвратить работу NAT. Существует обходное решение, специфическое для WSL 2: см. руководство администратора клиента Cisco AnyConnect Secure Mobility , версия 4.10 - Устранение неполадок.

Проблемы с подключением WSL к VPN при включенном режиме зеркального сетевого подключения.

Зеркальный сетевой режим в настоящее время является экспериментальным параметром вконфигурации WSL. Традиционная архитектура сети NAT WSL может быть обновлена до нового сетевого режима под названием "Зеркальный сетевой режим". Если для экспериментального networkingMode установлено значение mirrored, сетевые интерфейсы, имеющиеся в Windows, зеркально отражаются в Linux для повышения совместимости. Дополнительные сведения см. в блоге командной строки: обновление WSL за сентябрь 2023 г..

Некоторые VPN были протестированы и было подтверждено, что они несовместимы с WSL, в том числе:

• Bitdefender версии 26.0.2.1
• OpenVPN версии 2.6.501
• "Mcafee Safe Connect" версии 2.16.1.124

Рекомендации при использовании автопрокси для зеркального отображения HttpProxy в WSL

Настройка зеркалирования HTTP/S прокси может быть выполнена с помощью параметра autoProxy в экспериментальном разделе файла конфигурации WSL. При применении этого параметра обратите внимание на следующие аспекты:

• прокси-сервер PAC: WSL настраивает параметр в Linux, задав переменную среды WSL_PAC_URL. Linux по умолчанию не поддерживает прокси-серверы PAC.
• Взаимодействие с WSLENV: определяемые пользователем переменные среды имеют приоритет над теми, которые указаны этой функцией.

При включении следующие параметры применяются к параметрам прокси-сервера в дистрибутивах Linux:

• Переменная среды Linux HTTP_PROXYустанавливается на один или несколько прокси-серверов HTTP, установленных в конфигурации прокси-сервера Windows HTTP.
• Переменная среды Linux HTTPS_PROXYустанавливается на один или несколько прокси-серверов HTTPS, установленных в конфигурации прокси-сервера Windows HTTP.
• Переменная среды Linux, NO_PROXY, настроена для обхода всех прокси-серверов HTTP/S, найденных в целевых объектах конфигурации Windows.
• Каждая переменная среды, за исключением WSL_PAC_URL, имеет как нижний регистр, так и верхний регистр. Например, HTTP_PROXY и http_proxy.

Существует известная проблема, вызванная конфигурациями ZScaler, при которой ZScaler неоднократно включает и отключает конфигурации прокси-сервера Windows, что приводит к многократному отображению уведомления "Изменение прокси-сервера HTTP было обнаружено на узле".

Дополнительные сведения см. в блоге "Командная строка": обновление WSL за сентябрь 2023 г..

Рекомендации по работе с сетями с туннелированием DNS

Если WSL не удается подключиться к Интернету, это может быть вызвано блокировкой DNS-вызова узла Windows. Это связано с тем, что сетевой пакет для DNS, отправленный виртуальной машиной WSL на узел Windows, блокируется существующей конфигурацией сети. Туннелирование DNS решает эту проблему, используя функцию виртуализации для прямого взаимодействия с Windows, что позволяет разрешать DNS-имя без отправки сетевого пакета. Эта функция должна повысить совместимость сети и обеспечить более эффективное подключение к Интернету, даже если у вас есть VPN, определенная настройка брандмауэра или другие сетевые конфигурации.

Туннелирование DNS можно настроить с помощью параметра dnsTunneling в экспериментальном разделе файла конфигурации WSL. При применении этого параметра обратите внимание на следующие аспекты:

• Если вы используете VPN с WSL, включите туннелирование DNS. Многие VPN используют политики NRPT, которые применяются только к запросам WSL DNS при включении туннелирования DNS.
• Файл /etc/resolv.conf в дистрибутиве Linux имеет ограничение на 3 DNS-сервера, в то время как Windows может использовать более 3 DNS-серверов. Использование туннелирования DNS удаляет это ограничение. Теперь все DNS-серверы Windows теперь могут использоваться Linux.
• WSL будет использовать суффиксы Windows DNS в следующем порядке (аналогично заказу, используемому клиентом Windows DNS):
  1. Глобальные суффиксы DNS
  2. Дополнительные суффиксы DNS
  3. Суффиксы DNS для каждого интерфейса
  4. Если шифрование DNS (DoH, DoT) включено в Windows, шифрование будет применено к DNS-запросам из WSL. Если пользователи хотят включить DoH, DoT в Linux, им необходимо отключить туннелирование DNS.
• Запросы DNS из контейнеров Docker, управляемых Docker Desktop, обходят туннелирование DNS. Docker Desktop имеет собственный способ (отличается от туннелирования DNS) применения параметров и политик узла к DNS-запросам из контейнеров Docker.
• Чтобы туннелирование DNS было успешно включено, параметр generateResolvConf в файле wsl.conf не должен быть отключен.
• При включении туннелирования DNS параметр generateHosts в файле wsl.conf игнорируется (файл узлов Windows DNS не копируется в файле Linux /etc/hosts). Политики в файле узлов Windows будут применяться к DNS-запросам из Linux без необходимости копирования файла в Linux.

Дополнительную информацию можно найти в блоге "Командная строка": обновление WSL за сентябрь 2023 г..

Проблемы с управлением входящим трафиком, полученным узлом Windows на виртуальную машину WSL

При использовании режима зеркального сетевого подключения (экспериментальный networkingMode установлен на mirrored), некоторый входящий трафик, получаемый узлом Windows, никогда не будет перенаправлен на виртуальную машину Linux. Этот трафик выглядит следующим образом:

• Порт 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 будет настраивать:

Проблемы с контейнером Docker в WSL2 при включенном режиме зеркального сетевого подключения и использовании пространстве имен сети по умолчанию.

Существует известная проблема, из-за которой контейнеры Docker Desktop с опубликованными портами (docker run –publish/-p) не будут созданы. Команда WSL работает с командой Docker Desktop для решения этой проблемы. Чтобы обойти проблему, используйте сетевое пространство имен узла в контейнере Docker. Задайте тип сети с помощью параметра --network host, используемого в команде Docker Run. Альтернативным решением является перечисление опубликованного номера порта в параметре ignoredPorts экспериментального раздела в файле конфигурации WSL.

Проблемы с контейнером Docker при запуске диспетчера сети

Существует известная проблема с контейнерами Docker, у которых запущена служба Network Manager. Симптомы включают сбои при попытке установить петлевые соединения с хостом. Рекомендуется остановить службу Network Manager, чтобы правильно настроить сеть WSL.

sudo systemctl disable network-manager.service

Разрешение имен .local в WSL

Чтобы разрешить имена узлов IP-адресам в локальной сети без необходимости обычного DNS-сервера, часто используются локальные имена. Это достигается с помощью протокола mDNS (многоадресного DNS), который работает за счет многоадресного трафика.

networkingMode установлен в NAT:

В настоящее время эта функция не поддерживается при включении туннелирования DNS. Чтобы включить разрешение локальных имен, рекомендуется использовать следующие решения:

• Отключите туннелирование DNS.
• Используйте зеркальный сетевой режим.

networkingMode установлен в режиме Mirrored:

Примечание. Чтобы иметь приведенные ниже функциональные возможности, необходимо использовать сборку WSL 2.3.17 или более поздней версии.

Так как зеркальный режим поддерживает многоадресный трафик, протокол mDNS (многоадресный DNS) можно воспользоваться для разрешения имён в зоне .local. Linux должен быть настроен для поддержки mDNS, так как он не делает это по умолчанию. Одним из способов его настройки является использование следующих двух шагов.

1. Установка пакета libnss-mdns

sudo apt-get install libnss-mdns

*Пакет libnss-mdns — это плагин для функции Name Service Switch (NSS) библиотеки GNU C (glibc), который обеспечивает разрешение имен узлов через многоканальный DNS (mDNS). Этот пакет эффективно позволяет обычным программам Unix/Linux разрешать имена в домене ad-hoc mDNS .local.

2. Настройте файл /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

Суффиксы DNS в WSL

В зависимости от параметров в файле .wslconfig, WSL будет иметь следующую логику работы с суффиксами DNS:

Если для сетиMode задано значение NAT:

Вариант 1. По умолчанию суффикс DNS не настроен в Linux.

Вариант 2. Если туннелирование DNS включено (для dnsTunneling задано значение true в wslconfig); все суффиксы Windows DNS настроены в Linux, в настройке 'search' файла /etc/resolv.conf.

Суффиксы настраиваются в файле /etc/resolv.conf в следующем порядке, подобно тому, в котором DNS-клиент Windows пытается использовать суффиксы при разрешении имени: сначала глобальные суффиксы DNS, затем дополнительные суффиксы DNS, затем суффиксы DNS интерфейса.

При изменении суффиксов WINDOWS DNS это изменение будет автоматически отражено в Linux.

Случай 3. Если туннелирование DNS отключено и DNS-прокси SharedAccess отключен (dnsTunneling имеет значение false, а dnsProxy имеет значение false в .wslconfig), один DNS-суффикс настроен в Linux в параметре "domain" файла /etc/resolv.conf.

Если в DNS-суффиксах Windows есть изменение, это изменение не отражается в Linux.

Один суффикс DNS, настроенный в Linux, выбирается из суффиксов DNS для каждого интерфейса (глобальные и дополнительные суффиксы игнорируются).

Если Windows имеет несколько интерфейсов, эвристика используется для выбора одного DNS-суффикса, который будет настроен в Linux. Например, если в Windows есть VPN-интерфейс, суффикс выбирается из этого интерфейса. Если VPN-интерфейс отсутствует, суффикс выбирается из интерфейса, который, скорее всего, дает подключение к Интернету.

Если для networkingMode задано значение Mirrored:

Все суффиксы DNS Windows настроены в Linux в параметре поиска /etc/resolv.conf.

Суффиксы настраиваются в /etc/resolv.conf в том же порядке, что и в случае 2) в режиме NAT

При изменении суффиксов WINDOWS DNS это изменение будет автоматически отражено в Linux.

Примечание: дополнительные суффиксы DNS можно настроить в Windows с помощью SetInterfaceDnsSettings в Win32 приложениях | Microsoft Learn, установив флаг DNS_SETTING_SUPPLEMENTAL_SEARCH_LIST в параметре настроек.

Устранение неполадок DNS в WSL

Конфигурация DNS по умолчанию, когда WSL запускает контейнер в режиме NAT, предусматривает использование устройства NAT на хосте Windows в качестве DNS-сервера для контейнера WSL. Когда DNS-запросы отправляются из контейнера WSL на это устройство NAT на узле Windows, dns-пакет перенаправляются с устройства NAT в службу общего доступа на узле; ответ отправляется в обратном направлении обратно в контейнер WSL. Для этого процесса пересылки пакетов в общий доступ требуется правило брандмауэра, чтобы разрешить входящий пакет DNS, созданный службой HNS, когда WSL первоначально запрашивает HNS создать виртуальную сеть NAT для своего контейнера WSL.

Из-за этого NAT-дизайна общего доступа существуют некоторые известные конфигурации, которые могут нарушить разрешение имен в WSL.

1. Предприятие может вводить политику, которая не позволяет использовать локально определённые правила брандмауэра, разрешая только правила, определенные корпоративной политикой.

Если это задано предприятием, созданное правило брандмауэра HNS игнорируется, так как это локально определенное правило. Для работы этой конфигурации предприятие должно создать правило брандмауэра, чтобы разрешить трафик UDP порта 53 в службу общего доступа, или настроить WSL на использование DNS-туннелирования. Можно увидеть, настроено ли это, чтобы не разрешать локальные правила брандмауэра, выполнив указанные ниже действия. Обратите внимание, что в этом разделе отображаются параметры для всех 3 профилей: домен, частный и общедоступный. Если он установлен в любом профиле, пакеты будут заблокированы, если виртуальный сетевой адаптер WSL назначен этим профилем (по умолчанию — общедоступный). Это только фрагмент первого профиля брандмауэра, возвращаемого в 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, которые блокируют все правила входящего трафика.

Эти параметры переопределяют любое правило брандмауэра Allow-Inbound. Этот параметр заблокирует правило брандмауэра UDP, созданное HNS, и не позволит WSL осуществлять разрешение имен. Для работы этой конфигурации необходимо настроить WSL для использования туннелирования DNS. Этот параметр всегда блокирует DNS-прокси NAT.

из групповой политики:

Конфигурация компьютера \ Административные шаблоны \ Сеть \ Сетевые подключения \ Брандмауэр Защитника Windows \ Профиль домена | Стандартный профиль

"Брандмауэр Защитника Windows: не разрешать исключения" — включено

из политики 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), правило брандмауэра, созданное HNS, чтобы разрешить общий доступ UDP-пакетов, будет заблокировано.

Для работы настройки DNS-прокси-сервера NAT из WSL этот флажок должен быть снят, или WSL можно задать для использования туннелирования DNS.

4. Правило брандмауэра HNS, позволяющее пакетам DNS предоставить общий доступ, может стать недопустимым, ссылаясь на предыдущий идентификатор интерфейса WSL. Это недостаток в HNS, который был исправлен с последним выпуском Windows 11. В предыдущих выпусках, если это происходит, обнаружить это нелегко, но существует простое обходное решение:

• Остановка 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 существует, удалите это значение реестра и перезагрузите

Ручной способ удаления фантомных адаптеров

адаптеры-призракиили фантомные устройства Plug and Play (PnP) относятся к аппаратным компонентам, которые отображаются в системе, но физически не подключены. Эти "призраки" устройств могут вызвать путаницу и загромождение в параметрах системы. Если при запуске WSL в виртуальной машине отображаются фантомные адаптеры, выполните следующие шаги, чтобы найти и удалить эти фантомные PnP устройства. Корпорация Майкрософт работает над автоматизированным решением, которое не требует вмешательства вручную. Дополнительные сведения будут в ближайшее время.

1. Откройте диспетчер устройств
2. Показать скрытые устройства >

3. Открыть сетевые адаптеры

4. Щелкните правой кнопкой мыши сетевой адаптер и выберите Удалить устройство

Запуск WSL или установка дистрибутива возвращает код ошибки

Следуйте инструкциям по сбору логов WSL в репозитории WSL на GitHub для получения подробных логов и создания запроса на нашем GitHub.

Обновление WSL

Существует два компонента подсистемы Windows для Linux, которые могут потребовать обновления.

1. Чтобы обновить подсистему Windows для Linux, используйте команду wsl --update в PowerShell или CMD.

2. Чтобы обновить двоичные файлы конкретных пользователей дистрибутива Linux, используйте команду: apt-get update | apt-get upgrade в дистрибутиве Linux, который требуется обновить.

Ошибки apt-get при обновлении

Некоторые пакеты используют функции, которые мы еще не реализовали. udev, например, еще не поддерживается и вызывает несколько ошибок apt-get upgrade.

Чтобы устранить проблемы, связанные с udev, выполните следующие действия.

1. Запишите следующее в /usr/sbin/policy-rc.d и сохраните изменения.

   #!/bin/sh
   exit 101
   

2. Добавление разрешений на выполнение для /usr/sbin/policy-rc.d:

   chmod +x /usr/sbin/policy-rc.d
   

3. Выполните следующие команды:

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

"Ошибка: 0x80040306" при установке

Это связано с тем, что мы не поддерживаем устаревшую консоль. Чтобы отключить устаревшую консоль, выполните следующее:

1. Открой cmd.exe
2. Щелкните правой кнопкой мыши на строке заголовка - свойства> -> снимите флажок "Использовать наследованную консоль"
3. Нажмите кнопку "ОК"

Ошибка: 0x80040154 после обновления Windows

Подсистема Windows для Linux может быть отключена во время обновления Windows. Если это произойдет, необходимо повторно включить функцию Windows. Инструкции по включению подсистемы Windows для Linux см. в руководстве по установке вручную .

Изменение языка отображения

Установка WSL попытается автоматически изменить языковой стандарт Ubuntu в соответствии с языковым стандартом установки Windows. Если вы не хотите это поведение, вы можете выполнить эту команду, чтобы изменить языковой стандарт Ubuntu после завершения установки. Вам придется повторно запустить bash.exe, чтобы это изменение вступило в силу.

В следующем примере локаль изменяется на en-US:

sudo update-locale LANG=en_US.UTF8

Проблемы с установкой после восстановления системы Windows

1. Удалите папку %windir%\System32\Tasks\Microsoft\Windows\Windows Subsystem for Linux.
   Примечание. Не делайте этого, если необязательный компонент полностью установлен и работает.
2. Включите необязательную функцию WSL (если она еще не включена)
3. Перезагрузить
4. lxrun /uninstall /full
5. Установка bash

Нет доступа к Интернету в WSL

Некоторые пользователи сообщили о проблемах с определенными приложениями брандмауэра, блокирующими доступ к Интернету в WSL. Сообщается, что брандмауэры:

1. Касперский
2. СРЕДНЯЯ
3. Avast
4. Symantec Endpoint Protection

В некоторых случаях отключение брандмауэра разрешает доступ. В некоторых случаях простая установка брандмауэра, кажется, блокирует доступ.

Если вы используете брандмауэр Microsoft Defender, чтобы разрешить доступ, снимите флажок "Блокировать все входящие подключения, в том числе из списка разрешенных приложений".

Ошибка "Отказано в доступе" при использовании команды ping

Для юбилейного обновления Windowsверсии 1607 права администратора в Windows требуются для запуска проверки подлинности в WSL. Чтобы выполнить команду ping, запустите Bash на Ubuntu в Windows от имени администратора или выполните bash.exe из командной строки CMD/PowerShell с правами администратора.

Для более поздних версий Windows сборки 14926+права администратора больше не требуются.

Bash висит

Если при работе с bash вы обнаружите, что bash зависает (или заблокирован) и не отвечает на входные данные, помогите нам диагностировать проблему, собрав и сообщив дамп памяти. Обратите внимание, что эти действия завершатся сбоем системы. Не делайте этого, если вам это не удобно, или сохраните свою работу перед выполнением этого.

Сбор дампа памяти

1. Измените тип дампа памяти на "полный дамп памяти". При изменении типа дампа обратите внимание на текущий тип.

2. Используйте шаги и, чтобы настроить сбой с помощью управления клавиатурой.

3. Повторите зависание или взаимоблокировку.

4. Сбой системы с помощью последовательности ключей (2).

5. Система выйдет из строя и соберет дамп памяти.

6. После перезагрузки системы отправьте файл memory.dmp на [email protected]. Расположение файла дампа по умолчанию — %SystemRoot%\memory.dmp или C:\Windows\memory.dmp, если C: является системным диском. В электронном письме обратите внимание, что дамп предназначен для команды WSL или Bash для Windows.

7. Восстановите тип дампа памяти до исходного параметра.

Проверьте номер сборки

Чтобы найти архитектуру компьютера и номер сборки Windows, откройте
Параметры>Система>Информация

Найдите поле сборки ОС и поле системного типа.

Чтобы найти номер сборки Windows Server, выполните следующую команду в PowerShell:

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

Подтверждение включения WSL

Вы можете убедиться, что подсистема Windows для Linux включена, выполнив следующую команду в окне PowerShell с повышенными привилегиями:

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

Проблемы с подключением OpenSSH-Server

При попытке подключиться к серверу SSH возникла ошибка: "Подключение закрыто 127.0.0.1 порт 22".

1. Убедитесь, что запущен сервер OpenSSH:

   sudo service ssh status
   

   и вы последовали за этим руководством: https://ubuntu.com/server/docs/service-openssh

2. Остановите службу sshd и запустите sshd в режиме отладки:

   sudo service ssh stop
   sudo /usr/sbin/sshd -d
   

3. Проверьте журналы запуска и убедитесь, что 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-server.

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

"Не удалось найти указанную сборку". При включении необязательной функции WSL

Эта ошибка связана с плохим состоянием установки. Выполните следующие действия, чтобы попытаться устранить эту проблему:

• Если вы запускаете команду компонента WSL из PowerShell, попробуйте использовать графический интерфейс, открыв меню "Пуск" и выбрав "Включить или отключить компоненты Windows", а затем в списке выберите "Подсистема Windows для Linux", которая установит необязательный компонент.

• Обновите версию Windows, перейдя к параметрам, обновлениям и нажав кнопку "Проверить наличие обновлений"

• Если оба из них не удается, и вам нужно получить доступ к WSL, попробуйте выполнить обновление, переустановив Windows с помощью установочного носителя и выбрав "Сохранить все", чтобы обеспечить сохранение приложений и файлов. Инструкции о том, как это сделать, можно найти на странице по переустановке Windows 10.

Исправлены ошибки разрешений (связанные с SSH)

Если вы видите эту ошибку:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         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

Обратите внимание, что добавление этой команды будет включать метаданные и изменять разрешения на файлы Windows, отображаемые из WSL. Дополнительные сведения см. в разрешения файловой системы.

Не удается удаленно использовать WSL с помощью OpenSSH в Windows

Если вы используете opensh-server в Windows и пытаетесь удаленно получить доступ к WSL, вы увидите эту ошибку:

The file cannot be accessed by the system.

Это известная проблемапри использовании версии WSL из Магазина. Вы можете обойти эту проблему сегодня с помощью WSL 1 или с помощью версии WSL в Windows. Дополнительные сведения см. в https://aka.ms/wslstoreinfo.

Выполнение команд Windows завершается сбоем внутри распределения.

Некоторые дистрибутивы , доступные в Microsoft Store, пока не полностью совместимы с выполнением команд Windows из коробки. Если при запуске команды -bash: powershell.exe: command not found, powershell.exe /c start . или любой другой команды Windows возникает ошибка, можно устранить ее следующими шагами:

1. В дистрибутиве WSL запустите echo $PATH.
   Если это не включает в себя: /mnt/c/Windows/system32, значит что-то переопределяет стандартную переменную PATH.
2. Проверьте параметры профиля с помощью cat /etc/profile.
   Если он содержит назначение переменной PATH, измените файл, чтобы закомментировать блок назначения PATH с помощью символа #.
3. Проверьте, присутствует ли файл wsl.conf cat /etc/wsl.conf и убедитесь, что он не содержит appendWindowsPath=false, в противном случае добавьте комментарий, чтобы исключить его.
4. Перезапустите распределение, введя wsl -t за именем распространения или запустите wsl --shutdown в cmd или PowerShell.

Не удалось загрузить после установки WSL 2

Мы знаем о проблеме, влияющей на пользователей, где они не могут загружаться после установки WSL 2. Пока мы полностью диагностируем эти проблемы, пользователи сообщили, что изменение размера буфера или установка нужных драйверов может помочь их решить. Просмотрите эту проблему GitHub, чтобы просмотреть последние обновления по этой проблеме.

Ошибки WSL 2 при отключении ICS

Совместное использование подключения к Интернету (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 и WSL, например Windows 10 Creators Update (октябрь 2017, сборка 16299) или юбилейное обновление (август 2016 г., сборка 14393). Мы рекомендуем обновиться до последней версии Windows, но если это невозможно, ниже мы изложили некоторые различия.

Различия команд интероперабельности:

• bash.exe заменён на wsl.exe. Команды Linux можно запускать из командной строки Windows или из PowerShell, но для ранних версий Windows может потребоваться использовать команду bash. Например, C:\temp> bash -c "ls -la". Команды WSL, передаваемые в bash -c, перенаправляются в процесс 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 из дистрибутива WSL в более ранней версии Windows 10 необходимо указать путь к каталогу. Например, чтобы вызвать приложение "Блокнот Windows" из командной строки WSL, введите: /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

Если вы изначально установили WSL в версии Windows 10 до обновления Creators (октябрь 2017, сборка 16299), рекомендуется перенести все необходимые файлы, данные и т. д. из установленного дистрибутива Linux в более новый дистрибутив, установленный через Microsoft Store. Чтобы удалить устаревшее распределение с компьютера, выполните следующие действия из командной строки или экземпляра PowerShell: wsl --unregister Legacy. Вы также можете вручную удалить более старое устаревшее распределение, удалив папку %localappdata%\lxss\ (и все это вложенное содержимое) с помощью проводника Windows или PowerShell: rm -Recurse $env:localappdata/lxss/.