When you delete a file on your MAc, OS X only removes the index entry for the file, which tells the system the file’s contents are free to be overwritten; however, the data still technically remains and may be recovered using specialty software. To prevent this, you can use a secure-erase option that overwrites files you delete, but while this has been a built-in option in OS X, Apple has removed this in at least the initial release of El Capitan.
The reasoning for this change is that it could not be guaranteed to work with some of the storage hardware used in various Mac systems. Unfortunately there appears to be no workaround for this issue, so instead of giving users a false sense of security, Apple has removed this feature from OS X. However, there are still options you can use to invoke similar secure-deletion options to prevent recovery of sensitive files:
Some maintenance utilities for OS X like Cocktail and CCleaner include secure file deletion options. If you have one of these available, then you can use it to target and delete files securely.
2. The Terminal
While Apple removed secure-erase options from the Finder, Terminal commands still exist that can be used. The first is the classic “rm” file removal command, augmented with the “r” flags for recursive deletion of folders, and “P” to implement an overwrite of the removed files:
rm -rP /path/to/file-or-folder
For more thorough secure deletion, you can use the “srm” command (for secure rm) along with similar options to recurse (r), force confirmation (f), and then be verbose to show information about files being removed (v). The second flag (-s) is important for the type of secure erase to perform:
srm -rfv -s /path/to/file-or-folder
In this command, -s will perform a single-pass erase, but you can use -m for a seven-pass erase, or -z for overwriting with zeros. If you do not use this second flag, then the command will perform a 35-pass erase.
Erasing free space on a drive
In some cases, you might want to run an overwrite routine on the free space of a given drive, but unfortunately Apple has also removed options to erase free space in the new version of Disk Utility, which may leave you wondering how to do this. Granted on SSD devices, secure-erase can impact the life span of the drive, but it may still be useful for HDD devices.
To do this in El Capitan, you can again use Terminal commands:
diskutil secureErase freespace LEVEL /Volumes/DRIVENAME
In this command, change LEVEL to a number of 0 through 4, where 0 is a single-pass of zeros, 1 is a single-pass of random numbers, 2 is a 7-pass erase, 3 is a 35-pass erase, and 4 is a 3-pass erase (note all non single-pass options may take a while to complete). Change DRIVENAME to the name of the mounted drive (encase the name in quotes if it contains punctuation or spaces), and then press Enter to run the command.
How to sanitize a disk and be sure it is really wiped out (mostly useful for SSD):
1. Fill duplicating for ever a big monolithic file like a movie until no space is left to duplicate further.
2. Continue filling duplicating smaller files until 0 kb is left.
Is there an application (GUI) to do steps 1 and 2 above?
If you are really worried about someone recovering deleted files your best best is to enable FileVault.
True for drives you use regularly and with specific systems, but often you may have a drive you’ve used with another system (esp. a Windows system), or are just borrowing from a friend, and wish to remove a file and then securely delete it. These approaches will allow for this without needing to rely on full encryption.
Of Subject: Just wondered if any one knows how to somehow institute copy and move in El Capitan. Seems one of the major drawback running a Mac compare to Windows. It’s time saver when moving files around but on Apple never seems to do anything about.
In OS X you can select files and press Command-C to copy them, followed by pressing Command-V at your desired location to paste and copy the files. Alternatively you can press Option-Command-V to paste and move the file without copying.
If you want to move a file to another volume or disk without copying it you can press the Command key while dragging the file.
Thanks for the keyboard commands. I was using an app that (Xtrafinder) in Yosemite that provided a way to move them with a mouse click or using the trackpad but with the installation of El Capitan it broke the app and I’m not sure if the developer is going to update it in the future, so I guess it back to the keyboard to move or copy files
You can also use click and drag to move an item in the Finder, and if you hold the Option key when doing so, you will copy the item to the new location. This in conjunction with they hotkey shortcuts can make managing files a bit more fluid.
Noob question: can you explain in more detail, “…the ‘r’ flags for recursive deletion of folders”. I thought I understood the concept of recursion, but now I’m confused. If I’m targeting a specific folder for deletion, why would I need to set the recursion flag?
The “rm” command is built to only unlink/remove filesystem nodes (files and folders) that do not contain a subsequent hierarchy of child nodes. In the case of a folder, you may have additional folders or files within it, which will block the “rm” command from unlinking (removing from the drive’s index) the parent folder. However, the “rm” command is programmed with a “recursion” option (invoked with the -r flag) that will start a deletion function at the specified folder. This function will then traverse the folder’s hierarchy to first delete all child items before the command unlinks the parent folder itself.
The way this works is the deletion function internally lists all items in a folder, sorts them alphabetically, and then progressively unlinks them. If one of the items is another folder, then the function runs a copy of itself (recursion) that works on this new folders’ contents. The original function will wait for the child copy to complete before the original continues its work. The new copy will progress to delete files alphabetically in the child folder until another folder is encountered, where the recursion will happen again.
When the child folder is empty, the function acting on it (that was started “recursively”) will finish and return its results (ie, any encountered problems) to the parent function that called it. This allows the parent function to continue alphabetically until all files are removed from the hierarchy, all folders are unlinked, and the parent folder is finally empty so it can be removed.
You can imagine for a tree of 100 folders, you will have 99 paused parent functions that progressively (and recursively) started each other, which are waiting for the 100th one to act on its target folder. When its done, it will disappear and you will have the 99th function continuing to act on its folder, with 98 parent functions waiting. With no more folders encountered, each parent function will wait for its child to complete before continuing, resulting in the entire recursive tree of functions (built as folders in the folder tree were encountered) to collapse as they complete their tasks and delete the folders they are acting on. The result is the entire tree of 100 folders being deleted.
Great, thank you for the detailed explanation!
I’m trying to secure delete a file but don’t quite know how to use the commands alluded to above. For instance, what exact information do I need to include to make the following command work: rm -rP /path/to/file-or-folder. Dumb question but hey, what do I know? Where do I obtain the file information or the path/to/file-or-folder information to make it work? Is there an easier way for a non-techie to secure delete a file on El Capitan OS? Thanks!
With El Capitan, how does one wipe the internal HD in preparation for selling, or otherwise disposing of the Mac, without replacing the HD?
If you just want to dispose of the Mac, just pull out the hard drive and destroy it with a hammer or something. If you plan on selling the mac, just make a bootable installation flash drive of OS X, format your hard drive, install OS X and finally do a 3 or 7 pass secure erase of the free space.
I was thinking the same thing, I always wipe the internal drive when I’m getting a new machine, how is this done now?
Note that the 35 pass erase is no longer supported in OS X — & it never was intended by its author to do all 35 passes to begin with. For more about that, refer to https://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html
That is the seminal paper written by Peter Gutmann himself. The relevant info is in the epilogues.
Also note that multi-pass erases on solid state drives will increase wear on their memory cells, slightly shortening their usable life each time you do that.
Either way the ability to securely delete files easily, being lost from OSX is for me a deeply concerning issue. Confidential documents are encrypted using file vault but it’s the fact that something like this was removed with no warning to suit new systems that are currently a huge minority amongst users. It cannot have been that difficult to offer an opt in for those that can use it and deny the opt-in to systems that cannot. At least we then have a choice, rather than yet again, being faced with Apple’s monolithic approach to everything being the same and ignoring the needs of existing customers again.
For the “Erasing free space on a drive” part, can anyone confirm that this can be done on a drive that has files/folders that I wish to be retained? So I have items on the drive that I want to keep, but I’d like to “Erasing free space” as a form of drive maintenance.
Ideally I will have a backup of the drive, then attempt to Erase free space, but I also though asking here would get an answer quickly. Thank you in advance and thank you for the article.
Or you can use secureremove. A 3rd party app that includes 10 wiping algorithms and finder integration.
I’m erasing free space on drive as described above. I opted for using level “1” and so far 60% has taken 21 hours on my iMac.
As Alexander Pope famously wrote three hundred years ago, “a little learning is a dangerous thing.” As a journalist, technical writer, neurobiology lab technician, and “avid Mac user”, Topher Kessler has certainly learned a little about computer systems. Without a doubt, many people enjoy and benefit from his articles about Mac OS. But he would do a service to his readers by having them fact-checked by more qualified experts, or at least reviewing the topic on Wikipedia or StackExchange. Over the years I’ve noticed that his writing at times lacks depth, and fails to communicate important details, sometimes to the extent of leaving the audience with just enough knowledge to be dangerous. This article is a case in point.
With regards to the removal of “secure delete” functions from OS X, the article states: “The reasoning for this change is that it could not be guaranteed to work with some of the storage hardware used in various Mac systems.” But it fails to point out that this means *all* SSD, flash, and Fusion drives. That is, all USB sticks, and nearly every MacBook and most iMacs produced in the last five years – probably most computers running El Capitan, and hardly the “huge minority [sic]” Jon Champs asserts in the comments. This crucial missing fact perpetuates the “false sense of security” in users who think they are securely deleting files from SSD and flash drives, while only unnecessarily reducing the life of the drive.
It goes on to recommend “options you can use to invoke similar secure-deletion options to prevent recovery of sensitive files”. But none of the utilities or commands mentioned are effective with SSD drives. Doing a complete erase of all free space may overwrite some or all deleted sensitive files, but it’s not guaranteed. And attempting to securely delete individual files is unquestionably an exercise in futility. While it is pointed out that “on SSD devices, secure-erase can impact the life span of the drive”, there is no mention that it is also simply ineffective, and therefore worse than doing nothing.
It is true that the methods here may be useful for classic “spinning” hard drives, although “data leakage” through temporary and backup files, the OS X “Versions” system, and so on, may mean the effort is in vain. The description of options for multi-pass overwrites “for more thorough secure deletion”, also perpetuates an old security myth. It is a waste of time for any drive manufactured within the past twenty years or so, where a single-pass overwrite is entirely sufficient. In fact, “srm -s” is much faster than “rm -P”, which does a three-pass overwrite – two of which are pointless. If anything needs to be “more thorough”, it’s Mr. Kessler’s research and advice in this article.
Alexander Pope also said “Those move easiest who have learn’d to dance.” Apple has removed important options for their users and guys like me are simply looking for best methods to dance around this issue. When you say “doing nothing” is better than the options given by Mr Kessler it makes me wonder if you work for NSA. If you understand this technology please submit your best options for the millions of mac users like me who have hard disk drives but have upgraded to El Capitan.
If the article made it clear that the methods presented are only useful for hard disk drives, I would not have bothered to comment. Even then, a brief mention of data leakage issues through autosave buffers and so on, and the advantages of encrypted disks and dmg files, would have been appropriate.
Apple removed the options because it is simply not possible to securely delete unencrypted files from any USB flash, SSD, or fusion drive, using any software tool. See Wei et al, “Reliably Erasing Data From Flash-Based Solid State Drives”, 2011. Even after multi-pass file overwriting, or 100 times erasing free space, upwards of 80% of deleted files could still be recovered.
My point is, that for a widely-followed tech blogger like Kessler to offer detailed instructions on how to “dance around this issue” by using the exact same useless tools from the command line – without clearly explaining this fact – is negligent. Doing nothing, and knowing that your files are not secure, is better than do-nothing options that make you think they are.
Thanks for sorting me out. I have been irritated by the secure erase thing in previous versions. Now they take it out of the GUI entirely, but then the current functionality in the Terminal actually gets the job done, and I’m a Unix guy anyway. 😉
I also suffer bereavement (sniff) at losing the OS X free-space-wipe feature after upgrading to El Capitan from 10.7.5 Lion. Being more than vaguely familiar with OS X Terminal I searched for and found a few posts explaining how to run secure free space wipe from cmd line, and let ‘er roll. It failed, of course, just like the others reported, with the error code 69847, a POSIX-permissions failure. The process was run from a standard user account without the benefit of super-user sudo.
Sudo apparently can’t be used in a standard account because of permissions issues. In fact, OS X gets downright haughty when you try, failing with the standard user’s name and PW and then entering the admin name and password, upon which it comes back with the threat, ‘this will be reported.’
Okay. Let me go change these pants and then. . . from the admin account, where I seldom go, I ran secure free space wipe #2, which also failed with the same error. All those hours, wasted.
My disk is encrypted, but it isn’t out of concern for privacy, nor a great emphasis on security that makes me want to erase free space. . . it’s the fact that deleted files build up over time and slow everything down. The processor still has to manage deleted material even though it’s invisible to the user. It is still on the drive, though just ‘skin deep’ where it can be oh-so easily lifted up via software. Are you listening?
. . . Not a good idea to leave your deleted stuff hanging around, know what I mean?
So far I’ve seen multiple nuvi posts and a few replies from those who have experience in Terminal commands; yet my early 2011 MacBook Pro 2.6GHZ i7 with the newest OS, El Capitan, simply will not cooperate with the advice given. All it seems able to do is say NO!
disk1 is the target disk; it is the only line entry under diskutil list that doesn’t evoke an initial error response. No, the error comes AT THE END of the many-hours-long process. No joy.
So the deal is, that nobody seems to know diddly about ways and means of wiping free space in El Cahuna. Hope I spelled that right.
If I were one of the honchos at Apple the first thing I’d undertake during the next Monday morning meeting would be that of discussing how fast an update to restore all the missing PERSONAL SECURITY FEATURES that have been removed from the new OS X could be hashed out for downloading.
Small wonder the very useful and long-standing utility, Cocktail no longer enjoys a presence at the Apple Apps Store. It offers not only secure delete but many other nuances of sensible computing within the OS X framework.
Apple wants to hand its users a media-oriented system with one intrinsic design and purpose that has little to do with security — shopping at the Apps Store and sending plenty of the long green stuff Apple’s way.
. . . Guess it’s easy to see that I am not on the Apple payroll, unlike MANY of those who post the all-too-familiar, half-baked replies to questions such as this commentary addresses.
Not ironically, this post is being entered using Ubuntu.