Виправити WSL «Запитувана операція вимагає підвищення привілеїв» за 2 хвилини

February 8, 2026 • February 8, 2026 • Читання: 5 хв • Views: 0

Було корисно?

WSL мав би бути найспокійнішою частиною вашого робочого дня в Windows: Linux-термінал, пакунки які встановлюються, диски які монтуються. Потім ви запускаєте безпечну команду — можливо wsl --update, можливо дистрою — і Windows відповідає: «Запитувана операція вимагає підвищення привілеїв.»

Це один із таких повідомлень, які їдять години, бо технічно воно правдиве, але операційно марне. Підвищення для чого? Якого компонента? Якої межі? Трюк у тому, щоб припинити гадати і допитати систему, наче ви на виклику (бо ви на виклику, навіть якщо це просто ваш ноутбук).

Дво-хвилинне виправлення (робіть це першим)

Якщо потрібно відновити працездатність прямо зараз, не починайте з пошуку по реєстру або видалення дистрибутивів. Більшість помилок підвищення походить від одного з трьох: ви працюєте в неправильному контексті оболонки (без прав адміністратора проти з правами), потрібна опційна функція Windows не ввімкнена, або якась служба вмерла.

Хвилина 0–1: запустіть саме ту команду, що падає, як адміністратор (тільки один раз)

Відкрийте підвищений PowerShell або Windows Terminal (Запуск від імені адміністратора), потім перевірте статус WSL.

cr0x@server:~$ wsl --status
Default Distribution: Ubuntu
Default Version: 2
WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.61
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26091.1-240325-1447.ge-release
Windows version: 10.0.22631.3007

Що це означає: Якщо це працює як адміністратор, але не працює як звичайний користувач, то у вас не «проблема WSL». У вас проблема кордонів дозволів. Це можна виправити без перевстановлення нічого.

Рішення: Якщо як адміністратор працює, а як неадмін — ні, переходьте до Де проходить межа підвищення і зверніть особливу увагу на перемикачі функцій, доступ до реєстру Lxss і керування службами.

Хвилина 1–2: перезапустіть «трубопроводи» WSL і спробуйте ще раз

Все ще в підвищеному режимі, виконайте безпечну послідовність скидання. Це не видалить дистрибутиви.

cr0x@server:~$ wsl --shutdown
cr0x@server:~$ net stop LxssManager
The LxssManager service was stopped successfully.

cr0x@server:~$ net start LxssManager
The LxssManager service was started successfully.

cr0x@server:~$ wsl -l -v
  NAME            STATE           VERSION
* Ubuntu          Stopped         2
  Debian          Stopped         2

Що це означає: Ви змусили WSL зупинити всі VMs і перезапустили його сервіс-менеджера. Якщо проблема була у застряглому стані служби — все готово.

Рішення: Якщо виправлено — зупиніться. Не «чистіть» більше, ніж потрібно. Якщо проблема лишається — продовжуйте структуровану діагностику.

Жарт №1: Запити на підвищення в Windows нагадують несподівані наради: технічно виправдані, операційно деструктивні.

Що насправді означає «вимагає підвищення привілеїв» у WSL

WSL — це не одна програма; це ланцюг компонентів, що перетинають щонайменше три межі безпеки:

Токен вашого користувача (звичайний користувач проти адміністратора, фільтрація UAC, групові політики)
Служби та драйвери Windows (LxssManager, стек Hyper-V, віртуальні мережі)
Гостьова Linux (root проти user, права монтування та метадані файлової системи дистрибутива)

Це повідомлення зазвичай походить від Windows, а не від Linux. Windows каже: «Я збираюся змінити стан системи або привілейований ресурс, і вам не дозволено це робити з цього контексту.» У WSL «системний стан» може означати:

Встановлення/оновлення ядра WSL або пакета WSL
Увімкнення опційних функцій Windows (WSL, VirtualMachinePlatform, компоненти Hyper-V)
Реєстрація/видалення дистрибутивів (запис під керовані системою ключі реєстру)
Маніпуляції службами (запуск/зупинка LxssManager або служб, пов’язаних з Hyper-V)
Монтування певних пристроїв або налаштування дзеркальної мережі

Ключовий операційний момент: не сприймайте «вимагає підвищення» як «виконуй усе завжди від імені адміністратора». Це шлях до крихкого робочого середовища, де випадковий скрипт може зіпсувати ваш день. Використовуйте права адміністратора для одноразових системних змін, потім повертайтеся до звичайного користувача для щоденної роботи.

Швидкий план діагностики (перший/другий/третій)

Коли ви дебажите під тиском часу, вам потрібен найшвидший шлях до реального блокатора. Ось план для роботи на виклику.

Перший крок: визначте, яка операція просить підвищення

Якщо це wsl --install, wsl --update або увімкнення функцій: це системна зміна.
Якщо це запуск дистрибутива: зазвичай це LxssManager/служба/реєстрація, іноді політика файлової системи/монтування.
Якщо це wsl --mount або все, що стосується дисків: це часто доступ до сховища, що вимагає прав адміністратора.

Другий крок: перевірте стан менеджера WSL і стеку віртуалізації

Чи працює служба LxssManager?
Чи ввімкнені необхідні опційні функції Windows?
Чи доступний гіпервізор і чи його не блокує політика?

Третій крок: перевірте проблеми контексту користувача (підступні)

Ви в групі «Адміністратори», але працюєте з відфільтрованим токеном через UAC? (Поширено.)
Корпоративні контролі (AppLocker/WDAC, захист кінцевої точки, GPO) блокують допоміжні бінарники?
Windows Terminal запускає WSL у контексті, відмінному від вашої звичайної оболонки?

Якщо слідувати цьому порядку, ви уникнете класичної пастки: «Я перевстановив Ubuntu тричі — нічого не допомогло.» Перевстановлення дистрибутива рідко вирішує проблему межі привілеїв Windows.

Практичні завдання: команди, виводи та рішення

Ви просили реальні завдання з командами, інтерпретацією виводів і рішеннями. Ось більше десятка. Використовуйте їх як чекліст, а не як «вибирай-свою-пригоду».

Завдання 1: відтворіть помилку в чистому контексті оболонки

Запустіть точну операцію з PowerShell (не всередині WSL), щоб побачити, чи помилка походить від Windows або Linux.

cr0x@server:~$ wsl -l -v
  NAME            STATE           VERSION
* Ubuntu          Running         2

Що це означає: Якщо ця команда сама видає «вимагає підвищення», проблема на боці керування WSL у Windows, а не всередині дистрибутива.

Рішення: Якщо команди Windows не працюють, зосередьтеся на службах/функціях/політиці. Якщо команди Windows працюють, але Linux-операції падають — перемкніться на монтування та права Linux.

Завдання 2: перевірте, чи випадково ви використовуєте невисокий токен

З PowerShell можна виявити, чи процес підвищений, спробувавши операцію тільки для адміністратора, наприклад читання конфігурації служби. Невисокий шел зазвичай повертає Access is denied.

cr0x@server:~$ sc.exe qc LxssManager
[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: LxssManager
        TYPE               : 20  WIN32_SHARE_PROCESS
        START_TYPE         : 3   DEMAND_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\WINDOWS\System32\svchost.exe -k LxssManager
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : LxssManager
        DEPENDENCIES       :
        SERVICE_START_NAME : LocalSystem

Що це означає: Успіх підказує, що у вас ймовірно достатньо прав у цій оболонці. Якщо ви бачите «Access is denied», ви не маєте підвищених прав.

Рішення: Якщо ви не підвищені, підвищте лише для конкретної системної зміни. Не «виправляйте» WSL, живучи постійно в адмін-терміналах.

Завдання 3: перевірте стан служби LxssManager

cr0x@server:~$ sc.exe query LxssManager
SERVICE_NAME: LxssManager
        TYPE               : 20  WIN32_SHARE_PROCESS
        STATE              : 4  RUNNING
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

Що це означає: RUNNING — це добре. STOPPED або START_PENDING з помилками натякає на збій служби або проблему з залежностями/політикою.

Рішення: Якщо не RUNNING — запустіть її (Завдання 4). Якщо не стартує — переключайтеся на перевірку функцій і журнал подій.

Завдання 4: перезапустіть службу по-простому

cr0x@server:~$ net stop LxssManager
The LxssManager service was stopped successfully.

cr0x@server:~$ net start LxssManager
The LxssManager service was started successfully.

Що це означає: Якщо stop/start вдається, але WSL усе одно падає — проблема не в «застряглій службі». Шукайте далі.

Рішення: Продовжуйте перевірку функцій і валідацію движка WSL.

Завдання 5: перевірте опційні функції Windows, потрібні WSL

Для WSL2 зазвичай потрібні WSL + VirtualMachinePlatform. Hyper-V може бути опційним залежно від редакції/конфігурації, але VirtualMachinePlatform — зазвичай головний блокер.

cr0x@server:~$ dism.exe /online /get-features /format:table | findstr /i "Microsoft-Windows-Subsystem-Linux VirtualMachinePlatform Hyper-V"
Microsoft-Windows-Subsystem-Linux         | Enabled
VirtualMachinePlatform                    | Enabled
Hyper-V                                   | Disabled

Що це означає: Якщо WSL або VirtualMachinePlatform Disabled, спроби встановити/оновити/зареєструвати можуть викликати запит на підвищення або дивні відмови.

Рішення: Якщо Disabled — увімкніть їх (Завдання 6) в підвищеному шеллі, потім перезавантажте.

Завдання 6: увімкніть потрібні функції (для цього потрібні права)

cr0x@server:~$ dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

Enabling feature(s)
[==========================100.0%==========================]
The operation completed successfully.

cr0x@server:~$ dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

Enabling feature(s)
[==========================100.0%==========================]
The operation completed successfully.

Що це означає: Якщо ви не могли виконати це без підвищення — це нормально. Це одноразове налаштування.

Рішення: Перезавантажте. Потім спробуйте WSL у не підвищеному терміналі.

Завдання 7: підтвердьте, що гіпервізор доступний

cr0x@server:~$ systeminfo.exe | findstr /i "Hyper-V Requirements"
Hyper-V Requirements:      VM Monitor Mode Extensions: Yes
                           Virtualization Enabled In Firmware: Yes
                           Second Level Address Translation: Yes
                           Data Execution Prevention Available: Yes

Що це означає: Якщо віртуалізація відключена у прошивці, WSL2 спрацює з багатьма помилками, які іноді виглядають як проблеми привілеїв або ініціалізації.

Рішення: Якщо «Virtualization Enabled In Firmware: No» — виправте налаштування BIOS/UEFI. Не намагайтеся «заставити» Windows мати VT-x/AMD-V без підтримки апаратного забезпечення.

Завдання 8: перевірте версію WSL і стан ядра

cr0x@server:~$ wsl --version
WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.61
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26091.1-240325-1447.ge-release
Windows version: 10.0.22631.3007

Що це означає: Якщо wsl --version видає помилку підвищення, механізм встановлення/оновлення WSL може бути обмежений політикою або ви використовуєте збірку Windows, де WSL керується інакше.

Рішення: Якщо ви не можете запросити версію без прав адміністратора, підозрюйте інструменти захисту кінцевої точки або політику, яка контролює бінарні файли WSL або компоненти, що доставляються через магазин.

Завдання 9: перелічіть дистрибутиви і виявте аномалії реєстрації

cr0x@server:~$ wsl -l -v
  NAME            STATE           VERSION
* Ubuntu          Running         2
  Debian          Stopped         2

Що це означає: Якщо список порожній або перелік вимагає підвищення, доступ до реєстру для реєстрацій дистрибутивів може бути заблокований.

Рішення: Якщо перелік працює, але запуск падає — зосередьтеся на конкретному дистрибутиві (пошкодження файлової системи, відображення користувача, монтування). Якщо перелік не працює — фокус на контролі з боку Windows та реєстрі Lxss.

Завдання 10: вивантажте конфігурацію WSL і знайдіть шкідливі налаштування

Файл %UserProfile%\.wslconfig може впливати на налаштування VM (пам’ять, мережеві режими). Погана конфігурація може спричинити відмови під час запуску, що виглядають не пов’язаними.

cr0x@server:~$ type %UserProfile%\.wslconfig
[wsl2]
memory=2GB
processors=2
swap=0
localhostForwarding=true

Що це означає: Налаштування swap=0 і мала пам’ять можуть змусити важкі дистрибутиви падати при завантаженні або під час операцій з пакетами, але зазвичай це проявляється як час очікування або OOM — не підвищення. Проте добре знати, що запущено.

Рішення: Якщо ви бачите агресивне тонке налаштування — тимчасово поверніть за замовчуванням, перейменувавши файл, потім wsl --shutdown і повторіть спробу.

Завдання 11: спробуйте чистий запуск конкретного дистрибутива

cr0x@server:~$ wsl -d Ubuntu -- uname -a
Linux cr0x 5.15.146.1-microsoft-standard-WSL2 #1 SMP Tue Oct 10 10:00:00 UTC 2023 x86_64 GNU/Linux

Що це означає: Якщо запуск з тривіальною командою працює, ядро й базовий запуск в порядку. Ваше повідомлення про підвищення пов’язане зі специфічною дією (монтаж дискiв, оновлення ядра, імпорт/експорт або зміни мережі Windows).

Рішення: Зменшіть сферу — не «виправляйте WSL», виправляйте конкретну операцію.

Завдання 12: діагностуйте проблеми з монтуванням (DrvFs та automount)

Якщо помилка з’являється при доступі до /mnt/c або при монтуванні диска — ви у сфері сховища. Перевірте налаштування automount всередині дистрибутива.

cr0x@server:~$ wsl -d Ubuntu -- cat /etc/wsl.conf
[automount]
enabled=true
options="metadata,umask=22,fmask=11"
mountFsTab=true

Що це означає: Це впливає на спосіб представлення дисків Windows. Деякі середовища жорстко обмежують доступ до дисків або вимагають прав адміністратора для певних операцій з пристроями.

Рішення: Якщо проблема виникає на монтуванні — протестуйте з вимкненим automount, щоб ізолювати проблему:

cr0x@server:~$ wsl -d Ubuntu -- sh -lc "printf '[automount]\nenabled=false\n' | sudo tee /etc/wsl.conf"
[automount]
enabled=false

Потім wsl --shutdown і перезапустіть. Якщо помилка зникла — винуватець політика монтування або конкретний запис у fstab.

Завдання 13: перевірте fstab на монтування, що вимагає привілеїв

cr0x@server:~$ wsl -d Ubuntu -- cat /etc/fstab
C:\data  /data  drvfs  metadata,uid=1000,gid=1000,umask=022  0  0

Що це означає: Таке користувацьке монтування може падати під певними політиками безпеки Windows, особливо якщо шлях вказує на захищені локації.

Рішення: Тимчасово закоментуйте нефундаментальні монтування; якщо WSL запускається — додавайте монтування по одному та переміщайте дані в менш захищений шлях.

Завдання 14: перевірте, що файлову систему дистрибутива можна читати

Дистрибутиви WSL живуть під профілем користувача (зазвичай). Якщо продукт безпеки помістив VHDX під карантин або заблокував його, WSL починає падати з дивними помилками.

cr0x@server:~$ dir "%LocalAppData%\Packages" | findstr /i "Ubuntu"
d-----         12/10/2025  09:14 AM                CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc

Що це означає: Якщо директорія пакетів відсутня або недоступна, реєстрація дистрибутива може бути пошкоджена або заблокована.

Рішення: Якщо вона несподівано відсутня — не поспішайте перевстановлювати. Спочатку перевірте журнали безпеки/карантину і переконайтеся, що профіль не перенесений в мережевий шлях з дивними ACL.

Завдання 15: збирайте докази у подіях (бо гадання — не стратегія)

Помилки WSL і збої служб часто лишають сліди в журналах подій Windows. Запитайте останні помилки.

cr0x@server:~$ wevtutil qe Microsoft-Windows-Lxss/Operational /c:10 /rd:true /f:text
Event[0]:
  Log Name: Microsoft-Windows-Lxss/Operational
  Source: Microsoft-Windows-Lxss
  Date: 2026-02-05T08:12:44.123
  Event ID: 1005
  Task: None
  Level: Error
  Opcode: Info
  Keyword: Classic
  User: S-1-5-21-...
  Computer: WORKSTATION-17
  Description:
  Failed to start a WSL2 instance. HRESULT: 0x80070005

Що це означає: 0x80070005 — доступ заборонено — часто це підґрунтя для користувацького повідомлення «вимагає підвищення».

Рішення: Access denied вказує на проблему з дозволами/політикою, а не на «пошкоджений Ubuntu». Визначте, який ресурс заблоковано.

Завдання 16: перевірте, чи корпоративне посилення не блокує допоміжні бінарні файли

Деякі організації забороняють виконання з WindowsApps або блокують пакунки магазину. Переконайтеся, що шлях до бінарника WSL резольвиться і виконується.

cr0x@server:~$ where wsl
C:\Windows\System32\wsl.exe

Що це означає: Якщо wsl.exe не знайдено або він вказує на дивний шлях — у вас може бути хаос у PATH або сварка політик виконання.

Рішення: Виправте проблеми PATH першочергово; ви не зможете дебажити WSL, якщо фактично не запускаєте WSL.

Де проходить межа підвищення: поширені режими відмов

«Вимагає підвищення» — це симптом. Ось реальні категорії, які я бачив на корпоративних ноутбуках і робочих станціях розробників.

1) Увімкнення функцій: передумови WSL2 не були встановлені з правами адміністратора

Якщо ви намагалися налаштувати WSL без прав адміністратора, Windows дозволить вам зробити лише половину роботи: ви можете встановити дистрибутив, але віртуалізаційні компоненти не активні. Пізніше команда викликає перемикач функції або завантаження драйвера — і бах — запит на підвищення або відмова.

Виправлення: Увімкніть опційні функції в підвищеному шеллі (Завдання 6), перезавантажтеся, потім продовжуйте як звичайний користувач.

2) Керування службами: ви намагаєтеся стартувати/зупиняти служби як звичайний користувач

Запуск або переналаштування служб Windows зазвичай вимагає адміністратора. Деякі операції обслуговування WSL внутрішньо торкаються LxssManager або обчислювального стеку віртуалізації.

Виправлення: Використовуйте підвищений шелл для дій зі службами (Завдання 4), потім поверніться до звичайного користувача.

3) Реєстрація дистрибутивів: ключі реєстру заблоковані політикою

WSL зберігає реєстрації дистрибутивів у конфігурації під контролем Windows. Деякі корпоративні політики агресивно блокують ділянки реєстру. Якщо у вашій організації «безпека через незручність», WSL може стати побічною жертвою.

Виправлення: Ймовірно, потрібні зміни політики IT або затверджені шляхи установки. Тимчасово використовуйте метод інсталяції в межах користувача, якщо середовище це дозволяє.

4) Операції зі сховищем: приєднання/монтування дисків привілейоване

wsl --mount приєднує фізичний диск до VM WSL2. Windows трактує доступ до raw-дисків як привілейований. На те є вагомі причини — це не баг.

Виправлення: Виконуйте операції монтажу в підвищеному шеллі. Якщо це неприйнятно, не покладайтеся на raw disk attach — використовуйте файлові робочі процеси, мережеві шари або VHDX, які змонтував затверджений метод.

5) Зміни режиму мережі: дзеркальні/bridged налаштування можуть вимагати прав або винятків політики

Мережа WSL2 — це шарований пиріг: віртуальні свічі, NAT, правила брандмауера і іноді «дзеркальний» режим. Деякі зміни вимагають підвищених прав або блокуються інструментами безпеки.

Виправлення: Поверніть стандартні мережеві налаштування, перезапустіть WSL, потім перевірте зв’язність. Ескалюйте до власників політики, якщо інструменти блокують операції з віртуальними NIC.

6) Змішуєте версії WSL і очікування

WSL1 — це трансляція системних викликів без VM; WSL2 — повноцінне ядро Linux у легкій VM. Люди думають «WSL — це WSL», потім роблять те, що існує лише в одному режимі, і невірно тлумачать помилку.

Виправлення: Підтвердіть версію дистрибутива (Завдання 9) і за потреби встановіть її явно.

Три корпоративні історії з практики

Історія 1: інцидент через неправильне припущення

В одній середній SaaS-компанії команда стандартизувала ноутбуки Windows з WSL2 для локальної розробки. Все було здебільшого добре — поки не вийшла нова політика посилення безпеки. Політика звузила використання локального адміністратора і заблокувала певні операції з керування службами для непідвищених користувачів.

Один інженер отримав «Запитувана операція вимагає підвищення» при запуску WSL після перезавантаження. Він припустив, що дистрибутив зіпсувався, бо помилка з’явилася одразу після apt upgrade напередодні. Розумне припущення. Помилкове.

Він перевстановив Ubuntu, імпортував проєкт, згенерував SSH-ключі і витратив півдня. Помилка лишилася. Тепер він був злий і непродуктивний, але принаймні мав свіжі ключі.

Що насправді сталося: політика посилення заборонила запуск служби LxssManager у очікуваному для WSL вигляді під контекстом звичайного користувача; виправлення полягало в тому, щоб один раз запустити LxssManager у підвищеному шеллі і знову ввімкнути потрібну опційну функцію, яку політика вимкнула.

Постмортем був короткий і болючий. Висновок не в «ненадійності WSL». Висновок: не звинувачуйте Linux за помилки дозволів Windows і не перевстановлюйте ПЗ, поки не перевірили служби та функції.

Історія 2: оптимізація, яка обернулася проти

Інша компанія захопилася «ускоренням» WSL. Хтось підкинув внутрішні поради: вимкнути swap, обмежити пам’ять і перемістити артефакти збірки в захищену корпоративну папку, яку синхронізував ентерпрайз-агент резервного копіювання. Ідея — прискорити IO і зберегти дані в безпеці.

Тиждень працювало — доки один розробник не використав інструмент, який викликав операції файлової системи на боці Windows під час старту WSL, включаючи монтування і сканування. Раптом WSL почав запускатися нестабільно, і деякі бачили «вимагає підвищення».

Комбінація була токсичною: захищена папка мала агресивні ACL, агент резервного копіювання тримав блокування, а малий обсяг пам’яті робив таймінги старту суворішими, що виявило гонки між VM WSL і провайдером файлової системи Windows.

Виправлення не було героїчним: відкотити «тонкі» налаштування, тримати код у звичайних шляхах користувача і припинити ігнорувати агенти резервного копіювання. Вони не невидимі — вони «біля ядра» і поводяться як діти з фломастерами.

Урок: тонке налаштування продуктивності без розуміння меж створює відмови, які виглядають як проблеми з дозволами, бо на рівні ОС це саме так — блоковані операції.

Історія 3: нудна, але правильна практика, яка врятувала день

У регульованому підприємстві була політика: на кожній машині розробника зберігався невеликий «діагностичний пакет» у внутрішньому репозиторії. Він нічого не виправляв автоматично. Просто збирав стан: статус WSL, увімкнені функції, стани служб, останні події Lxss та вміст .wslconfig.

Одного ранку кілька розробників повідомили, що WSL не стартує і виводить помилки підвищення. Підтримка могла б витратити день на перемикання питань. Натомість попросили діагностичний вивід з трьох машин.

Пакет показав закономірність: VirtualMachinePlatform була вимкнена після циклу оновлень на уражених хостах, а журнал Lxss показував access denied під час створення інстансу. Виправлення було контрольованим: увімкнути функцію з правами адміністратора, перезавантажити, перевірити wsl --status.

Жодних перевстановлень. Жодного ритуального дебагу. Просто докази, потім дія.

Це було нудно. Але це врятувало день. Нудне — це фіча в операціях.

Поширені помилки (симптом → причина → виправлення)

Тут більшість людей витрачає час. Симптоми розмиті. Причини — ні.

1) Симптом: `wsl --install` падає з «вимагає підвищення»

Причина: Встановлення WSL змінює системні компоненти і вимагає адміністратора.

Виправлення: Запустіть інсталяцію з підвищеного терміналу. Якщо ви не можете підвищити (корпоративна машина) — зверніться в IT, щоб увімкнули функції або надали затверджений процес.

2) Симптом: WSL працював вчора; сьогодні запуск дистрибутива вимагає підвищення

Причина: Оновлення Windows, політика безпеки або зміна налаштувань віртуалізації. Часто VirtualMachinePlatform відключили або LxssManager не стартує коректно.

Виправлення: Перевірте функції (Завдання 5), перезапустіть служби (Завдання 4), перегляньте події Lxss (Завдання 15).

3) Симптом: `wsl -l -v` падає з підвищенням, але ви «адміністратор»

Причина: Фільтрований токен UAC: перебування в групі Administrators не означає, що процес зараз підвищений.

Виправлення: Відкрийте Windows Terminal «Запуск від імені адміністратора» для одноразового ремонту. Потім працюйте без підвищення для щоденних задач.

4) Симптом: помилка виникає лише при `wsl --update`

Причина: Оновлення компонентів WSL може вимагати прав адміністратора залежно від способу встановлення і політик (системний компонент проти пакованого застосунку), плюс політика може блокувати оновлення.

Виправлення: Запустіть оновлення один раз як адміністратор. Якщо блокує політика — координуйтеся з власниками політик; не повторюйте спроби без потреби — деякі інструменти безпеки трактують повтори як підозрілу активність.

5) Симптом: помилка підвищення при `wsl --mount`

Причина: Операції з raw-дисками привілейовані у Windows.

Виправлення: Виконуйте wsl --mount у підвищеному шеллі. Якщо не можна — змініть дизайн: використовуйте копії файлів, мережеві шари або VHDX, дозволені у вашому середовищі.

6) Симптом: WSL стартує, але доступ до `/mnt/c` викликає помилки або дивні підказки про права

Причина: Параметри монтування DrvFs, корпоративний захист папок або записи fstab, що вказують на захищені локації.

Виправлення: Перегляньте /etc/wsl.conf і /etc/fstab (Завдання 12 і 13). Перенесіть проєкти в звичайні користувацькі каталоги і уникайте «захищених» коренів синхронізації для дерев збірки.

7) Симптом: лише профіль Windows Terminal падає; PowerShell працює

Причина: Профіль терміналу запускається з іншого каталогу старту, аргументів або налаштувань підвищення; іноді він намагається стартувати в захищеній папці.

Виправлення: Тестуйте з простого PowerShell, потім налаштуйте профіль Terminal, щоб він стартував у доступному для користувача каталозі і без спеціальних аргументів запуску.

8) Симптом: після зміни `.wslconfig` WSL почав падати і помилки стали вводити в оману

Причина: Нестача ресурсів і відмови під час завантаження можуть спливати як загальні помилки запуску.

Виправлення: Видаліть .wslconfig, виконайте wsl --shutdown, повторіть спробу. Поверніть налаштування поступово.

Перевірочні списки / поетапний план

Чекліст A: «Зробити працювати прямо зараз» (2–10 хвилин)

Запустіть аварійну команду в підвищеному терміналі один раз.
Виконайте wsl --shutdown.
Перезапустіть LxssManager (Завдання 4).
Перевірте, що функції увімкнені (Завдання 5).
Перезавантажте, якщо ввімкнули функції.
Спробуйте wsl -l -v без підвищення.
Запустіть дистрибутив з мінімальною командою (Завдання 11).

Чекліст B: «Знайти реальну причину, щоб не поверталося» (15–45 хвилин)

Зберіть події Lxss Operational (Завдання 15) і шукайте access denied коди на кшталт 0x80070005.
Підтвердіть Hyper-V вимоги systeminfo (Завдання 7), щоб виключити проблеми прошивки/віртуалізації.
Перевірте .wslconfig на агресивне тонке налаштування (Завдання 10).
Перевірте /etc/wsl.conf і /etc/fstab на монтування в захищені Windows-шляхи (Завдання 12, 13).
Переконайтесь, що шлях пакета дистрибутива існує (Завдання 14) і не знаходиться в незвичному перенаправленому профілі.
Перевірте, що ви справді використовуєте WSL2 навмисно і послідовно (Завдання 9), а не перескакуєте між WSL1 і WSL2 через чутки про швидкість.

Чекліст C: «Корпоративний санітарний стан» (коли ви не керуєте машиною)

Визначте, чи взагалі можете запускати підвищення (поведінка із Завдання 2).
Якщо не можете підвищити: припиніть пробувати випадкові фікси. Зберіть докази (Завдання 15) і подайте запит.
Запитайте прямо, чи дозволяють опційні функції WSL і чи дозволено приєднання raw-дисків (wsl --mount).
Уточніть, чи обмежено виконання додатків з системних локацій (Завдання 16).

Цікаві факти та контекст (щоб це мало сенс)

WSL1 і WSL2 — принципово різні сутності: WSL1 транслює системні виклики; WSL2 запускає реальне ядро Linux у легкій VM. Різні режими відмов, різні межі привілеїв.
Файлова система WSL2 зазвичай — VHDX: «диск» вашого дистрибутива — це віртуальний жорсткий диск-файл під профілем користувача. Блокування/карантин можуть його зламати.
LxssManager — регулювальник руху: він координує запуск/зупинку інстансів і взаємодію зі стеком VM. Якщо він вниз — WSL здебільшого лише театральна постановка.
Опційні функції Windows — це реальні компоненти ОС: увімкнення WSL і VirtualMachinePlatform ближче до «встановлення підсистеми», ніж до «встановлення програми», звідси й вимога прав.
UAC означає, що «адмін» — це режим, а не ідентичність: багато користувачів у групі Administrators запускають більшість процесів з фільтрованим токеном. Це зроблено навмисно.
DrvFs — це шар трансляції: доступ до файлів Windows з Linux включає відображення семантик і ACL. Можна зробити зручніше з опціями metadata, але це також джерело плутанини.
Доступ до raw-дисків навмисно привілейований: wsl --mount може відкрити блочні пристрої. Windows не видає це непривілейованим процесам так само, як не дає «формат C:» купони.
WSLg змінив очікування: підтримка GUI зробила WSL відчутним як десктопне середовище, але це все ще покладається на служби, драйвери та віртуалізацію. Коли вони блокуються — UX лишається нечітким.
Інструменти корпоративної безпеки люблять хуки біля ядра: вони можуть заважати віртуалізації й віртуалізації файлової системи. Результат часто виглядає як випадкові помилки доступу.

Жарт №2: «Просто запустіть як адміністратор» — це ІТ-еквівалент «ви пробували вимкнути й увімкнути знову», тільки може ще й зруйнувати вашу безпеку.

FAQ

1) Чому WSL каже «Запитувана операція вимагає підвищення привілеїв», якщо я вже адміністратор?

Через UAC. Ваш обліковий запис може належати до групи Administrators, але поточний процес терміналу працює з нефільтрованим токеном. Підвищте процес терміналу для однієї операції, яка цього потребує.

2) Чи безпечно запускати WSL постійно як Адміністратор?

Ні. Це розширює зону ураження: скрипти, установки пакетів і інструменти отримують системний вплив. Використовуйте права адміністратора лише для ввімкнення функцій, оновлення системних компонентів або привілейованих монтувань.

3) Які команди WSL зазвичай вимагають підвищення?

Увімкнення функцій (dism), деякі шляхи встановлення/оновлення (wsl --install, wsl --update залежно від налаштування), операції зі службами та приєднання дисків (wsl --mount).

4) Чому помилка з’являється тільки на моєму корпоративному ноутбуку?

Групові політики, інструменти захисту кінцевої точки й контроль виконання можуть блокувати віртуалізацію, керування службами, записи реєстру або виконання допоміжних компонентів. Зберіть журнали подій (Завдання 15) і стани функцій (Завдання 5) і покажіть їх в IT.

5) Чи вирішить переключення дистрибутива на WSL1 помилки підвищення?

Іноді це оминає блокери віртуалізації, але це компроміс: WSL1 має іншу поведінку файлової системи і ядра. Не використовуйте це як «виправлення», якщо ви не розумієте вплив на сумісність і продуктивність для вашої роботи.

6) Я отримую помилки підвищення при доступі до Windows-файлів з WSL. Що відбувається?

Зазвичай ви торкаєтеся захищених шляхів Windows, контрольованих папок або директорій під управлінням безпеки. Перевірте /etc/fstab і місце розташування Windows-папки. Розміщуйте проєкти в звичайному каталозі користувача й уникайте «захищених» коренів синхронізації для дерев збірки.

7) Чи допоможе перевстановлення Linux-дистрибутива?

Рідко. Якщо помилка походить від операцій на боці Windows (служби, функції, реєстр, монтування), перевстановлення Ubuntu дає вам лише свіжу Ubuntu, яка все одно не зможе стартувати.

8) Чи можна виправити це без перезавантаження?

Інколи, якщо це просто застрягла служба: wsl --shutdown і перезапустіть LxssManager. Але якщо ви ввімкнули опційні функції — краще перезавантажити. Windows не театрує; вона переналаштовує ОС.

9) Що означає HRESULT 0x80070005 у журналі Lxss?

Доступ заборонено. Це основна причина багатьох відмов із повідомленням «вимагає підвищення». Наступний крок — визначити, який ресурс блокується: функція, служба, реєстр, файлову систему або політика.

10) Як уберегтися від цього після оновлень Windows?

Тримайте невелику діагностичну рутину: перевіряйте стани функцій, статус WSL і останні події Lxss після циклів оновлень. Якщо ви в корпоративному середовищі — домагайтеся підтримуваного базового образу, де ці функції не вимикаються політиками посилення.

Висновок: що робити далі

«Запитувана операція вимагає підвищення привілеїв» — це не якась таємнича кара WSL. Це Windows, що повідомляє про перетин межі привілеїв. Ставтеся до цього як до операційної задачі: визначте межу, зберіть докази, застосуйте мінімальну привілейовану зміну і поверніться до звичайної роботи.

Наступні кроки, які справді працюють:

Зробіть дво-хвилинне виправлення: підвищений wsl --status, потім wsl --shutdown і перезапуск LxssManager.
Якщо лишається, перевірте стани функцій за допомогою DISM і перезавантажте після змін.
Завантажте журнал Lxss Operational і шукайте деталі про access denied.
Якщо тригер пов’язаний зі сховищем — прийміть, що wsl --mount привілейований, і спроектуйте робочі процеси відповідно.

Надія — не стратегія. — James Greene