Apple Event: May 7th at 7 am PT

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Securely erase Free Space

Does anyone notice that after you use Disk Utility to erase free space, the mac slows down as a whole.

Boot times and shutdown times have extended by a massive difference, Also when shutting down i see the spinner on blue background "every single time"

I'm jumping to the conclusion of secure erase as the mac never did this before i started this process.

Secure erase does finish, it does not hang or anything. the free space that is securely wiped, is restored to use. However, the entire mac is just slower as a whole afterwards.


I'm just wondering if anyone else has experienced the same.

Message was edited by: Mac_101

Intel Macbook Unibody (Late 2008), Mac OS X (10.6.5)

Posted on Dec 1, 2010 12:47 AM

Question marked as Best reply

Posted on Dec 1, 2010 2:53 AM

This is such a niche issue in my opinion but I have suffered it too.

I know EXACTLY what you are talking about, the little spinner for ages when shutting down.

It's due to an issue where OS X sets incorrect group permissions on a file during the secure erase.

And trust me googling my Mac won't shut down fast will get you no where!

In the console you'll probably see things like:

Can't create kext cache under / - owner not root..


Here's the SOLUTION, get back to me and let me know if it worked...



just open the the terminal and type: "*sudo chown root:admin /*" without quotes and boom fixed!


Regards,
John

PS- just a little background on this, OS X trys to create caches for the kernel and other system elements. Sometimes the UNIX permissions and group rights get muddled up by certain operations, like erasing free space and also using apps to clear the caches like Onyx. Running a 'Repair disk permissions' as some will tell you to do DOES NOT fix this issue. you must run this command in terminal.

This solution took me about 3 months to find on google at the time!

I had a big thread on this on MacRumors if you try to find it there it has even more background, my name there is JohnAlan 🙂
18 replies
Question marked as Best reply

Dec 1, 2010 2:53 AM in response to Community User

This is such a niche issue in my opinion but I have suffered it too.

I know EXACTLY what you are talking about, the little spinner for ages when shutting down.

It's due to an issue where OS X sets incorrect group permissions on a file during the secure erase.

And trust me googling my Mac won't shut down fast will get you no where!

In the console you'll probably see things like:

Can't create kext cache under / - owner not root..


Here's the SOLUTION, get back to me and let me know if it worked...



just open the the terminal and type: "*sudo chown root:admin /*" without quotes and boom fixed!


Regards,
John

PS- just a little background on this, OS X trys to create caches for the kernel and other system elements. Sometimes the UNIX permissions and group rights get muddled up by certain operations, like erasing free space and also using apps to clear the caches like Onyx. Running a 'Repair disk permissions' as some will tell you to do DOES NOT fix this issue. you must run this command in terminal.

This solution took me about 3 months to find on google at the time!

I had a big thread on this on MacRumors if you try to find it there it has even more background, my name there is JohnAlan 🙂

Dec 1, 2010 3:58 AM in response to Community User

I've never heard of such an issue, and would have to assume that there was something wrong in the first place and secure erase made it worse. Did you [repair the hard drive with Disk Utility|http://support.apple.com/kb/TS1417] (or at least verify it) prior to doing the secure erase? If not, try that now. If there are problems, the computer may not have been able to correctly identify which space was actually free, and you may have just securely erased some small portions of the system.

As for JohnAllanWoods' suggestion, it seems unlikely to me, but then so many other things that have turned out to be true did as well. One suggestion, though... there's a quick and easy test to see if you need to do what he is suggesting. Just type the following in the Terminal:


ls -al /


The very first line and gets spit out (you'll have to scroll up to see it) should look like this:


drwxrwxr-t@ 31 root admin 1122 Nov 25 05:43 .


If it says something else where mine says "root" and "admin", then you'll need to run the command John gave you. Otherwise, there's no point in doing so, and mucking around with commands like that in the Terminal if you don't know what you're doing can be dangerous.... one typo can sometimes spell disaster.

Dec 1, 2010 6:05 AM in response to thomas_r.

This and many many others, I swear to god, I'm a professional software developer myself, and I do try and report these kinda issues, but if you take for example the rediculous bug in the flash player released with 10.6.5 where it HARD crashes my 2010 MBP on some flash enabled sites, but doesnt with the version that shipped with 10.6.4 (Flash Plug-In 10.0.45.2), I just give up.

I think they have very high quality software and hardware (that's why I use Apple's stuff) but I have to wonder how some of this stuff goes unnoticed in basic test.

Message was edited by: JohnAlanWoods

Dec 2, 2010 6:31 AM in response to thomas_r.

I know the solution is solved, but just a quickie in regards to the reason why this happens

Why does secure erase stuff up permissions ...?

To me, permissions are changed during upgrading or manual change to files.... I see it has nothing to do with secure erase, As i understand it anyhow, all secure erase would do is create an image, fill the file with zero, then delete the image. That should really be it shouldn't it ?

In any case, i've sent feedback via Apple feedback form as a bug.

Weather it'll get fixed..... Thats always a question.

Dec 2, 2010 10:38 AM in response to Community User

The only workaround I have found other than resetting permissions is to use a different wipe
program such as bcwipe. Even the command line version (diskutil) will change the perms on
the boot volume.

This is not a new problem, it has existed at least since 10.6.0, and I believe it was a problem
even in 10.5.x, although it didn't effect performance noticeably in 10.5.

Dec 4, 2010 2:26 AM in response to JohnAlanWoods

I have found a solution, but only for those souls who use Terminal.

Open Terminal;
Before running the diskutil erase freespace command,
run this command:
sudo -s

Now you are running a root shell.
From the root shell run:
diskutil secureErase freespace 0 /

Running under the root shell, diskutil will not
mess up the boot drive ownership perms.

You can set an alias or create a bash script so
you won't have to type out the command every time.

Here is link to download the bash script I use:
http://azlist.info/kj/support/erase.zip
#Run it from a root shell and ownership will be preserved#

Jun 10, 2011 4:03 AM in response to Community User

Could it be that a TM restore onto a new disk also messes up ownership of "/" ?


After installing a Intel 320 SSD and restoring from TM, boot times were initially very low, like 10 seconds, but after a few days, went into the 30-40 secs region. I checked Console Logs and indeed I suddenly got the "Can't create kext cache under / - owner not root." warning. "ls -ld /" confirmed that myself was the owner of / and not root, so a quick


sudo chown root:wheel /; touch /System/Library/Extensions


fixed the issue. The latter command rebuilds the kext cache. Once /System/Library/Caches/com.apple.kext.caches/Startup/ has been updated, reboot and enjoy a faster system.

Securely erase Free Space

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.