Much simpler than that. In a terminal window, enter the following command:
ls /Volumes
The list you get back has the potential targets for @ron 's command. For example, on my computer, I get:
12:17 PM ~ > ls /Volumes
Macintosh HD Time Machine
Because I have only my internal boot drive (Macintosh HD) and one external drive (Time Machine). So lets imagine when you run this command on your computer, the result is:
12:17 PM ~ > ls /Volumes
Macintosh HD Time Machine TroublesomeSSD
There’s the name of the drive you need to target for the cat command. So the complete command would be:
You can ignore the Preboot, Recovery, and 11.4-GB system volume. Those get set up by any modern macOS install, but they contain no private information at all. They can be found in exactly that configuration on any modern macOS system. The only partition you write private data to is the one with “Data” appended to it. That is the one you need to be concerned with.
Fortunately, due to the way Apple has firmlinked these partitions, you access that volume (/Volumes/CCC_Clone - Data) when you call /Volumes/CCC_Clone, as @fischej points out above. Since the /Volumes/CCC_Clone system partition is read-only (except for the macOS installer/updater), any of your attempts to write to it would fail anyway, so they cleverly get rerouted to /Volumes/CCC_Clone - Data by macOS right away. When you view any of the partition through Finder all of it will appear as one contiguous volume, again thanks to the way Apple has cleverly firmlinked these read-only and read/write volumes. You need to know exactly where to peek to see that some parts of it come from the read-only system partition while other are writable as they reside on the Data partition.
TRIM has been specified for the following interfaces:
ATA (including SATA) has the TRIM command
SCSI has the UNMAP command
SD/MMC cards (including eMMC drives) have the ERASE command
NVMe has a generic “dataset management” command that includes a “deallocate” sub-command
Of note is that USB does not include any such command in its mass-storage class (MSC) protocol. But an enclosure that supports USB-attached-SCSI (UAS) might support the SCSI UNMAP command.
So if you want to perform TRIM on a USB device, the device’s USB bridge chip will need to implement UAS and must be able to map the SCSI UNMAP command onto the appropriate command for the internal SSD (TRIM if it is SATA, or deallocate if it is NVMe), in addition to the internal SSD having support.
And, of course, macOS needs to send the command, which may require third-party software support and/or use of the trimforce command.
A Thunderbolt-attached drive is effectively a PCIe-attached drive, which greatly simplifies everything:
An NVMe device will appear as if it was directly connected to you motherboard (since NVMe is based on PCIe).
A SATA devie will appear as if it is connected to a SATA host adapter. Since SATA host adapters are very simple (typically just passing ATA commands to/from the connected device), it should support TRIM if the drive itself does.
After erasing the drive (either via a single-pass erase or reformatting it with TRIM), any residual garbage data would only be accessible by bypassing the SSD controller.
It’s definitely doable, but it would require either replacing the SSD controller’s firmware or removing the flash chips and connecting them to something else. I don’t know how hard this would be, but it is definitely not something that a service tech would do as a part of the work he’s being paid to do, since it would be time consuming, would probably render the SSD unusable, and might require specialized equipment.
Just to be sure I understand: you mean
1- fill up with date
2- erase with new encrypted format.
My point is that there is no encryption without erase, at least in disk util as far as I understand ? I don’t see a way to take a disk with data and just encrypt it.
the setup is Mac OS Catalina, 1TB primary drive and 2 TB external SSD renamed TroublesomeSSD (no spaces). The difference is size makes it easy to see which disk in the list is primary vs external SSD.
when I run diskutil list, I end up with a myriad of disks in the identifier column, synthetic and physical etc
based on my probably false understanding of your post, I opted to
diskutil secureErase 4 disk3s1 (because it’s the line with the actual name of the disk I want to delete) and ended up with the error message below.
Instead of just trying each disk in the identifier column one by one, by trial and error, I am opting to contact you yet again to understand the problem and then enter the right command.
Yeah, you need to run it on the entire disk, not just the APFS volume you interact with in Finder. In your case that looks to be either disk2s2 or just disk2. Never quite sure which one the command expects.
@Lucas043 A lot of the posts here are filled with useful information, aimed at correctly solving your problem with optimal efficiency. Namely, allowing you to exchange the drive with no additional cost, while being certain that the data is erased. This is natural, and one of the greatest things about the TidBITS community, we like to help people.
I’d suggest that that might not be the best way to go about resolving your situation.
If this drive has national security-level data, or other data with live-altering consequences if it gets out, then stop thinking. Physically destroy the drive, with a hammer, and accept the loss. It’s probably a business expense, and possibly something you can charge back to the client. You are, after all, performing a service for them, ensuring their data security.
Otherwise, evaluate the consequences of the data being released or captured. What’s the worst that can happen?
If it’s just embarrassing, you get a talking to, but you can show best efforts (like this post, and following some of the procedures outlined here) to protect the data, so you’re not getting fired or going to jail, then stop worrying about perfection. Zero out the drive using @Simon 's command line use of diskutil, and move on.
If it’s more serious, then stop thinking, and destroy the drive. It’s what, $200 to replace? Again, business expense, or maybe just an expensive lesson in always encrypting external storage. But it’s not worth agonizing over.
If you have kids, give them the hammer, and record them destroying it. Post it on the socials, you (and they) might go viral! ;-)
(I’m not saying $200 is trivial money, because it’s not. I’m just saying, peace of mind is worth something, and your time is worth something, and those probably add up to more than $200.)
Everything you say is correct and I greatly appreciate your post. It’s not national security data, just accounting data.
To your suggestion that I zero out the drive, I would simply add a simple measure which forum members taught me above, and that is cryptographic erase, which basically means encrypt and throw away the key which was probably implicit in your post.
I would just like to add that there is another dimension to my question, which is the learning experience.
Had I received a simple one line answer: “run this terminal command”, I would have understood nothing about the underlying hardware and software issues which in itself is not very safe.
Thanks to the contributions and detailed explanations of @fischej@Simon@Shamino@ace@Will_B@Will_B@ron and others, I have some grasp of the problem (much more than most people), and now have enough knowledge to at least be able to read, understand and follow new developments.
You have generously gone into a lot of detail about all of this, so I apologize for not fully understanding, but what I meant was, if you apply encryption to a drive that already has files on it, then throw away the key, are the files that had not been originally encrypted accessible only by bypassing the SSD controller – and therefore not a major security concern for most users – or are they more easily gotten at?
You need to know exactly where to peek to see that some parts of it come from the read-only system partition while other are writable as they reside on the Data partition.