Connecting USB in WSL when Windows Admin is a separate account

[janegilruud]

I just wanted to share my experience when trying to use usbipd-win to connect to a USB tool in WSL2 on my corporate Windows PC where the admin rights are in a separate account. I found bits and pieces in different places, so I thought I'd collect them in one place. I started out with this description: https://devblogs.microsoft.com/commandline/connecting-usb-devices-to-wsl/

The command usbipd wsl attach --busid <busid> won't work since my regular user don't have admin rights, and my Admin account doesn't see the WSL distro. The solution is to split this command in two:

1. In CommandPrompt or PowerShell with Admin rights run the following command: usbipd bind --busid <busid> --force. If you don't use --force the next step will fail with a "Device busy" error.
2. Make sure that you have completely restarted WSL (Run wsl --shutdown in a CommandPrompt or PowerShell). Then in WSL run sudo usbip attach -r $HOSTNAME.local --busid=<bus-id>. (Without sudo you will get an "Import Error".)

[dorssel]

@janegilruud
Great that you have it working.
Some additional notes:

1. --force may be necessary (or even wanted) for several reasons. The device being used exclusively by installed host software is one of them. But it isn't strictly necessary just because you have a non-admin account. It has its own ups-and-downs, but is unrelated.
2. After you have used usbipd bind as admin (with or without --force) you should be able to use usbipd wsl attach as a non-admin user. So, you do not necessarily have to attach from the Linux side (although you can, if you want to).

[janegilruud]

1. I was at least not able to get it working without --force
2. You are right. That works fine. (This could have saved me some time since it took me a while to figure out what's the correct <host> for the -r option ($HOSTNAME.local) 😃 )

EDIT: Escaped the < and >

[J-Rios]

I just faced the same thing,...

A couple of questions:

• Is the bind procedure permanent or we need to be an Admin each time we want to connect a device?
• Is there any other way to makes the windows admin terminal to detect WSL and allows the "attach" instead the bind?

Best Regards.

[dorssel]

@J-Rios

1. It is permanent. An admin needs to do this exactly once per device. It survives reboots, etc.
2. No, if you have separate accounts (standard user / admin user) then they cannot see each other's WSL instances. However, once you bind as admin as in (1), then you can just use wsl attach as the regular user. No need for an admin terminal then.

[J-Rios]

Sounds good, thanks for the clarifications!

[d0n13]

Just wondering if the command line could hand the bind off to the usbipd service to execute the bind as admin? I know this would require some code changes but would it be possible so that non-admin users could do this without any admin rights?

Important if the devices that are being plugged in have never been seen before...

[dorssel]

@d0n13
I know you are looking for a non-admin way of binding devices. It is possible, but we (me and MS) decided we don't want it for security reasons. There are many people using this on company administered machines, without admin rights. And there is a reason for not allowing any user to bind any device to their WSL instance when they are non-admin on Windows, but root on WSL. Think: security tokens, webcams (privacy), keyboard (key-logging on shared computers), etc. This would allow a standard user to bypass Windows group policy -> not good.

TL;DR: possible: yes, happening: no

[dorssel]

BTW: there is an easy hack that you could try: just change the permissions on the usbipd-win\Devices registry key to allow any user to write. That will do the trick for "non-force" bind as normal user. With --force, it is not possible, nor will it ever be.

[d0n13]

We will probably do this ourselves and move the bind into a service. I'm not sure we can do it any other way. I can see your point above and it makes sense. Ours is not the normal use case for this.

[d0n13]

Yea. I do the registry hack already. Just won’t work in this case

[kumkee]

How do I find out my $HOSTNAME.local?

[kumkee]

I got usbip: error: tcp connect when I do that.

[janegilruud]

Are you connected to VPN by any chance? If so, try when not connected to VPN.

[kumkee]

Are you connected to VPN by any chance? If so, try when not connected to VPN.

Not at all.

[kumkee]

You use that exact string. like this: sudo usbip attach -r $HOSTNAME.local --busid=8-2

It still doesn't work. I don't have a VPN or 3rd party firewall. I even downgraded my usbip on windows to match the one on wsl.

[kumkee]

You use that exact string. like this: sudo usbip attach -r $HOSTNAME.local --busid=8-2

It still doesn't work. I don't have a VPN or 3rd party firewall. I even downgraded my usbip on windows to match the one on wsl.

It turns out that it was due to my kernel version being too low. After upgrading,it works.

[The-Monkey-King]

I have been able to get this to work on a non-admin account. But two things must be established:

• You need to have WSL (1) installed on your account. Sometimes an Admin will install WSL within the Admin account and will only see Admin installed distributions.
• Install distros on your account.

With WSL it's basically 'like for like' which is interesting since I ran into the issue of being in the Admin account and not able to see distros loaded in other accounts.

[tao-chen-xc]

If you are struggling with the usbip: error: tcp connect error. Try this:

sudo usbip attach -r `hostname`.local --busid=<bus-id>

[Adesanya-Toba]

Awesome find! It works.
Thank you!