Your External Drive May Be Fine. Your Mac Just Can’t Ask.

“S.M.A.R.T. status: Not Supported” is usually a telemetry-path problem, not a health verdict. The useful question is what sits between macOS and the actual drive.

By CoreGuard · Jul 11, 2026 · 12 min read

What does “SMART Not Supported” mean on a Mac?

“SMART Not Supported” on a Mac means macOS did not receive usable SMART telemetry from that external device through its current connection path. It does not mean healthy, and it does not mean failing.

That distinction matters. Disk Utility presents the phrase in the same little information panel where people expect a verdict, so it is easy to read “Not Supported” as a polite version of “nothing is wrong.” It is not. The drive may be pristine. It may be degrading. macOS simply lacks the data required to distinguish those states.

For an internal drive, the operating system talks much more directly to the storage controller. In our own test, smartmontools 7.5 read the native NVMe health log from an Apple internal SSD, including Percentage Used, Data Units Written, Available Spare, and Power-On Hours. That internal case belongs in our Mac SSD SMART guide.

An external drive adds more hardware to the sentence. Sometimes several nouns’ worth.

The useful model is:

macOS → USB or Thunderbolt → bridge chipset → SATA or NVMe drive

SMART can exist perfectly well at the last step and still disappear before it reaches the first. Disk Utility can only report what arrives. It does not have a small engineer inside the enclosure with a clipboard.

The enclosure is part of the diagnostic system

People say “USB SSD” as if that describes one device. It usually describes a stack.

Inside the enclosure may be a SATA hard drive, a SATA SSD, or an NVMe SSD. The enclosure’s controller translates between that storage protocol and whatever the Mac sees. A complete portable SSD has the same problem; its bridge may simply be hidden on the product’s internal board rather than sold as a separate box.

For a SATA drive connected over USB, SMART normally depends on SAT, or SCSI / ATA Translation. The bridge must accept an ATA pass-through command, forward it to the SATA drive, and return the response. The DriveDx knowledge base tells users to check whether the enclosure controller is SAT-capable; it also warns that a nominally SAT-capable enclosure may still be unsupported by the available software path.

Micromat’s external-drive support note describes the same failure boundary: a USB bridge chipset may not pass SMART information through, or the device inside may expose too little useful information.

NVMe-over-USB is a different animal. SAT is for ATA/SATA; adding -d sat does not turn an NVMe device into a SATA device through force of personality. USB-to-NVMe bridges use vendor-specific translation methods. The smartmontools 7.5 release notes document support related to ASMedia and JMicron bridges and introduce experimental NVMe/SAT autodetection forms; the current macOS build also lists ASMedia, JMicron, and Realtek USB-to-NVMe device types.

There is no single magic -d sntusb option covering every NVMe enclosure. The actual names are bridge-family-specific: sntasmedia, sntjmicron, and sntrealtek.

Thunderbolt usually gives you a better shot because an NVMe device can be exposed through a PCIe-style path instead of appearing as generic USB mass storage. Micromat reports native macOS SMART support for external Thunderbolt storage. USB4 complicates the label: a USB4-capable enclosure may use a Thunderbolt/PCIe path or fall back to USB behavior. Check how it enumerates in System Information; the connector shape and retail badge are not evidence.

The decision tree: SATA, NVMe, USB, or Thunderbolt?

Start with the drive inside, not the cable outside.

If it is a SATA HDD or SATA SSD in a USB enclosure: the likely boundary is SAT pass-through. A bridge that supports SAT may expose the drive to smartctl even when Disk Utility remains unhelpful. A bridge that blocks ATA pass-through will give you no SMART data regardless of how healthy or unhealthy the SATA device is.

If it is an NVMe SSD in a USB enclosure: SAT alone is the wrong protocol. You need support for the specific USB-to-NVMe bridge family. smartmontools may identify a known ASMedia, JMicron, or Realtek implementation; an unknown controller or incompatible firmware can still leave the health log unreachable.

If it is NVMe over Thunderbolt: try the ordinary device path first. The storage may enumerate closely enough to native NVMe for macOS and smartctl to read its health log. Do not add bridge flags until the default query fails and you know what hardware you are addressing.

If the product says USB4: inspect the active connection. “USB4” describes capabilities, not necessarily the route used during this connection. System Information can show whether the device appears under USB or Thunderbolt/USB4.

These read-only commands help identify the stack:

diskutil list external physical
system_profiler SPUSBDataType SPUSBHostDataType SPThunderboltDataType
diskutil info /dev/diskN

One version note: on macOS 26 Tahoe, SPUSBDataType no longer returns any output; an Apple Community thread points to SPUSBHostDataType there instead, while noting the two data types do not necessarily expose identical information. Because system_profiler silently ignores data types it does not recognize, listing both keeps the command working on older and newer systems.

Replace diskN with the whole external disk, not an APFS volume such as disk4s2. In Disk Utility, choose View → Show All Devices and select the top physical device. Selecting a volume answers a filesystem question; selecting the device answers a hardware-path question.

Also test without a hub. Connect the enclosure directly, note the cable used, and keep power delivery in mind. If the same physical drive exposes SMART in one enclosure but not another, you have learned something about the bridge—not about the drive’s health.

That is the recurring logic error here: changing the messenger changes whether the report arrives. It does not retroactively change the patient.

How to try smartctl without guessing wildly

Use a current smartmontools build. First let it identify what it can:

smartctl --version
sudo smartctl --scan-open
sudo smartctl -a -q noserial /dev/diskN

The noserial option is worth keeping when you plan to paste output into a forum or support ticket. A drive serial number is not a diagnostic flourish.

If the normal query fails and you know the device contains a SATA drive behind a compatible USB bridge, try SAT explicitly:

sudo smartctl -a -q noserial -d sat /dev/diskN

For a USB-to-NVMe enclosure, identify the bridge chipset before choosing a device type. smartmontools 7.5 lists these families:

sudo smartctl -a -q noserial -d sntasmedia/sat /dev/diskN
sudo smartctl -a -q noserial -d sntjmicron/sat /dev/diskN
sudo smartctl -a -q noserial -d sntrealtek/sat /dev/diskN

The /sat forms are the experimental smartmontools 7.5 NVMe-or-SATA autodetection variants. They are not a universal compatibility layer. Use the line matching the known bridge family; do not machine-gun every flag at the only mounted copy of your archive and call that a methodology.

A successful NVMe result may include fields such as:

• Critical Warning
• Available Spare
• Percentage Used
• Data Units Written
• Media and Data Integrity Errors
• Power On Hours

The smartmontools 7.5 release notes explicitly document NVMe health handling for Percentage Used, Available Spare, and Media and Data Integrity Errors. SATA output varies more by manufacturer and model, so raw attribute names need interpretation against the drive vendor’s documentation.

A failed query still does not condemn the media. Errors such as “unsupported,” an unknown bridge, or an unavailable pass-through command describe the access path. Save the exact output, enclosure model, bridge chipset if known, smartctl version, and macOS version. “It didn’t work” is not a reproducible report. It is weather.

There is also an older SAT SMART Driver route. I would not present that as the default on Apple Silicon. Apple’s deployment documentation says third-party kernel extensions on Apple Silicon require Reduced Security, explicit approval, and a restart, and Apple no longer recommends kexts because of their security and reliability impact. Changing the Mac’s startup security policy for one health field is a serious trade, not a checkbox I would bury in step four.

What you can still observe when SMART is blocked

Missing SMART removes one evidence stream. It does not make the drive invisible.

First, look for behavior: failed copies, files that cannot be read twice, unexpected ejections, stalls under ordinary I/O, or a drive that repeatedly disappears and remounts. Those symptoms matter. They also implicate the cable, port, hub, enclosure controller, power delivery, and drive, so they do not identify the guilty component alone.

Second, inspect recent macOS logs:

log show --last 24h --style compact \
  --predicate '(eventMessage CONTAINS[c] "I/O error") OR
               (eventMessage CONTAINS[c] "ejected") OR
               (eventMessage CONTAINS[c] "disconnect")'

The result will be noisy. Correlate timestamps with the drive’s actual disconnects or failed operations. One unrelated “ejected” line is not a verdict; repeated device-correlated I/O errors deserve attention.

Third, verify the mounted filesystem without requesting changes:

diskutil verifyVolume "/Volumes/My Drive"

Apple says Disk Utility checks errors in formatting and directory structure, and the Disk Utility User Guide says it cannot detect every problem a disk may have. A clean verification means the filesystem metadata looked consistent during that check. It does not prove the flash, magnetic surface, controller, bridge, cable, or power supply is healthy.

The inverse matters too. Filesystem damage does not automatically mean the physical drive is failing. An unsafe unplug or power interruption can leave structural errors on otherwise functional storage. SMART and filesystem checks answer different questions.

For important files that should not change, a checksum gives you another read-only observation:

shasum -a 256 "/Volumes/My Drive/path/to/important-file"

Compare it with a trusted earlier checksum or repeat it after copying through a different path. A matching hash proves those bytes matched in those reads. It does not certify the rest of the device.

If the drive is already disconnecting, producing I/O errors, or losing files, copy irreplaceable data before running broader tests. Diagnostics are secondary when the only copy is evaporating in front of you.

Build an evidence chain, not a verdict from one label

I use four buckets:

1. Telemetry: Did SMART expose critical warnings, media errors, wear, spare capacity, or a failing status?
2. Transport: Does the device disconnect, reset, or misbehave only through one cable, hub, port, or enclosure?
3. Filesystem: Does read-only verification report structural errors, and do those errors recur?
4. Data: Do ordinary reads fail, or do trusted checksums change unexpectedly?

Then change one variable at a time. Try a direct port. Try a known-good cable. Try another enclosure appropriate for the same SATA or NVMe device. Try another Mac or an operating system with a different pass-through stack.

If SMART appears after an enclosure swap, the old bridge was hiding it. If disconnects disappear after a cable swap, the original cable becomes the leading suspect. If errors follow the bare drive across known-good bridges and machines, suspicion moves toward the media or its controller.

None of that yields an exact failure date. It yields something more useful: a documented chain of observations with fewer unknowns.

“Not Supported” is an unknown. Unknown is a legitimate result. Painting it green would be fraud with nicer typography.

Where CoreGuard fits—and where it cannot

CoreGuard is built around the same rule: show the evidence the hardware exposes, and never invent the rest.

It cannot force a USB bridge to pass SMART data that the bridge or macOS path withholds. No local health monitor can conjure Percentage Used or Media and Data Integrity Errors from an enclosure that never returns them. In that case, the honest state is unavailable—not healthy.

When usable SSD telemetry is exposed, CoreGuard Free shows the basic SSD verdict and life-remaining percentage. Every danger warning remains free. Free also includes basic history of readings and threshold alerts; I am spelling out “basic” because bare “history” is an easy way to imply a feature boundary that is not true.

CoreGuard Pro, at a one-time $29, adds the endurance detail: TBW, power-on hours, raw SMART data, wear trends, and an honest “years left” projection based on the observed trend. It is a projection, never a promised failure date. CSV/JSON sensor-log export is Pro as well.

The abnormal-disk-writes warning is free because learning that something is wrong is not an upsell. Pro adds the detailed per-app write timeline, longer history, and exportable evidence. The app observes and explains; it does not alter your files or pretend a blocked telemetry path is a pass.

Everything stays local. CoreGuard makes zero network connections, requires no account, and is distributed for macOS 13 or later as a Developer-ID signed and notarized universal app for Apple Silicon and Intel.

CoreGuard is still pre-launch. You can get notified for the launch or see the Free and Pro split. Until then, the practical move costs nothing: identify the drive, identify the bridge, preserve the smartctl output, and stop treating “Not Supported” as reassurance.

Frequently asked questions