Portable SSD Not Mounting on Mac: What -69845 Hides

There is no portable SSD attached to the machine that runs this business. system_profiler SPUSBDataType returns exactly 0 bytes, diskutil list external prints nothing, and tmutil destinationinfo says No destinations configured. That is an awkward starting point for an article about drives that will not mount, so I manufactured the failures out of disk images instead and measured what macOS 26.4.1 (build 25E253) says at each layer.

What came out is not the checklist every search result gives you. Three unrelated faults present as the same sentence, my SSD is not mounting, and the error code everyone quotes carries no diagnostic information at all.

Layer 1: what "not detected" actually looks like

The empty baseline is worth publishing because almost nobody shows it. With nothing plugged in, SPUSBDataType is not an error and not a politely empty list; it is a zero-byte response. If a drive never enumerates, that is what you see, and no amount of Disk Utility clicking changes it. This is the layer where cables matter, and the one thing disk images cannot simulate, so treat the rest of this article as silent on it. The relevant check is telling USB-C cable speeds apart.

Layer 2: mounted, writable, and invisible

In the long Apple Developer Forums thread on external disks not mounting, the recurring report is not that the disk is absent. It is that the disk appears in Disk Utility but not in Finder. One poster found flash drives present in /Volumes while Finder showed nothing; another found them hidden in the sidebar until the Locations arrow was expanded.

A mount flag produces exactly this. I added volumes to one APFS container while changing a single thing, the APFS role. The volume that got a role came up with one extra flag and nothing else:

/dev/disk5s1 on /Volumes/CTRL   (apfs, local, nodev, nosuid, journaled, noowners, mounted by sg-mini)
/dev/disk5s2 on /Volumes/NOROLE (apfs, local, nodev, nosuid, journaled, noowners, mounted by sg-mini)
/dev/disk5s3 on /Volumes/ROLEB  (apfs, local, nodev, nosuid, journaled, noowners, nobrowse, mounted by sg-mini)

nobrowse means Finder does not list it. The volume is mounted, ls and touch both work, and diskutil info reports Mounted: Yes next to Volume Read-Only: No. Every tool tells the truth and the desktop still looks empty.

So which roles do this? diskutil apfs addVolume accepts twelve role letters, B|R|V|I|T|S|D|E|X|H|C|Y, and defines none of them. The man page never mentions -role in its addVolume examples, and the changeVolumeRole usage text says only that you "should be aware of any specific system usage or legal combinations of role flags." I made one 6 GB container and tried all twelve:

Letter	Role reported back	Finder
B	Preboot	hidden (nobrowse)
R	Recovery	hidden
V	VM	hidden
I	Installer	hidden
T	Backup	visible
S	System	visible
D	Data	visible
E	(accepted, role name blank)	visible
H	Hardware	visible
C	Time Machine Sidecar	hidden
X	rejected: Error: -69624: Unable to add a new APFS Volume to an APFS Container
Y	rejected, same error

This table corrected me twice while I built it. I first read -role B as Backup and nearly wrote that backup volumes are hidden by design. The control run says B is Preboot, the real Backup role is T, and T volumes are visible and writable. The hidden backup-adjacent role is C, Time Machine Sidecar. That matters because T9 owners circulate the opposite folk explanation: one Apple Discussions reply asserts that "a backup drive cannot be used for other purposes so there is no user write permission." I could not reproduce read-only behaviour from the role flag alone. Both the B and T volumes accepted writes.

Scope limit: these are synthetic volumes where I set the role flag directly. I am not claiming they are identical to what Time Machine builds on a real drive, and I cannot check — this machine has zero backup destinations configured.

Layer 3: the mount that gets refused

Here is where the exFAT experiment produced the result I did not expect. I formatted a 2 GB sparse image as exFAT, wrote files to it, then zeroed its entire first sector and read it straight back to confirm the write had landed. It had. Then I mounted it:

$ diskutil mount disk4s1
Volume LABDRIVE on disk4s1 mounted
EXIT=0

The mount succeeded, and re-reading sector 0 afterwards showed the boot sector back: OEM string EXFAT, signature 55aa, byte-identical to the copy at sector 12. macOS rebuilt it during the mount. Microsoft's exFAT specification puts the Main Boot Region at sectors 0 through 11 and the Backup Boot Region at 12 through 23, and states that the backup "aids recovery of the exFAT volume in the event of the Main Boot region being in an inconsistent state." That recovery is not theoretical. It happens silently, which means a damaged boot sector is not why your exFAT drive refuses to mount.

Zeroing both regions, all 24 sectors, is what finally breaks it:

$ diskutil mount disk4s1
Volume on disk4s1 failed to mount
If you think the volume is supported but damaged, try the "readOnly" option
EXIT=1

The readOnly option it suggests fails identically. And note what the information layer keeps saying while the filesystem is rubble: diskutil list still labels the partition Windows_NTFS and diskutil info still reports File System Personality: ExFAT. Only the volume name goes blank.

That Windows_NTFS label is its own trap, and it is there before anything breaks. A healthy, freshly formatted exFAT volume prints as Windows_NTFS in diskutil list, because the MBR partition type byte is 0x07, which NTFS and exFAT share. I read it off the disk to be sure — offset 0x1C2 of the first sector is 07. People troubleshooting a Mac drive see "NTFS", conclude macOS cannot write to it, and start solving the wrong problem.

-69845 is a wrapper, not a diagnosis

Running First Aid on the broken exFAT volume produced the code that sends people to search engines:

Alternate boot region is invalid
The volume  could not be verified completely
File system check exit code is 211
Restoring the original state found as unmounted
Error: -69845: File system verify or repair failed
Underlying error: 211

Then I broke an HFS+ volume and an APFS volume the same way and compared:

Filesystem	First Aid code	Underlying	What repairVolume did
exFAT	-69845	211	failed; volume still will not mount
HFS+	-69845	8	repaired successfully, mounted immediately
APFS	-69564	—	never reached fsck: no container reference

Two volumes, identical error code, opposite outcomes. One came back with a single command; the other is gone as far as macOS is concerned. What separates them is the Underlying error line, the fsck exit status passed through, which almost nobody quotes when asking for help. Both threads I read follow that pattern: an Apple Discussions thread on -69845 with underlying error 8 collected years of replies and closed without a general answer, and in a more recent -69845 thread the real diagnosis sat in the lines above the code, where fsck complained about a doc-id tree record with no inode referencing it.

The numbers are undocumented on both sides. man fsck_exfat and man fsck_hfs say only that "the exit status will be non-zero." man diskutil mentions error codes zero times. Meanwhile the strings themselves ship on every Mac: DiskManagement.framework carries a localization table with 716 English entries across 41 languages, including the exact sentence "File system verify or repair failed." Apple ships the vocabulary and withholds the index.

One trap if you search the number: errno 8 is ENOEXEC, "Exec format error", which is why the older thread renders fsck exit code 8 as Underlying error: 8: POSIX reports: Exec format error. That is a numeric collision, not a clue. My 26.4.1 output prints the bare number; I did not chase down when that changed.

What to actually run, in order

1. system_profiler SPUSBDataType. Zero bytes means the drive never enumerated. Stop here and change cables or ports.
2. diskutil list external. If the disk is listed, the hardware is fine. Ignore the TYPE column; Windows_NTFS may well be exFAT.
3. mount | grep disk and diskutil info diskNsM. If it says Mounted: Yes and the flags include nobrowse, nothing is broken. The data is reachable by path.
4. diskutil verifyVolume diskNsM. Read the Underlying error line, not the -69845. That is the number worth searching, and the fsck lines above it are the actual finding.
5. Only then choose between repair and recovery. For exFAT, macOS failing does not mean the volume is lost: one T9 owner hit -69845 on a nearly full exFAT volume and recovered the data on a Windows machine.

Where this lands if you are still choosing a drive

The buying lesson is about format, not brand. On this evidence an exFAT volume damaged past its backup boot region is a dead end for the macOS repair tools, while the HFS+ case came back in one command. Formatting a Mac-only drive as exFAT buys portability you never use and the worst recovery story of the three.

The drive I keep linking in this series is the Samsung T9 2TB, and I should be plain: I do not own one. Every claim about it comes from the spec sheet or owner threads, and those threads include the failures above, an exFAT volume that needed Windows to recover and read-only confusion I could not reproduce. Samsung's own forum has a T9 random-disconnect thread I can see exists but cannot read, since it returns 403 to scripts, so I am not citing its contents. I am not quoting a price either: Amazon's product page returns 200 but renders no price or product title to a script, and a stale number is worse than none. The comparison behind picking it is in the T7 Shield versus T9 breakdown, and the shortlist in what I would buy for Time Machine. Those are affiliate links; if you buy through one I earn a commission at no extra cost to you.

A drive that refuses to mount is cheaper to diagnose than to replace, and the diagnosis is free. What is not free is the hour lost because Apple prints a five-digit number meaning "something failed" and hides the one meaning "here is what failed." If a backup is what sent you here, the catalog behind that message has the same shape and I took it apart in Time Machine running out of space; the sizing side is in whether a 24/7 Mac server needs an external SSD.

How this was made: every command output above was produced on this machine on 2026-08-12, macOS 26.4.1 (25E253), against sparse disk images created with hdiutil and damaged deliberately by writing zeros to known sector offsets. No physical portable SSD was attached, which is why this article says nothing useful about cables, enclosures or power. The corruption is artificial and uniform, so a real drive's partial damage may produce different fsck results. Role behaviour was tested by setting APFS role flags directly, not by letting Time Machine create the volumes. Owner reports are linked inline and were read at their source; one Samsung community thread and the search summary claiming a pkill fsck workaround were both discarded after the originals failed to confirm them.