News Windows-Subsystem für Linux: WSL 1.0 als finale Version im Microsoft Store erschienen

[MadCat[me]]

War das nicht über Samba verdängelt im Falle von WSL2?

Wenn ich's richtig im Kopf habe, lief das über einen separaten Dateisystem-Treiber, ähnlich wie es Docker Desktop macht.

Es war jedenfalls unfassbar langsam. Ich hatte testweise ein größeres Java-Projekt unter Windows ausgecheckt und Maven über WSL laufen lassen. Der Build war nach 30 Minuten immer noch nicht fertig, nativ ging das in unter zwei Minuten durch. Selbst mit Docker Desktop unter macOS war das nicht so krass und das war bis vor gut einem Jahr wahrlich keine Rakete ...

So müsste ich das Projekt dann in in der VM auschecken und es läuft dann auch sehr flott, aber es war zumindest damals nicht möglich mit IntelliJ darauf zuzugreifen. Inzwischen geht das wohl, aber nach Aussagen von Kollegen fällt das auch nicht gerade in die Kategorie "it just works". Ich hatte es selbst für andere Projekte immer mal wieder mit VS Code probiert, aber auch das lief nicht reibungslos.

Im Berufsalltag hab ich wirklich keinen Nerv, mich mit sowas rumschlagen zu müssen.

 

[Cornuostium]

Das Problem bei WSL ist, das es im Hintergrund genau wie Hyper-V einen virtuellen Switch anlegt und man dann die gleichen Probleme wie bei anderen VM Lösungen hat. Man muss sich für Bridget-Networking oder NAT entscheiden. Mit den entsprechenden Vor- und Nachteilen. Ich habe es auf meinem Dienstlaptop noch nicht geschafft mit WSL2 ins Internet zu kommen. Per Dienstausweiszertifikat und Pin wird ein VPN zum Firmen-LAN aufgebaut und dann natürlich auch die Gateways und DNS Server vom AG genommen. Das ganze Thema ist bei WSL überhaupt noch nicht implementiert. Genau wie unterschiedliche Paket und Framegrößen zwischen Windows Host und Linux Gast.
Deswegen ist es nice to have, um mal schnell ein Bash-Script zu testen. Aber von Linux-Entwicklung unter Windows zu sprechen, ist dann doch etwas zu hoch gegriffen.

Ich hatte letztens auch Spaß mit WSL2 auf Arbeit. Und auch Probleme mit Docker, Internetverbindung usw. wenn man im Firmen-VPN war. Was da bei mir geholfen hat, war auf jeden Fall, im Linux System die resolv.conf anzupassen, ich meine, die war dort mit dem falschen Wert befüllt. Es kann auch sein, dass man noch zwischen dem VPN und dem WSL Netzwerkadapter ein Forwarding einrichten musste, aber das hab ich zum Teil schon wieder vergessen.

DENN:
WSL funktioniert so lange, so lange man lokal nicht ein verteiltes System testen möchte, da sich alle Distros in WSL den selben Netzwerkadapter und damit die selbe IP teilen. So musste ich letztlich doch wieder auf eine klassische VM Lösung mit VMware wechseln.
Und das (Nicht-)Zusammenspiel mit Cisco AnyConnect - wenn man es nicht aus dem Windows Store installiert bzw. installieren kann - kann einem auch den letzten Nerv rauben und führt zu viel Trial&Error, um dann am Ende doch aufzugeben.

Aber ansonsten ist WSL ganz praktisch 😆

 

[jedi23]

Was ich auch noch nicht ganz raffe, was genau ist eigentlich der Unterschied, wenn ich WSL über die Systemsteuerung (Windows Features hinzufügen) installiere, so wie es ursprünglich nur möglich war? Dann wird das ganze ja über Windows Update aktuell gehalten. Wenn ich jetzt zusätzlich über den Store installiere, kann ich das Windows Feature ja wieder deinstallieren, sonst wäre das doch doppelt gemoppelt, oder?

Also gibt es überhaupt einen Unterschied welchen Installationsweg man jetzt wählt?

 

[Dark Soul]

Als jemand der WSL 1 & 2 seit 2017 fast jeden Arbeitstag verwendet, räume ich hier mal auf - das gebashe ist ja zum Teil schlimm

Zu meinem Hintergrund: Ich entwickle vor allem native C/C++ Applikationen für Embedded Anwendungen (RTOS, Embedded Linux) oder Desktop Systeme (Windows / Linux).

Ab und zu kommen Python Anwendungen, Plots, Backends und Webstuff dazu.

Der Trick ist Docker komplett in der WSL (2) laufen zu lassen. Docker Desktop kannst du in der Pfeife rauchen, nur unter Mac OS ist es noch schlimmer integriert.

Docker Desktop besitzt seit ~ 2 Jahren ein WSL Backend - mit dem läuft es wunderbar. Die alte Windows Integration war "schwierig" - vor allem wenn man Hardware zur Beschleunigung mit OpenCL / CUDA ansprechen wollte. Das geht jetzt alles sehr smooth.

Und was macht das dann besser, als wenn ich eine "echte" VM aufsetze und da die Linux Distri meiner Wahl drin ausführe?
Irgendwie verstehe ich den Sinn davon noch immer nicht.

WSL ist über das Terminal (ab Windows 11 Standard wenn "cmd" ausgeführt wird - in Win10 nachinstallierbar) in Windows integriert. Hier paar Dinge die mir einfallen, welche so nicht mit einer "echten" VM gehen:

- im cmd/powershell

wsl

eintippen, öffnet an der Stelle den jetzigen Folder (cwd) im WSL.

- Umgekehrt öffnet im WSL

cmd.exe

eine Eingabeaufforderung im cwd.

- Filesystem im Windows Explorer öffnen (unabhängig ob man im gemounteten Windows Filesystem ist oder im ext4 von WSL). Einfach mit WSL in einen Ordner navigieren und folgenden Command absetzen:

explorer.exe .

- Umgekehrt kann man im Windows Explorer in der BreadCrumbs Leiste "wsl" eintippen und den jetzigen Folder im WSL Terminal öffnen.

Das sind bisher nur Explorer Tricks um sich noch schneller eine Übersicht zu verschaffen - aber ja, sowas geht mit einer "echten" VM nicht.

Kann Microsoft einmal Produkt-Versionen konsistent benennen. Das ist doch nicht mehr auszuhalten.

Das Projekt an sich hiess schon immer WSL:
WSL Github Releases

WSL1 respektive WSL2 sind die Runtime Versionen welche sich grundlegend in der internen Funktion unterscheiden. Nach einer WSL installation - welche sich mittlerweile kinderleicht im cmd erledigen lässt mit

wsl --install

- kann man die Runtime mit

wsl -l -v

anzeigen.

Wer das 1.0 update holen will kann dies mit

wsl --update

auch sehr einfach erledigen.

Wer noch die WSL1 runtime verwendet, dem empfehle ich auf die WSl2 runtime umzusteigen, Gründe dafür sind:

• Cuda geht endlich
• Grafische Benutzeroberflächen laufen (super wenn man SDL2, gstreamer oder sonst einen X11 Kontext öffnet)
• Filesystemzugriff ist viel schneller
• Das WSL2 backend kann mit allen Linux OS Calls umgehen.

Es gibt aber dennoch Gründe auf dem WSL1 Backend zu bleiben, für mehr Infos:
MS WSL1 vs WSL2 comparison

Na gut, ich war mir sicher, dass Windows mir damals HyperV auch mit WSL1 aufnötigen wollte, aber ist auch Ewigkeiten her

WSL1 brauchte damals kein Hyper-V

Thema Docker: man kann aus WSL heraus sogar auf ein unter Windows laufendes Docker zugreifen, wenn man in den Docker-Einstellungen den entsprechenden Haken setzt.

Genau - wenn man Docker installiert hat auf Windows inklusive WSL backend, so wird einem Docker als Distribution angezeigt (zB. mit dem oben erwähnten List Befehl (wsl -l -v)).

Man sieht diese auch im Windows Explorer:

In diesem Beispiel sind zwei Distributionen installiert - beide nutzen das WSL backend.

Und wenn alles gut geht für Microsoft, wächst die nächste Generation "Ich bin professioneller Webentwickler, ich habe 27 Stunden Berufserfahrung aus zwei Bootcamps!"-Webshits mit WSL auf und versteht gar nicht, was VMs oder Linux sind, und denken sie brauchen für alles Microsoft-Lizenzen. Ob das in der Praxis auch so funktioniert, ist die andere Frage…

Ich sehe du hast einen Hass auf Webentwickler - Danke fürs Mitteilen

Seit es WSL gibt, habe ich jedoch auch keine VM mehr gestartet. Für was auch? Wenn ich volle posix system call compatibilty habe, brauch es das gar nicht mehr.

Ein natives Linux habe ich hingegen ab und zu doch gebootet, denn WSL kann noch nicht alles, zB SD Karten oder externe ext4 Datenträger über USB-C mounten.

Jetzt aber zur Frage, die alle haben die es bis hier hin geschafft haben, wieso WSL? Hier mal meine Liste:

• C/C++ entwickeln in Visual Studio ist immer noch am angenehmsten. Einfach ein Linux Remote Projekt erstellen und man kann loslegen - auch ohne die Hardware, denn GCC / GDB kann man im WSL nutzen Und das egal ob die Target Hardware ARM64 oder sonst eine Architektur hat So kann man Logik bereits lokal testen ohne einen komplizierten Testaufbau.
• SSH & SCP! Statt Putty und WinSCP zu verwenden, kann man wie in Linux gewohnt die Nativen Tools verwenden
• Für Python Entwicklung ist die Windows Welt grauenhaft - schon nur bei Virtuellen Environments / Conda Environments wird da ganz hässlich über den Path getrickst damit was läuft. Das ist im Linux Umfeld eleganter gelöst & man kann Bibliotheken sehr einfach dazu installieren (vor allem Cuda ML Stuff) ohne dass man diese global installieren muss.

Wieso nicht natives Linux?

• Meiner Meinung nach ist die Windows Oberfläche immer noch besser als alles was KDE / Gnome / Unity und Rest bieten.
• Man kann seinen Rechner (vor allem im Homeoffice war dies relevant) am Tag zum Arbeiten und am Abend zum Zocken nutzen.
• Die Office Suite ist, wenn man denn mal Word statt LaTEX verwenden muss, LibreOffice überlegen.

- (Mein ganz persönlicher Grund welchen man nicht auf andere projizieren kann: Ich bin schneller in Windows! Denn wenn mal im Linux etwas nicht geht, und ja GRUB hatte auch schon mal keine Lust, dann verliere ich Zeit für das Troubleshooting, welche mir dann im Projekt fehlt. Ein OS muss eben doch einfach laufen, auch ohne Liebe und die braucht Linux meistens mehr als Windows - vor allem auf einem Notebook )

 

[Sharakea]

Huh? Wieso sollte das Host System auf einmal unter dem Hypervisor laufen der auf dem Host System installiert ist? Ich hab nie mit Hyper-V gearbeitet aber das klingt etwas abenteuerlich 🤔

@Mihawk90
Das ist nicht abenteuerlich sondern normal.
Hyper-V ist ein Type 1 Hypervisor auch wenn dieser erst nachträglich installiert wird über die Windows-Features.

Microsoft Hyper-V Architecture​

Hyper-V is a hypervisor that lets you run several, isolated guest operating systems on a hardware platform. Hyper-V is a Type 1 hypervisor which is installed on bare-metal servers, or on the Windows 10 operating system, but then boots up before the operating system does and runs it as a guest OS. In both cases, Hyper-V interacts directly with the CPU, without going through the host operating system.

Hyper-V creates isolated partitions in which operating systems can operate. There are two types of partitions:

• A root partition that runs Windows and the hypervisor
• Child partitions that can run additional guest operating systems, which do not have direct hardware access. Hyper-V provides the hypercall API, which is used to create child partitions.

 

[bananajoe2k4]

@SVΞN man sollte in der Feature-Tablelle noch aufnehmen, dass WSL2 kein IPv6 kann, WSL1 hingegen schon. Leider hat es Microsoft auch Ende 2022 nicht geschafft, dies in WSL2 zu implementieren.

Siehe hier: https://github.com/microsoft/WSL/discussions/5855

 

[Beelzebot]

@Dark Soul
Die Bilanz liest sich ziemlich vernichtend: Man "braucht" Windows wegen einer schöneren Oberfläche, zum Zocken (nicht mehr) und für Office, in allem anderen ist Linux besser geeignet

PS. Gummiboot statt GRUB nutzen

 

[mibbio]

Genau - wenn man Docker installiert hat auf Windows inklusive WSL backend, so wird einem Docker als Distribution angezeigt

Und der Zugriff darauf ist auf Wunsch eben auch in jede andere installierte WSL Distribution nahtlos integrierbar. Das ist auch ein nennenswerter Unterschied zu Linux in einer "klassischen" VM von VirtualBox oder VMWare. Da dürfte ein VM-übergreifender Zugriff auch schwer bis unmöglich sein. Was aber auch in Ordnung ist, da dort die Isolation der VMs voneinander ja gewollt ist.

Ergänzung (16. November 2022)

SSH & SCP! Statt Putty und WinSCP zu verwenden, kann man wie in Linux gewohnt die Nativen Tools verwenden

Wobei Windows mittlerweile ja auch native Windows-Binaries von OpenSSH mitliefert, so dass man auch ohne Linux/WSL direkt SSH & SCP in der cmd.exe oder Powershell nutzen kann.

 

[Rassnahr]

Ich habe bei meinem Arbeitgeber die Wahl zwischen MacBook und Lenovo mit Windows, hätte aber lieber Linux native (entwickle nur backend Server Anwendungen und noch etwas devops kubernetes ). Wenn die Intel / AMD CPUs mal wieder mit den Apple Mx CPUs mithalten könnten würde ich ggf zu Windows wechseln wegen WSL

 

[Creshal]

@Dark Soul
Die Bilanz liest sich ziemlich vernichtend: Man "braucht" Windows wegen einer schöneren Oberfläche, zum Zocken (nicht mehr) und für Office, in allem anderen ist Linux besser geeignet

PS. Gummiboot statt GRUB nutzen

Buchstäblich alles ist besser als GRUB heutzutage, das schleppen Distros nur noch zur Abwärtskompatibilität mit. Syslinux, systemd-boot, refind, … alles kein Problem.
Und der Rest… lol. Alle meine Spiele laufen flüssig in Proton oder haben native Linux-Ports, die teilweise schneller sind als unter Windows. Und zwischen GDocs, O365 Webapps, Onlyoffice und modernem Libreoffice hab ich auch beruflich seit gut 8 Jahren kein Windows-Office mehr gebraucht.

Einziger Schmerzpunkt zwischendurch: Manche Firmen senden uns Zertifikat-verschlüsselte PDFs, das kann noch immer nur Adobe Reader 9 in WinE brauchbar aufmachen. Aber der läuft auch ohne Probleme.

 

[KitKat::new()]

• C/C++ entwickeln in Visual Studio ist immer noch am angenehmsten. Einfach ein Linux Remote Projekt erstellen und man kann loslegen - auch ohne die Hardware, denn GCC / GDB kann man im WSL nutzen Und das egal ob die Target Hardware ARM64 oder sonst eine Architektur hat So kann man Logik bereits lokal testen ohne einen komplizierten Testaufbau.
• SSH & SCP! Statt Putty und WinSCP zu verwenden, kann man wie in Linux gewohnt die Nativen Tools verwenden

Angenehmer als CLion (hat auch WSL Support)? War mir vor ein paar Jahren lieber als VS.

Windows hat seit einer Weile selbst einen SSH Client fürs Terminal -> kein putty/winscp notwendig

 

[Dark Soul]

@Dark Soul
Die Bilanz liest sich ziemlich vernichtend: Man "braucht" Windows wegen einer schöneren Oberfläche, zum Zocken (nicht mehr) und für Office, in allem anderen ist Linux besser geeignet

PS. Gummiboot statt GRUB nutzen

Haha, mein Killerargument für Linux ist die Zeitersparniss Aber eben, jeder soll das Tool verwenden um seine Arbeit am besten durchzuführen

Gummiboot? Danke! Schau ich mir mal an

Und der Zugriff darauf ist auf Wunsch eben auch in jede andere installierte WSL Distribution nahtlos integrierbar. Das ist auch ein nennenswerter Unterschied zu Linux in einer "klassischen" VM von VirtualBox oder VMWare. Da dürfte ein VM-übergreifender Zugriff auch schwer bis unmöglich sein. Was aber auch in Ordnung ist, da dort die Isolation der VMs voneinander ja gewollt ist.

Ergänzung (16. November 2022)

Wobei Windows mittlerweile ja auch native Windows-Binaries von OpenSSH mitliefert, so dass man auch ohne Linux/WSL direkt SSH & SCP in der cmd.exe oder Powershell nutzen kann.

True - ging aber vor paar Jahren auch noch nicht

Angenehmer als CLion (hat auch WSL Support)? War mir vor ein paar Jahren lieber als VS.

Windows hat seit einer Weile selbst einen SSH Client fürs Terminal -> kein putty/winscp notwendig

Meiner Meinung nach schon - vor allem der Debugger ist absolut genial. Finde da kann CLion, Eclipse C++ und VSCode gar nicht mithalten.

Auch wenn man zB. Breakpoints im Cuda Code hat (mit den Cuda VS Tools).

 

[aid0nex]

Das Namensschema setzt sich also zusammen aus "was ist es" (Subsystem) und "was macht es" (Linux ausführen, Drucken, usw).

Ah, danke für die Erklärung.

 

[jedi23]

Meine Frage #63 ist wohl leider etwas untergegangen, aber ich frage mich das schon sehr lange und würde mich hier über mehr Klarheit freuen

Nachtrag: Ich habe jetzt mal WSL über die Windows Features deinstalliert und nach dem Neustart WSL über den Store installiert. Anschließend öffnet sich folgendes Fenster aber es passiert dort nichts! Auf das Drücken einer beliebigen Taste reagiert das Fenster nicht und auch nach einem Neustart funktioniert WSL jetzt auch nicht mehr.

Als ich würde wirklich gerne wissen, was das ganze soll und warum man das nicht über die Windows Features und anschließenden Windows Updates belassen hat! Nach Version 1.0 fühlt sich das wirklich nicht an...

 

[Grimba]

SSH & SCP! Statt Putty und WinSCP zu verwenden, kann man wie in Linux gewohnt die Nativen Tools verwenden

Das geht schon lange ganz normal in der Powershell, auch ohne Putty und WinSCP. Dafür alleine wäre Wsl Overkill.

 

[tomgit]

ALso zumindest bei ubuntu steht dabei, dass WSL unter den Windows Features aktiviert werden muss.

 

[Yuuri]

Docker Desktop besitzt seit ~ 2 Jahren ein WSL Backend - mit dem läuft es wunderbar. Die alte Windows Integration war "schwierig" - vor allem wenn man Hardware zur Beschleunigung mit OpenCL / CUDA ansprechen wollte. Das geht jetzt alles sehr smooth.

Ich weiß und der Wechsel brachte mich dann dazu, es direkt in der WSL zu installieren, weil es ständig Probleme mit Docker Desktop gab. Manchmal startete es nicht, Zurücksetzen war die Hölle (das VM Image wächst ja leider ins Unendliche), Volumes laufen in einem eigenen Image, an das man nur extrem schwer ran kommt und mit extensivem Logging gern auch 200+ GB einnehmen kann, manchmal kam einfach keine Reaktion der Anwendung (docker reagierte aber in der WSL), WSL abschießen + Docker Desktop neu starten war die einzige Lösung, die Volumes hakten manchmal und und und...

Seitdem ich docker direkt in WSL laufen und Docker Desktop weggeschmissen hab, funktioniert es seither anstandslos ohne zu murren und ohne irgend ne fragwürdig funktionierende Drittanbieterlösung im Hintergrund, die sich überall reinzuhängen versucht.

Andauernd unvollständig getestete, nicht immer "ansatzweise" funktionierende "Features" einzuführen war auch extrem nervig. Damit kann ich nicht täglich arbeiten. An einem Punkt war ich auf einen bestimmten Build fixiert, weil danach irgend ein nicht funktionierender Blödsinn eingeführt wurde, der nicht zurückgerollt und/oder schnell gefixt wurde, der die Arbeit unmöglich machte. Den Build hab ich aber auch schon sehr lange von der Platte geschmissen. Die Deepllinks zu den Preview Builds haben sie ja auch irgendwann von der Seite genommen... Preview entsprach hier eher Nightly und Stable war eher Debian Release Philosophie.

In der WSL läuft es nun auch monatelang ohne Probleme, egal ob ich da täglich den Rechner in Standby versetze, runter fahre, minütlich Container neu starte oder oder oder. Ist halt zuverlässig und es funktioniert wirklich wie gewollt. Und wenn das WSL-Image zu groß wird (u.a. auch wegen Volumes oder den tausenden Images, Build Caches usw.), kann ich das mit Hausmitteln (docker system prune -a und Optimize-VHD Cmdlet) auch wieder fix eindämmen.

Aber zwei Jahre? Hab im Urin das durch die Previews schon deutlich länger zu nutzen... Seit 2020 hab ich docker zumindest in meinem Brewfile verewigt, vorher lief es via apt.

Schade, daß das mit den übergreifenden Dateisystem bei WSL 2 nicht mehr so funktioniert. Gerade das war für mich recht praktisch, wenn ich mit Terraform-Scripten für AWS über GitHub (Actions) direkt rumhantierte. Das funktioniert mit WSL 1 erstaunlich gut.

Funktioniert doch noch genauso? Aber was für ein exotisches Feature hast du genutzt, dass dies nun nicht mehr gehen sollte? Der Zugriff erfolgt exakt genauso, im Hintergrund wird aber transparent P9 als Protokoll genutzt. Gemountet werden die lokalen Platten standardmäßig immer noch nach /mnt.

Meine Frage #63 ist wohl leider etwas untergegangen, aber ich frage mich das schon sehr lange und würde mich hier über mehr Klarheit freuen

Über die Systemsteuerung aktivierst du WSL lediglich. Über den Store beziehst du dir die gewünschte Distro, die dann darin ausgeführt wird. Und nein, die Distro wird nicht aktuell gehalten, das musst du alles manuell machen. WSL 1 kam hingegen auch nur mit bash on Ubuntu on Windows, da hattest du noch nicht die Auswahl wie jetzt mit CentOS, Ubuntu, Debian, SUSE, Alpine uvm.

Über die Systemsteuerung kannst du auch Hyper-V aktivieren. Um dann Ubuntu, Arch, Fedora o.ä. laufen zu lassen, musst du dir trotzdem die ISO ziehen und in einer VM installieren.

 

[jedi23]

Über die Systemsteuerung aktivierst du WSL lediglich. Über den Store beziehst du dir die gewünschte Distro, die dann darin ausgeführt wird. Und nein, die Distro wird nicht aktuell gehalten, das musst du alles manuell machen. WSL 1 kam hingegen auch nur mit bash on Ubuntu on Windows, da hattest du noch nicht die Auswahl wie jetzt mit CentOS, Ubuntu, Debian, SUSE, Alpine uvm.

Über die Systemsteuerung kannst du auch Hyper-V aktivieren. Um dann Ubuntu, Arch, Fedora o.ä. laufen zu lassen, musst du dir trotzdem die ISO ziehen und in einer VM installieren.

Okay dann ist die WSL App im Store, die ja das eigentliche Thema hier ist, also komplett überflüssig. Punkt.

Okay, Spaß beiseite. Soweit ich das jetzt verstanden habe, wird WSL als Windows Komponente tatsächlich hauptsächlich nur dann aktualisiert, wenn man eine neue Windows Version installiert (Ein manuelles updaten ist wohl aber auch möglich). Aber ich meinte auch mal Windows Updates zum WSL gesehen zu haben. Auf jeden Fall scheint die App Variante entsprechend schneller Updates zu bekommen, soll also die empfohlene Variante werden! Also muss ich auf jeden Fall zuerst die Windows Komponente aktivieren um dann mit der Store App eine aktuellere Version zu bekommen? Das verwirrende ist, das es sich auf vielen Seiten zur WSL Store App so liest, als würde das Subsystem allein durch die App aktiviert. Also würde ja dann das separate aktivieren über die Systemsteuerung dann nicht mehr erforderlich sein...

 

[SI Sun]

Das ist ja garnicht verwirrend...

Vielleicht war die für den Namen verantwortliche Person versehentlich mit jemandem im Gespräch, der die Namen für USB Standards definiert hat.

 

[Cornuostium]

@Yuuri Als ich meine Versuche mit Docker in WSL2 gemacht habe, musste ich zum Beispiel Docker Desktop nutzen, weil Docker nativ im WSL-Ubuntu zu installieren bzw. zu nutzen am Ende nicht funktioniert hat. Es war mir vor ein paar Wochen auf jeden Fall nicht möglich, dann ein Docker-Image anzulegen bzw. zu starten. Das ging dann erst mit Docker Desktop und der dort aktivierten WSL-Integration. Ich kann dir aber auch nicht mehr genau sagen, was das Problem war. Bei der Suche nach dem Fehler waren allerdings alle Lösungsvorschläge, Docker Desktop zu nutzen.