macOS Tahoe 26.4 — "all 45 virtual ports in-use" on fresh boot, USB mass storage

Submitted by RyuX51 on #1

Hi,

I'm trying to share a USB mass storage device from a Synology DS920+ to a MacBook Pro M2 Max running macOS Tahoe 26.4 (build 25E246).

Versions:
- VirtualHere Server: 4.6.6-1466 (Synology DSM 7 package)
- VirtualHere Client: 5.9.7 (macOS Universal)

What happens:

When I right-click the USB drive in the client and select "Use", the client immediately fails with:

Unable to enumerate device at address 21

The log shows all 45 virtual ports are exhausted instantly — this happens on a fresh macOS reboot with no prior VirtualHere usage:

2026-03-31 18:43:57 INFO  :Unable to enumerate device at address 21
2026-03-31 18:43:57 ERROR :There are no more virtual ports available, all 45 in-use

This repeats in a tight loop. The server log shows rapid BOUND/UNBOUND cycling:

Device 21 [XXXX:XXXX] BOUND to connection 1
Device 21 [XXXX:XXXX] UNBOUND from connection 1
Device 21 [XXXX:XXXX] BOUND to connection 1
Device 21 [XXXX:XXXX] UNBOUND from connection 1

What I've tried:
- Fresh Mac reboot (ports exhausted on first connection attempt)
- Added onBind event handler to unmount DSM partitions and delete the SCSI device before claim — handler executes successfully per the server log, but the loop continues
- Confirmed no other USB devices are connected via VirtualHere

System extension status:

VirtualHere does not appear in systemextensionsctl list. I understand the client uses IOUSBHostControllerInterface (entitlement com.apple.developer.usb.host-controller-interface) rather than a DriverKit system extension. No approval prompts appeared on first launch.

Suspected cause:

Tahoe 26 made significant changes to the USB stack (IOUSBFamily.kext removal, property renames). It seems like the virtual host controller initializes but all 45 ports are immediately reported as in-use, preventing any device enumeration.

This looks related to the sleep/wake port leak fixed in 5.4.1, but occurring at initialization rather than after sleep.

Happy to provide additional logs or test a beta build.

Thanks

P.S.: The analysis and this post has been created with help of Claude Code.

Submitted by Michael on Wed, 2026/04/01 - 06:07

#2

Can you plug the drive into a USB 2 hub first to force it to usb 2 mode and see if that fixes it.

Submitted by RyuX51 on Thu, 2026/04/02 - 01:55

#3

Ok, I have an update: Because I don't have an USB 2 hub and my DS902+ has no USB 2 port, I tried disabling USB 3 via sudo sh -c 'echo 0 > /sys/bus/usb/devices/usb2/authorized'. I noticed that my (encrypted) drive was directly locking when I tried to connect via USB 2 so I tried replicating it with an USB 2 and then an USB 3 stick. Both connected just fine using VirtualHere. So the problem seems to be specific to my hardware encrypted drive - which I should've mentioned in my initial post but I thought it would just behave the same as a normal drive when unlocked. Does VirtualHere reset the device during capture? If so, then the encryption controller might lock the drive, which then fails enumeration.

Either way - it's not a bug in your software, so sorry for the unneeded ticket.

Submitted by Michael on Thu, 2026/04/02 - 06:23

#4

OK yes that is likely the issue. Virtualhere does reset the drive when it is captured.