Error when starting up: EISDIR: illegal operation on a directory

[mnoworzyn]

Actual Behavior

When Rancher Desktop 1.3.0 (also confirmed on 1.2.1) starts up it displays the error message: Error: EISDIR: illegal operation on a directory, open '\wsl$\rancher-desktop\etc\hosts' and hangs. I've also tried factory reset, enable/disable Kubernetes, containerd/dockerd with the same behavior. Uninstalling Rancher Desktop and unregistering rancher-desktop and rancher-desktop-data WSL distributions don't work either. The file /etc/hosts is editable from WSL shell and from Windows.

Steps to Reproduce

After installing Rancher.Desktop.Setup.1.3.0.exe run Rancher Desktop and wait.

Result

Please check the attached logs:

rancher_desktop_1.2.1_logs.zip

Rancher Desktop icon is red, docker command is not available.

Expected Behavior

Startup Rancher Destkop completed, Rancher Desktop is running, docker command is available.

Additional Information

No response

Rancher Desktop Version

1.3.0 and earlier

Rancher Desktop K8s Version

1.23.5

Which container runtime are you using?

containerd (nerdctl)

What operating system are you using?

Windows

Operating System / Build Version

Windows 10

What CPU architecture are you using?

x64

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

No response

Windows User Only

No response

[gunamata]

Is this the first time you tried installing Rancher Desktop on this machine?
Also, Can you please confirm you have Windows 10 build 1909 or higher, and WSL2 installed on this machine?

[bendahl]

Hi there,

I'm having the reported issue on my work machine. It is currently running a Windows 10, build 18363. I'm also running WSL2, as most of my work evolves around Linux and containers. I did successfully install and run Rancher Desktop version pre-1.0. At the time, Rancher Desktop would only work outside the corporate VPN making this a non-option, unfortunately.

Things that I've tried, but that did not yield any success:

• Cleaning up all left over resources after uninstalling Rancher Desktop (WSL distros, directories, etc...)
• Adjusting ownership on /etc/hosts
• Deleting /etc/hosts (Go will error out when trying to create an already existing file)

I hope this helps. Let me know if you need any further information. Thanks in advance!

Cheers
Ben

[gunamata]

The Windows build# looks okay.. As you mentioned you were able to install an earlier version of Rancher Desktop without VPN in the past, Can you please try installing the latest version outside your corporate VPN? Just to rule out if the issue has got something to do with VPN.

[bendahl]

Thanks again for the quick reply! I've tried this outside the VPN, but no luck. Another idea that comes to mind is to try and manipulate the /etc/hosts from within another script to see whether I'm getting the issue there as well. This would allow for further debugging...

[bendahl]

Hey there,

I just got the hint that there is another similar issue reported in #1807. Maybe the problem is related... I will investigate this further and post if anything new turns up.

[bendahl]

Just did some testing and these are my findings:

• Using a Python script (running on Windows) I can access (read/write) the /etc/hosts file within the rancher-desktop WSL distro using the network path '\\wsl$\rancher-desktop\etc\hosts'.
• Upon resetting the K8S installation as well as upon a version change the WSL instance is restarted
• Upon restart the error mentioned above appears as well

This leads me to believe that we're dealing with some sort of timing issue. If a process tries to write to the /etc/hosts within the rancher-desktop distribution while the distro is not ready yet (network mount unavailalbe in Windows), the file won't be accessible and therefore any operations on it would fail.

Looking at the local log files and searching for the error in this repo leads me to believe that the error happens within background.ts (see this:

rancher-desktop/background.ts

Line 665 in af57b25

console.log(`Kubernetes was unable to start:`, payload);

). I'm not sure though, whether the issue needs to be fixed/can be fixed in the invoking function or whether this is something related to the k8smanager class, since I'm not familiar with the code. However, maybe this helps.

[bendahl]

On a different note, maybe it would be safer to simply perform all alterations to config files within the WSL environment, not accessing the network mount from Windows at all. This also works in the event that the distro is still offline/shutdown. A crude, yet effective way of doing this would be execing echo or grep within the distro (e.g. exec(wsl -d rancher-desktop 'echo "somevalue" > /etc/somefile'). "Somevalue" could also be a templated string, of course.

I'm sure there are better ways of doing this, but this is just a quick thought of things to try.

[gunamata]

We couldn't reproduce this issue on our end.
@bendahl , By any chance , Have you tried anything else that fixed the problem or have additional information that could help us investigate?

[bendahl]

@gunamata: I just tried installing RD again after applying a bunch of updates, hoping that this might change things. Unfortunately, it didn't. I'm still running into the same issues described.

I don't think that I do have any more information regarding the RD installation that would be of any help.

From experience in automating WSL image builds I can say though that writing to config files directly using the UNC path proved to be unreliable. Another issue I came across is the fact that the WSL will shut down the instance once a command is done. So, if you want to do any kind of provisioning and need to keep the instance running, you will need to start some background process. I simply used the cron daemon for this purpose. As already mentioned before, maybe the "EISDIR" issue is somehow related to this WSL behavior. Regarding the manipulation of config files within the WSL instance I did resort to template strings and running a command inside the target instance to update the relevant file, circumventing any issues regarding network mounts.

[mnoworzyn]

I've got another report of this bug in our company. Unfortunately without any new data. Yet another Windows 10 21H2 and Rancher Desktop 1.3.0 and 1.4.1.

When starting up rancher desktop I keep getting this error message, and docker is not available ('docker demon not running' upon 'docker ps'):
Error: EISDIR: illegal operation on a directory, open '\wsl$\rancher-desktop\etc\hosts'

[mburkhardtPSI]

Using Rancher Desktop 1.5.1 I still have this issue.

Error: EISDIR: illegal operation on a directory, open '\wsl$\rancher-desktop\etc\hosts'

Workaround

For me it just helps to delete the hosts file before each startup.

wsl -d rancher-desktop  
cd /etc  
rm hosts

After that it´s working fine in a non VPN and Proxy environment.
With VPN and Proxy it will try to connet to Kubernetes for ever.

Open Question
It creates this file anyway during startup, but because of this there seems to be some misbehavior if this file exists?