11 Replies Latest reply: Jun 12, 2014 2:51 PM by hayzey
timgeek Level 1 Level 1 (0 points)
I turned on file vault on my MacBook with OS 10.6.4 and selected the secure erase option for the resulting empty space. The File Vault encryption process completed fairly quickly, but the secure erase has carried on for 48 hours and I'm just at 26% complete as per the security pane of System Preferences.

I'd like to stop the secure erase process. It seems like overkill, and as this computer (and the hard disk) are 4+ years old, I'm thinking the wear and tear on the drive is more than is necessary.

I've tried killing the secure erase process ("sudo kill -9 ...") but the process re-spawns.

My question: is there a safe way to stop the secure erase process after turning on File Vault? (I am fully backed up with Time Machine if that makes any difference.)

MacBook, Mac OS X (10.6.4)
  • johntodd Level 1 Level 1 (10 points)
    Seriously! This is a big issue. I'm at 1% of my erase, and it's been running for 9 hours. That means I have.. uh... the rest of my life to wait. Deleting my old home directory is not worth flushing the performance of my machine for a week or two. Plus, the stupid Spotlight search is running at the same time, making this machine completely worthless at the moment. So I had to take charge of my process destiny...

    I log in as root <gasp> (yes, I've been a sysadmin for 20+ years, I don't fat-finger things but I will often use my backups when I stick a wrench into undocumented routines like this) and then mangle the process manually by making the secure_erase program not exist any longer.

    cd /System/Library/CoreServices/loginwindow.app/Contents/Resources
    mv secure_erase BOGUS.secure_erase
    ps -ef|grep secure
    kill <process ID of the secure_erase process>

    Presto! Process stopped, and it won't re-spawn. This is a horrible, horrible hack. I wish there was some documentation as to where the secure_erase queue lived, or what daemon spawned it. However, Apple doesn't like people diddling under the hood, it seems. Anyway, to test things I re-named the process and it immediately went back to it's churning. So, at least it's reverse-able.

    I wish I knew what was going on here - does it track inodes? Do I risk crunching real objets if I now write things into those unoccupied sectors? Bah.

  • timgeek Level 1 Level 1 (0 points)
    Thanks much for your post. Very clever, but also very hack-y too.

    That said, I think the key part of your post is this:

    I wish I knew what was going on here - does
    it track inodes? Do I risk crunching real
    objects if I now write things into those
    unoccupied sectors? Bah.

    Apple, we'd love to know more about what's going on here. Or, at least provide us with a means stopping the secure erase (perhaps with a warning) from within the system preferences interface.

    As for my macbook? It's at 80% and I think I'm just going to let it run its course, wear and tear on my old disk notwithstanding.
  • johntodd Level 1 Level 1 (10 points)
    Ah-HA! OK, I've fixed the problem the right way now instead of the ugly method of renaming secure_erase, which was admittedly a hack until I had more time to look at things.

    The queue for secure_erase is stored in /var/db/fvsecureerase.jobs/ - you need to cd into that directory and look for the files there, and remove them. By deleting the numbered job, you will remove it from the secure_erase queue.

    HOWEVER, please look at the files first and then manually delete the file path listed, otherwise you will leave those to-be-destroyed files UNDELETED. This is probably NOT what you want. What happens is that secure_erase moves the "original" files into a new directory (in my case the file was named /Users/jtodd.10307331336706142097) and then secure_erase does it's magic on that directory and wipes out each file in a tedious, secure way. If you made a mistake and don't want to wait the 20 days for it to finish the tedious method, you can just "rm" it the old fashioned way. I typically pipe "yes" into the "rm -R" command since there are a lot of strange permissions things that rm asks about and I would otherwise spend an hour hitting "y" on every file about which it uncertain - hooray for UNIX pipes! For instance, this is a what I did (again, as root):

    sh-3.2# cd /var/db/fvsecureerase.jobs
    sh-3.2# ls -lsa
    total 8
    0 drwx------ 3 root admin 102 Nov 12 11:44 .
    0 drwxr-xr-x 51 root wheel 1734 Nov 12 11:44 ..
    8 -rw-r--r--@ 1 root admin 33 Nov 10 13:53 501
    sh-3.2# cat 501
    sh-3.2# rm 501
    sh-3.2# yes|rm -R /Users/jtodd.10307331336706142097
  • davidham Level 1 Level 1 (0 points)
    Hey, this was awesome! I've been fighting my way back after turning on, regretting, and turning off FileVault. I still had that secure_erase going and slowing everything down, but I tried what you said, and after a few tense minutes when it seemed to hang on that 'yes|rm' task, it ended, and everything seems to be working!

    Boy, as soon as this is all over I am SO going to make a SuperDuper clone. What a nightmare!

    Thanks again for the post.
  • JngmsterNL Level 1 Level 1 (0 points)
    Hey Guys,

    Yesterday evening made the stupid mistake to turn on FileVault and Erase secure home etc... And it's still never left the far left side of the progressbar. Also can't click anything, only a roundgoing progress indicator in the middle seems to be alive. Indicator says "Securely erasing home dir"

    I've read the above solutions, my question is, as i can't do anything right now is it wise to hard reboot? And what will happen then, will it reboot and have access to my documents? Can i then proceed with killing the process as described.
  • corvi42 Level 1 Level 1 (0 points)
    You can still get some of the benefits of secure erase without the massive drill-a-hole-in-my-head-and-salt-my-cerebrum pain of the default secure erase. Follow the above instructions, but use srm with the -s or -m options. srm acts just like rm, but will do a secure erase. The default is to do an insane 35-passes of overwriting each file with different patterned and random data. This is certainly effective at eliminating all traces of your files, but probably not really worth the effort (unless you're deleting military secrets or swiss bank account data). The -s option will do a single overwrite with random data, and -m will do 7 passes which is apparently a US DoD compliant option. I have deleted some pretty huge directories using -m and it is fast enough for me. I'm really not sure why apple decided they needed 35-passes, but you can't fault them for not being thorough.
  • corvi42 Level 1 Level 1 (0 points)
    PS - to use srm do the following:

    sh-3.2# cd /var/db/fvsecureerase.jobs
    sh-3.2# ls -lsa
    total 8
    0 drwx------ 3 root admin 102 Nov 12 11:44 .
    0 drwxr-xr-x 51 root wheel 1734 Nov 12 11:44 ..
    8 -rw-r--r--@ 1 root admin 33 Nov 10 13:53 501
    sh-3.2# cat 501
    sh-3.2# rm 501
    sh-3.2# srm -rfm /Users/jtodd.10307331336706142097

    (this uses the -m flag for 7 overwriting passes), change the last line to
    sh-3.2# srm -rfs /Users/jtodd.10307331336706142097

    if you want to do just a single pass.
  • mpeuser Level 1 Level 1 (0 points)

    I just browsed via Finder to /Users/ and dropped the <username>.<random numbers> "file" into the recycle bin. After entering my login credentials, FileVault told me the old home folder has been removed securely.

    Apparently this works too.

  • Forbidden Master Level 1 Level 1 (20 points)



    You've just saved me hours and hours of work hahaha.. Nice one.

  • smarchel24 Level 1 Level 1 (0 points)

    I've been at the secure erase for 24 hours I can't even see where the percentage is.  How do I see the percentage and how far it has erased so far?

  • hayzey Level 1 Level 1 (0 points)

    Great post guys - straight to the point.  You also have the honor of currently being one of only two google results for "fv_secure_erase.jobs"!


    For everyone's benefit, by 10.6.8 you can't cd into fv_secure_erase.jobs, even with sudo.  A quick "sudo chmod 777 fv_secure_erase.jobs" will get around that.  All of the other commands also require sudo.