USB Mass Storage Orico (JMicron JMS56x 152d:0565) passthrough through Proxmox

Operating System
1

I have ZimaOS 1.5.3 plus installed in Proxmox. I’m trying to use external USB 3.0 case Orico (JMicron JMS56x ), passing it through as USB device. But in ZimaOS I can only see
these devices found:

#lsusb
Linux Foundation 2.0 root hub
Linux Foundation 3.0 root hub

Analyzing kernel logs, I can suppose, that the USB-to-SATA bridge JMicron JMS56x is detected, starting scsi host3, but kernel does not create block devices (sdX).
~20sec after device is down. There are no modules usb_storage/uas (modprobe: FATAL: Module not found).

On pure Debian 13.0 installed as VM at the same Proxmox host, this USB case works as a charm (I can see SCSI disks under lsblk, dmesg).

How to reproduce:

  1. In Proxmox 9.1.2 there is VM with ZimaOS 1.5.3 installed (ID 101, config: usb0: host152d:0565)
  2. In QEMU monitor: info usb outputs Device 1.0, Port 1, Speed 5000 Mb/s, Product JMS56x Series, ID: usb0
  3. In ZimaOS kernel logs:
[    3.410738] usb 3-1: new SuperSpeed USB device number 3 using xhci_hcd
[    3.424081] usb 3-1: New USB device found, idVendor=152d, idProduct=0565, bcdDevice= 0.09
[    3.424086] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[    3.424087] usb 3-1: Product: JMS56x Series
[    3.424089] usb 3-1: Manufacturer: JMicron
[    3.424090] usb 3-1: SerialNumber: RANDOM__EF0C17AD758C
[    3.425354] usb-storage 3-1:1.0: USB Mass Storage device detected
[    3.425555] scsi host3: usb-storage 3-1:1.0

BUT there are no lines with awaited scsi 3:0:0:0: Direct-Access / sdX.
And about 20sec after:

[   26.026956] usb 3-1: USB disconnect, device number 3

Unfortunatelly, cannot attach full dmesg logs…

Tried to temporary disconnect UAS/usb_storage, but:

root@ZimaOS:/root ➜ # modprobe -r uas
modprobe: FATAL: Module uas not found.
root@ZimaOS:/root ➜ # modprobe -r usb_storage
modprobe: FATAL: Module usb_storage not found.

As workaround, I can use these disks connected to host, and pass-through host discs. But it would be great, if it is possible to work with devices as pure USB.

The case is (almost) similar to this one: Zima OS 1.5 USB external 2 bay not being added to storage

Thank you!

2

Hi, thanks for the very detailed report, that helped a lot.

Based on what you’ve shared, I believe what you’re seeing is expected behaviour with ZimaOS, not a Proxmox or hardware fault.

What’s happening (important context)

ZimaOS is Buildroot-based, not a full Debian/Ubuntu system. Because of this, the kernel is intentionally minimal and does not include dynamic kernel modules like:

  • usb_storage
  • uas

That’s why:

  • modprobe usb_storage and modprobe uas fail
  • The JMS56x bridge is detected
  • usb-storage starts a SCSI host
  • But no block device (sdX) is ever created
  • The device disconnects after ~20 seconds

In other words, enumeration starts, but the required storage drivers are simply not present in the kernel, so the device cannot complete initialization.

Why it works on Debian but not ZimaOS

Your comparison with Debian 13 is actually the key point here:

  • Debian VM > full kernel + modules > works
  • ZimaOS VM > fixed, stripped kernel > does not

So this rules out:

  • Proxmox USB passthrough issues
  • JMS56x firmware issues
  • Disk or enclosure faults

Current limitations

As of ZimaOS 1.5.3, I believe:

  • USB-to-SATA bridges that rely on usb_storage or uas are not supported
  • This applies whether ZimaOS is bare-metal or virtualized
  • There is no supported way to load missing modules at runtime

Practical workarounds (what I suggest)

For now, the two reliable options are:

  1. Pass disks from the Proxmox host
    This is the safest and most stable approach and matches how ZimaOS is designed to be used in VMs.
  2. Attach storage via SATA / NVMe passthrough instead of USB
    These paths are fully supported by the ZimaOS kernel.

I believe your current workaround is already the correct one given today’s limitations.

About future support

This is not a configuration error on your side. It’s a kernel feature gap. Supporting USB mass storage bridges would require IceWhale to:

  • Enable usb_storage / uas in the kernel
  • Or provide a different VM-oriented kernel build

At the moment, I don’t believe this is officially supported.