Cannot safely remove external USB HDD if WSL Linux services are running

[quiret]

• Your Windows build number: Build 17063.1000

• What you're doing and what's happening:

1. Plug in an external USB drive
2. Start bash
3. do some things until Ubuntu services are running (apt-get update, apt-get upgrade, launch some GUI apps like codeblocks, etc) [TENDS TO BE RANDOM]
4. close all bash windows and all other Linux windows
5. try to safely unmount your USB drive using the tray icon
6. recognize that the removal fails all the time
7. kill all Linux processes using Task Manager
8. repeat step 4
9. recognize that your USB drive has now successfully unmounted

• What's wrong / what should be happening instead:
  Linux processes should not block external USB drives like that. I know this is by design because external USB drives are mounted as regular drives into Linux namespace (/mnt/y). But this is not obvious to Windows users and there is no helpful hint by the GUI as to what could be having the handle into the drive.

[therealkenc]

do some things until Ubuntu services are running (apt-get update, apt-get upgrade, launch some GUI apps like codeblocks, etc) [TENDS TO BE RANDOM]

I think the problem isn't the Linux services proper, per-se (let's say dbus as a common case). It isn't random. The problem (if that's the word) is you have taken a positive action to mount Y:, and WSL instance is still running; not because anything has a handle open on Y:.

What is non-obvious is that Linux services are still there, as of 17046 "Allow processes to run without an active terminal" and in the case of some Linux GUI apps, get auto-launched. As you say, that is pretty much by-design territory.

But this is not obvious to Windows users and there is no helpful hint by the GUI as to what could be having the handle into the drive.

Yeahbutt, that is the GUI experience on the Windows side too. If you have something holding Y: open in Windows, you get the same message, which doesn't indicate what is holding the drive hostage. You could use the Windows Feedback Hub and/or User Voice and ask for improvement here, but it has been that way for decades; possibly because a big crazy error message was deemed undesirable. I wish the message were more informative too, so I feel your pain. But that User eXperience isn't under control of the WSL peeps. Maybe there could be some coordination, shrug. Anything is possible.

I think, probably, the real solution here is support for auto-unmount. Previous to 17046 your Y: drive was unmounted by virtue of the fact the whole edifice was taken down. Even if dbus is still running, that drive went away and should unmount, unless something is holding open a handle (say httpd is serving up files on USB drive Y:). This was touched on briefly in #1962 (message). That's a pretty big ask though....

[quiret]

I like that you mentioned the auto-unmount idea. Have slim hopes for this because you said it is a "pretty big ask" though having this issue around should at least point and say "hey, you could have to terminate all WSL processes before safely removing your X/Y/Z drive".

[fpqc]

Automount units are supported by systemd, if support is ever added, but this is basically intended behavior.

[therealkenc]

Let's call this #560 for the sake of closure. The OP is either by-design (which isn't constructive tag to give this) or "Windows error message should suckless" (which isn't a WSL actionable). This issue will show up in a web search either way. Completely understandable post.