DevBeta 3: External USB NVMe enclosure detected but block device is not created (Apple Silicon)

[edevmon]

I have one dock with two HDDs, and one SSD inside a USB 3.2 enclosure but none of this external drives will show up in Finder, neither would be listed on Disk Utility, when I plug them in. The same devices work correctly on macOS 15.7.7 on an Intel based MacBook Pro, but they don't on macOS 27 Beta 3 (M5 MacBook Air).

I investigated this issue in the terminal with help from ChatGPT, with commands like:

system_profiler SPUSBDataType

ioreg -p IOUSB -l

log show --predicate 'subsystem contains "diskarbitrationd"' --last 30m

We concluded that the external USB mass storage devices are detected by the USB subsystem, but no block storage devices are created.

This MBA M5 came with MacOS 26 pre-installed but I dislike Tahoe's UI with a passion so I created my user and inmediately upgraded to Golden Gate even before installing any software or using any external device. This leads me to think that this problem is not inherited from MacOS 26, but that Apple is working under the hood on the USB stack instead.

It was my first time sending a report through Feedback Assistant and I wonder: am I the only one with this issue?

 

[edevmon]

Hello! This is still happening to me in Developer Beta 4. Ran a new set of tests and this is my conclusión (translation with help from ChatGPT):

Additional technical information

The affected external storage device is correctly detected at the USB level, but it never becomes available as a block storage device.

Observations​

• The USB host controller is operating normally.
• The external device is successfully enumerated as:
  
  • Vendor ID: 0x152D (JMicron)
  • Product ID: 0x0583
  • USB 3.2 (10 Gbps link)
• The USB Mass Storage / UASP stack loads correctly:
  
  • AppleUSBMassStorageInterfaceNub
  • IOUSBMassStorageDriverNub
  • IOUSBMassStorageUASDriver
• The SCSI layer is also initialized:
  
  • IOSCSITargetDevice
  • IOSCSIHierarchicalLogicalUnit

However, the initialization never progresses to creating a block storage device.

No IOSCSIBlockCommandsDevice, IOBlockStorageDriver, IOMedia, or /dev/diskX node is ever created.

As a consequence:

• diskutil list only shows the internal SSD.
• Disk Arbitration never receives a new disk to mount.
• The external drive is inaccessible.

Kernel log​

While the device is connected, the kernel repeatedly reports:

IOSCSIPeripheralDeviceType00:ClearNotReadyStatus<br>ClearNotReadyStatus in progress...<br>service response 0x2<br>task status 0x2<br>sense data 0x02/0x04/0x01<br>
The returned SCSI sense codes correspond to:

• Sense Key: 0x02 — NOT READY
• ASC: 0x04 — Logical Unit Not Ready
• ASCQ: 0x01 — Becoming Ready

The device appears to remain indefinitely in the "Becoming Ready" state and never transitions to READY, preventing macOS from publishing a block device.

Additional observations​

system_profiler SPUSBDataType unexpectedly returns an empty result:

system_profiler SPUSBDataType<br>
and

system_profiler SPUSBDataType -xml<br>
produce an empty SPUSBDataType array, despite the USB device being fully visible in ioreg and correctly enumerated by the USB stack.

Expected behavior​

The device should transition from IOSCSIHierarchicalLogicalUnit to IOSCSIBlockCommandsDevice, followed by creation of IOBlockStorageDriver, IOMedia, and a corresponding /dev/diskX device, allowing Disk Arbitration to mount the volume.

Additional information​

The same external storage device works correctly on another Mac, suggesting this may be a regression specific to the current macOS beta rather than a hardware issue.

 

[edevmon]

Here's the last report (with more concise information) sent in Feedback Assistant:

USB NVMe device enumerates successfully but fails during SCSI initialization and is never published as an IOBlockStorageDevice

--------------------------------------------------------------------------------

Configuration

Host:
- MacBook Air M5 (Apple Silicon)

Operating System:
- macOS Golden Gate Beta
- Build 26A5388g

External enclosure:
- AISENS ASM3-028B

USB bridge:
- JMicron JMS583
- VID : PID = 152D:0583
- Firmware version: 2.01.04

SSD:
- Silicon Power P34A80
- 2 TB
- PCIe Gen3 x4
- NVMe 1.3
- Phison E12 controller

--------------------------------------------------------------------------------

Expected Result

Connecting the enclosure should:

- enumerate the USB device
- initialize the storage stack
- publish an IOBlockStorageDevice
- create /dev/diskX
- allow Disk Arbitration to mount the volume

--------------------------------------------------------------------------------

Actual Result

The USB device enumerates successfully.

The UASP driver is loaded.

The SCSI target is created.

Storage initialization never completes.

No IOBlockStorageDevice is published.

No IOMedia is created.

No /dev/diskX node appears.

The drive is therefore invisible to:

- Disk Utility
- diskutil
- Finder
- Disk Arbitration

--------------------------------------------------------------------------------

Observed Behavior

USB enumeration succeeds.

IORegistry contains:

IOUSBHostDevice
AppleUSBMassStorageInterfaceNub
IOUSBMassStorageDriver
IOUSBMassStorageUASDriver
IOSCSITargetDevice
IOSCSIHierarchicalLogicalUnit

However:

- IOBlockStorageDevice is never created.
- diskutil list only shows the internal SSD.
- system_profiler SPUSBDataType returns an empty device list.
- Disk Arbitration never receives a usable storage device.

--------------------------------------------------------------------------------

Relevant Kernel Messages

During initialization the following messages are repeatedly logged:

IOSCSIPeripheralDeviceType00:
ClearNotReadyStatus

sense data:
02/04/01

(Logical Unit Not Ready – Becoming Ready)

The retries continue for approximately 46 seconds.

Initialization finally terminates with:

InitializeDeviceSupport error

No block storage device is subsequently published.

--------------------------------------------------------------------------------

Additional Observations

USB transport appears to operate normally.

The enclosure negotiates:

USB 3.2 Gen2
10 Gbps
UASP

There are no USB disconnects, controller resets, or transport errors before the storage initialization aborts.

The failure occurs after USB enumeration and before block storage publication.

--------------------------------------------------------------------------------

Hardware Verification

The enclosure has been verified on another Mac running a stable macOS release.

The same hardware works correctly.

The following components have therefore been verified:

- AISENS ASM3-028B enclosure
- JMicron JMS583 bridge
- JMS583 firmware 2.01.04
- Silicon Power P34A80 SSD

The problem only occurs on this macOS Golden Gate beta installation.

--------------------------------------------------------------------------------

Reproducibility

100%

Every connection follows the same sequence:

1. USB enumeration succeeds.
2. UASP driver loads.
3. SCSI target is created.
4. ClearNotReadyStatus retries begin.
5. InitializeDeviceSupport fails.
6. No IOBlockStorageDevice is published.

--------------------------------------------------------------------------------

Commands Used During Investigation

ioreg -p IOUSB -l

ioreg -r -c IOUSBHostDevice

ioreg -r -c IOBlockStorageDevice

diskutil list

system_profiler SPUSBDataType

log stream --info --predicate '(process == "kernel") && (eventMessage CONTAINS[c] "SCSI" || eventMessage CONTAINS[c] "UAS" || eventMessage CONTAINS[c] "MassStorage" || eventMessage CONTAINS[c] "disk" || eventMessage CONTAINS[c] "IOMedia")'

--------------------------------------------------------------------------------

Regression

The same enclosure and SSD function correctly on another Mac running a stable macOS version.

This behavior appears to be a regression in the current macOS Golden Gate beta affecting the USB Mass Storage / UASP / SCSI initialization path.

--------------------------------------------------------------------------------

Working Hypothesis

The regression appears to occur after successful USB/UASP initialization but before IOBlockStorageDevice publication.

The failure point appears to be within the SCSI block device initialization path, terminating with InitializeDeviceSupport before an IOMedia object is created.

 

[benholt]

Not just you — the JMS583 has been a slow-motion train wreck against Apple's UAS driver for a couple of years now, and Golden Gate is where it looks like it finally fell off the rails. Two things that gave me useful data on my M2 Ultra with a similar 152D:0583 enclosure:

1. Kill UASP for that enclosure and force plain BOT. On Apple Silicon you can't blacklist by kext arg the way Intel used to, but you can create /Library/Preferences/SystemConfiguration/com.apple.usb.uasp.plist with the VID/PID pair to fall back to Mass Storage. Slower, but the "Becoming Ready" loop is a UAS command-queuing timeout, not a bus-level issue — BOT sidesteps it.

2. If the JMS583 firmware is old (yours is 2.01.04, current is 2.02.11 as of last summer), that's worth a Windows loaner-machine detour with JMicron's flasher. Silverstone/AISENS/Sabrent all shipped units on 2.01.x that miscount the "unit becoming ready" reporting interval by an order of magnitude, and Apple's newer UAS state machine gives up before the flag ever flips.

Longer term I switched everything critical to Realtek RTL9210B or ASMedia ASM2464 bridge enclosures and haven't hit this class of bug once. JMS583 was a great chip in 2019, but Apple's storage stack has clearly moved past what its firmware handshake assumes.

 

[edevmon]

Thank you very much for your insights; I will try to force BOT fallback and see what results I can get. As for the firmware flashing, It will take a bit more time from me as I'm on vacation now.
From now on, I'll consider another bridge options when buying new enclosures, this was totally unknown to me.

 

[schmalen]

Not just you — the JMS583 has been a slow-motion train wreck against Apple's UAS driver for a couple of years now, and Golden Gate is where it looks like it finally fell off the rails. Two things that gave me useful data on my M2 Ultra with a similar 152D:0583 enclosure:

1. Kill UASP for that enclosure and force plain BOT. On Apple Silicon you can't blacklist by kext arg the way Intel used to, but you can create /Library/Preferences/SystemConfiguration/com.apple.usb.uasp.plist with the VID/PID pair to fall back to Mass Storage. Slower, but the "Becoming Ready" loop is a UAS command-queuing timeout, not a bus-level issue — BOT sidesteps it.

2. If the JMS583 firmware is old (yours is 2.01.04, current is 2.02.11 as of last summer), that's worth a Windows loaner-machine detour with JMicron's flasher. Silverstone/AISENS/Sabrent all shipped units on 2.01.x that miscount the "unit becoming ready" reporting interval by an order of magnitude, and Apple's newer UAS state machine gives up before the flag ever flips.

Longer term I switched everything critical to Realtek RTL9210B or ASMedia ASM2464 bridge enclosures and haven't hit this class of bug once. JMS583 was a great chip in 2019, but Apple's storage stack has clearly moved past what its firmware handshake assumes.

Thanks, this is really helpful — matches a lot of what I've been chasing down myself over the past two days (same VID / PID 152D:0583, same "Becoming Ready"/UAS timeout pattern on an M2 Pro mini, not an M2 Ultra).

Two follow-up questions if you don't mind:

1. Could you share where you got the 2.02.11 firmware? I've only been able to find older community-shared JMS583 firmware (0.2.1.4 and a v244.02.00.03 build from July 2025), and it'd help to compare against what you're running.

2. On the com.apple.usb.uasp.plist VID/PID blacklist approach — is that something you've confirmed working on current Apple Silicon builds (Tahoe/Golden Gate beta), or is it a legacy mechanism carried over from Intel-era kext blacklisting? I haven't been able to find independent documentation of that plist path for Apple Silicon and want to make sure I'm not chasing a dead end before I try it.

Appreciate the detailed writeup either way — already mid-way through switching a Time Machine drive off JMS583 to an RTL9210B enclosure based on exactly this kind of feedback.

 

[edevmon]

Additional investigation has isolated the issue further.
The affected device is an Aisens ASM3-028B USB enclosure based on the JMicron JMS583 bridge, containing a Silicon Power P34A80 2 TB NVMe SSD.

USB identification on the affected Mac:
VID: 0x152D
PID: 0x0583
USB speed: 10 Gbps
bInterfaceClass: 8 (Mass Storage)
bInterfaceSubClass: 6 (SCSI transparent)
bInterfaceProtocol: 0x62 (98, UAS)

ioreg shows that macOS successfully enumerates the USB device and matches it to:
IOUSBMassStorageDriverNub
IOUSBMassStorageUASDriver

The UAS driver is therefore being selected correctly, but the storage device never becomes available as a usable block device.

The same physical enclosure and SSD work correctly when connected directly to another Intel Mac running macOS Sequoia. The SSD and enclosure therefore appear to be functional.

There is also a significant topology-dependent workaround:
- Direct connection to the affected Mac: device is enumerated, IOUSBMassStorageUASDriver is matched, but the disk does not appear/mount.
- Connection through a USB hub: the same enclosure/SSD becomes usable.

This strongly suggests a compatibility problem in the UAS/storage initialization path rather than a USB enumeration or physical-layer problem.

I also tested the proposed per-device UAS-to-BOT override by creating:

/Library/Preferences/SystemConfiguration/com.apple.usb.uasp.plist

with the device VID/PID (0x152D / 0x0583), followed by a reboot.

This did not change the behavior. After reboot, the device continued to be handled by IOUSBMassStorageUASDriver when connected directly, and the disk still did not become available.

Therefore the plist does not appear to provide an effective UAS blacklist/override mechanism on this version of macOS, or the format/key used by the current USB mass-storage implementation differs from the expected mechanism.

The most useful diagnostic comparison may therefore be the difference between the direct connection and the USB-hub connection.

In particular, please investigate the JMS583 UAS initialization sequence and the handling of SCSI/UAS "TEST UNIT READY" / "UNIT ATTENTION" / "BECOMING READY" responses and associated timeouts.
The behavior is highly suggestive of a UAS state-machine/timeout compatibility issue with this JMS583 firmware revision.

JMS583 firmware currently reports version 2.01.04.

A potential workaround for users is to connect the enclosure through a USB hub, which changes the USB topology and allows the device to become operational. However, direct connection remains broken.

Please compare the UAS initialization behavior between:
1. Direct USB connection on Golden Gate (fails)
2. Same device through a USB hub on Golden Gate (works)
3. Same device directly connected to macOS Sequoia on Intel (works)

This should help determine whether the regression is in the Golden Gate USB/UAS storage stack rather than in the device hardware or firmware.

 

[edevmon]

Retested on macOS 27 beta 7.

The issue is still 100% reproducible with the same AISENS ASM3-028B / JMicron JMS583 enclosure (VID 0x152D, PID 0x0583, firmware 2.01.04) containing a Silicon Power P34A80 2 TB NVMe SSD.

Direct connection produces the same SCSI initialization failure observed on the previous beta:

11s ClearNotReadyStatus Sense 0x02/0x04/0x01
22s ClearNotReadyStatus Sense 0x02/0x04/0x01
33s ClearNotReadyStatus Sense 0x02/0x04/0x01
41s ClearNotReadyStatus Sense 0x02/0x04/0x01
46s ClearNotReadyStatus failed or took long
InitializeDeviceSupport error

The device is enumerated as USB Mass Storage/UAS and IOUSBMassStorageUASDriver is selected, but no usable block device is created and the drive does not appear in diskutil.

Important comparison:
- Direct connection on macOS 27 beta 7: FAIL
- Same enclosure connected through a USB hub: WORKS
- Same enclosure connected directly to another Intel Mac running macOS Sequoia: WORKS

This strongly suggests a compatibility/regression issue in the UAS/SCSI initialization path for this JMS583 implementation rather than a hardware or filesystem problem.

The behavior and timeout sequence are unchanged from the previous beta.