wsl.conf nie jest respektowany

Plik wsl.conf nierespektowany przez dystrybucję oznacza, że zmiany wymagają pełnego restartu podsystemu (`wsl --shutdown`), ponieważ ustawienia są wczytywane tylko przy starcie dystrybucji, nie na żywo.

Wsl.conf nie jest respektowany – co oznacza ten problem

Komunikat lub obserwacja, że plik /etc/wsl.conf nie jest respektowany, oznacza rozbieżność między ustawieniami zapisanymi w konfiguracji dystrybucji WSL a rzeczywistym zachowaniem uruchomionego środowiska Linux. Plik ten steruje wybranymi właściwościami dystrybucji, między innymi sposobem montowania dysków Windows, ustawieniami automatycznego montowania, konfiguracją sieciową, użytkownikiem domyślnym oraz uruchamianiem określonych mechanizmów startowych. Nie jest to jednak konfiguracja odczytywana przy każdej zmianie polecenia lub przy każdym otwarciu nowej powłoki.

Najczęściej zmiana zostaje zapisana poprawnie, ale działająca instancja dystrybucji nadal korzysta z wartości odczytanych podczas wcześniejszego uruchomienia. Z tego powodu samo zamknięcie okna terminala może nie wystarczyć. Procesy dystrybucji WSL mogą nadal pozostawać aktywne w tle, a wtedy ponowne otwarcie terminala nie powoduje pełnego ponownego wczytania ustawień. Konfiguracja może więc wyglądać poprawnie w pliku, mimo że jej efekt nie jest jeszcze widoczny.

Istotne jest także odróżnienie pliku /etc/wsl.conf od ustawień globalnych zapisanych w pliku .wslconfig w profilu użytkownika systemu Windows. Pierwszy z nich dotyczy konkretnej dystrybucji, natomiast drugi odnosi się do wybranych parametrów całego środowiska WSL. Umieszczenie wpisu w niewłaściwym pliku, zapisanie go poza właściwą dystrybucją albo użycie nieprawidłowej składni może sprawić wrażenie, że konfiguracja jest ignorowana.

Dlaczego ustawienia WSL nie działają od razu

Wsl.conf jest plikiem inicjalizacyjnym, a nie mechanizmem przeładowywanym dynamicznie. Po jego edycji należy zakończyć działanie dystrybucji, a następnie zatrzymać całe środowisko WSL poleceniem wsl --shutdown uruchomionym w systemie Windows. Dopiero ponowne uruchomienie dystrybucji pozwala odczytać zmienione wartości. W praktyce kolejność może wyglądać następująco:

1. sprawdzenie, czy edytowany jest plik /etc/wsl.conf w tej dystrybucji, której dotyczy problem;
2. zapisanie pliku w prawidłowym kodowaniu i z poprawną składnią INI;
3. zamknięcie procesów korzystających z dystrybucji;
4. wykonanie polecenia wsl --shutdown w PowerShellu lub wierszu polecenia systemu Windows;
5. ponowne uruchomienie właściwej dystrybucji i sprawdzenie rezultatu.

Nie każda zmiana w pliku wpływa na ten sam element systemu. Parametr dotyczący montowania może zmienić sposób pojawiania się dysków, ale nie naprawi problemu z nazwą dystrybucji, integracją z terminalem ani z samą instalacją WSL. Podobnie wpis odnoszący się do użytkownika domyślnego nie zmienia kont już uruchomionych w istniejących procesach. Weryfikacja powinna dlatego obejmować zarówno treść pliku, jak i dokładny obszar działania danego ustawienia.

Warto również sprawdzić, czy plik nie został zapisany z dodatkowymi znakami, rozszerzeniem utworzonym przez edytor Windows albo błędnymi nagłówkami sekcji. Typowa składnia wymaga użycia sekcji w nawiasach kwadratowych, na przykład [automount], [network] lub [user], oraz wpisów w formacie klucz=wartość. Błąd literowy w nazwie klucza, niewłaściwa wielkość liter tam, gdzie ma znaczenie, albo umieszczenie parametru w nieodpowiedniej sekcji może spowodować pominięcie ustawienia.

Typowe problemy i błędy związane z wsl.conf

Jednym z częstych źródeł nieporozumień jest edycja pliku w innej dystrybucji niż ta, która jest uruchamiana. WSL może zawierać kilka środowisk, a każda z nich ma własny katalog główny i własny plik /etc/wsl.conf. Zmiana wykonana w Ubuntu nie wpłynie na Debian, Kali ani inną zainstalowaną dystrybucję. Przed diagnozą należy ustalić nazwę aktywnego środowiska oraz sprawdzić, czy polecenia są wykonywane w odpowiednim kontekście.

Drugim problemem bywa brak pełnego zatrzymania WSL. Wyłączenie pojedynczego procesu powłoki, zamknięcie karty terminala lub użycie polecenia exit nie zawsze kończy wszystkie procesy dystrybucji. Jeżeli środowisko nadal działa, nowa sesja może zostać dołączona do wcześniej uruchomionej instancji i nadal używać starej konfiguracji. W takiej sytuacji wsl --shutdown jest ważnym etapem testu, a nie jedynie czynnością pomocniczą.

Problemy mogą wynikać także z nieprawidłowych uprawnień do pliku, uszkodzonego systemu plików dystrybucji, błędnych znaków końca linii albo edycji pliku z poziomu narzędzia, które dopisało własne rozszerzenie. Należy sprawdzić, czy polecenie cat /etc/wsl.conf pokazuje dokładnie oczekiwaną zawartość, czy sekcje są zapisane bez literówek oraz czy wartości odpowiadają wersji używanego WSL.

Możliwe jest również pomylenie ograniczeń konfiguracji z błędem samego środowiska. Niektóre ustawienia mają zastosowanie tylko przy określonym trybie uruchamiania, wybranej wersji WSL albo konkretnym sposobie integracji z systemem Windows. Zmiana parametrów nie zawsze cofnie wcześniej utworzone punkty montowania lub zmodyfikuje stan już uruchomionej usługi. Weryfikacja powinna zatem obejmować stan po restarcie, komunikaty diagnostyczne oraz wynik poleceń kontrolnych, a nie tylko samą obecność wpisu w pliku.

Kiedy najlepiej zgłosić sprzęt do serwisu - wsl.conf nie jest respektowany

Zgłoszenie do serwisu jest uzasadnione, gdy po prawidłowej edycji pliku, pełnym zatrzymaniu WSL i ponownym uruchomieniu dystrybucji ustawienia nadal nie daje oczekiwanego efektu. Szczególnej uwagi wymaga sytuacja, w której problem dotyczy kilku dystrybucji, pojawia się po aktualizacji systemu Windows, towarzyszą mu błędy montowania dysków albo środowisko uruchamia się z nieoczekiwanym użytkownikiem. W takich przypadkach potrzebne może być porównanie konfiguracji, logów oraz stanu komponentów WSL.

Przed przekazaniem urządzenia warto przygotować nazwę dystrybucji, treść zmienianego pliku, polecenia użyte do zatrzymania środowiska oraz dokładny opis tego, co miało się zmienić. Ułatwia to odtworzenie problemu i ogranicza ryzyko przypadkowego usunięcia danych z dystrybucji. Nie powinno się też usuwać całego środowiska ani ponownie instalować systemu bez kopii zapasowej, ponieważ taka operacja może doprowadzić do utraty plików przechowywanych w dystrybucji.

W Warszawie takie przypadki można przekazać do Warszawskiego Pogotowia Komputerowego 24/7 pod numerem +48 22 100 48 29. Poza samym plikiem konfiguracyjnym może zostać sprawdzona współpraca WSL z systemem Windows, stan aktualizacji oraz wpływ innych ustawień na uruchamianie dystrybucji. Naprawy są z reguły wykonywane w ciągu 3 dni roboczych, zależnie od wyniku diagnozy i zakresu problemu.