WSL Integration cannot be disabled

[DaRolla]

Actual Behavior

I am using Windows 11 with WSL2 and 2 distros: Kali and Ubuntu.
Rancher Desktop was enabled for both distros (only Docker, no Kubernetes).
Now I want to disable one integration (e.g. Ubuntu).
The UI shows the success.
And I restarted my system to be crystal clear.
Unfortunatlly I can call "docker" within Ubuntu, and "whereis docker" shows "/mnt/c/Program Files/Rancher Desktop/resources/resources/linux/bin/docker".
So it is NOT disabled, although I chose so, and the UI mirrors that.

Steps to Reproduce

Install 2 WSL distros on a Windows 11 system.
Install Rancher Desktop.
Enable WSL Integration for both distros.
Then disable one WSL Integration.

Result

use "docker" or "whereis docker" to make sure that no docker is installed on the distro with the disabled Rancher Desktop WSL Integration.

Expected Behavior

using "docker" or "whereis docker" shows that there is no docker installed (thus not using the Rancher Desktop WSL Integration)

Additional Information

No response

Rancher Desktop Version

1.13.1

Rancher Desktop K8s Version

not using Kubernetes

Which container engine are you using?

containerd (nerdctl)

What operating system are you using?

Windows

Operating System / Build Version

Microsoft Windows 11 Pro, Version 10.0.22631 Build 22631

What CPU architecture are you using?

x64

Linux only: what package format did you use to install Rancher Desktop?

None

Windows User Only

No response

[mook-as]

We just add all of the tools to Window's PATH, and your distro is picking that up. Any copy of docker you install inside the distro should still take precedence.

We can't turn that off because we're not actually doing anything there :)

[pit-hub]

Rancher Desktop should add only windows executables to the windows path. So this way only the Docker integration should include linux executables to the WSL distros.
It will be possible to run docker.exe though ;-) as this is the way WSL works ...

[jandubois]

Rancher Desktop should add only windows executables to the windows path. So this way only the Docker integration should include linux executables to the WSL distros.

While I agree with this conceptually, it is actually difficult to implement: how do we know for each possible distro how the user configures the Linux PATH inside. What shell are they using, what config file do we have to update etc.

We can do this via heuristics, that will work most of the time (similar to how we do this on macOS and Linux), but it would be more brittle.

So I'm wondering what problem this would solve. What is the issue of having the binaries included near the end of the PATH of a distro even when WSL integration is not enabled for that distro? There must be a significant benefit to compensate for switching to a less reliable method of configuring the PATH.

Note that you can also disable appending the Windows paths by setting appendWindowsPath = false in the [interop] section of /etc/wsl.conf inside your distro.

[DaRolla]

Just one more thing to mention.
So I really wanted to get rid of that docker within my WSL, so I uninstalled Rancher Desktop.
Unfortunately the docker was still available within my distros, and the rancher-desktop and the rancher-desktop-data distros were still there. So I had to unregister them manually to get finally rid of that docker (in order to install docker natively within my distros). So please think about cleaning up as well...

[jandubois]

I uninstalled Rancher Desktop.
Unfortunately the docker was still available within my distros,

I do this on a daily basis for testing, and when I uninstall Rancher Desktop with the "Add or Remove programs" feature, the files are deleted, so there is no way it can still be available in WSL unless the uninstall failed:

$ ls -l "$(which docker)"
-r-xr-xr-x 1 suse suse 38401408 May 16 23:38 '/mnt/c/Program Files/Rancher Desktop/resources/resources/linux/bin//docker'

In the same shell, after uninstalling Rancher Desktop:

$ ls -l "$(which docker)"
ls: cannot access '': No such file or directory

Either way, I don't see how the docker binary at the end of the PATH can be an issue; if you install docker yourself, then your client should be installed in a directory earlier on the PATH, shadowing the Rancher Desktop one.

the rancher-desktop and the rancher-desktop-data distros were still there

This is by design, so you can upgrade Rancher Desktop (which uninstalls the old version), and still keep your images/workloads/configs etc.

If you want to remove everything, you need to perform a factory-reset before the uninstall.

[jandubois]

I'm going to close this issue as "by design" since I haven't seen any actual problems that are caused by having the binaries always on the PATH, and I've explained why doing it has benefits.