PDA

View Full Version : Macintosh HD won't unmount


JoBoy
01-29-2010, 03:35 PM
I'm asking this question here because Sandbox and Macintosh HD volumes share data.

In attempting to do routine maintenance, I booted from a current, bootable clone on an external Firewire drive. Using the clone's Disk Utility app, I performed Repair Disk and Repair Disk Permissions on the Sandbox volume. I then attempted to perform the same operations on Macintosh HD, but that volume would not unmount. I tried to do the same thing while booted from another clone and obtained the same results. I then booted from the Snow Leopard install disk and was able to perform both operations on both volumes without incident. I then booted from the external Firewire clone and attempted to use the installed Disk Warrior app. Rebuilding the directory on Sandbox went just fine, but Macintosh HD would not unmount. I then booted from the Disk Warrior 4.1 install disk and was able to rebuild the directories on both disks without incident. There is one other fact that may be useful. The installed version of Disk Warrior is 4.2. Since making that installation, the DW 4.2 DVD was scratched and cannot boot, so I was forced to go back to the 4.1 install disk to do the operations from an install disk. I'm using Snow Leopard 10.6.2 as my regular OS, but the boot OS on the DW 4.1 install disk is 10.5.6. Is there an SD! issue that would explain these results?

dnanian
01-29-2010, 03:38 PM
A Sandbox explicitly references and uses the files that are shared from the original drive.

JoBoy
01-29-2010, 03:59 PM
I know that. It's in the User Guide, but does it have anything to do with why Macintosh HD won't unmount? BTW, sorry for accidentally putting this question in the wrong forum. I'd move it if I knew how.

dnanian
01-29-2010, 04:03 PM
Yes. Items are shared from it, so the drive is busy.

JoBoy
01-29-2010, 04:04 PM
How can the drive be busy when the machine is booted from an external clone and the drive I'm trying to do maintenance on is the main internal drive?

dnanian
01-29-2010, 04:04 PM
You said you're using a Sandbox, right?

JoBoy
01-29-2010, 04:07 PM
Your answers are coming so quickly that I can't edit my previous questions fast enough to make them clearer<grin>.

See the edited version of my last reply.

dnanian
01-29-2010, 04:26 PM
Are you using a Sandbox or are you not using a Sandbox? If it's a Sandbox, it's sharing data with the original drive.

If you're not using a Sandbox, then name the backup the same as the original drive before you start up from it. That way, programs that reference the volume by name will default to the copy.

JoBoy
01-29-2010, 05:01 PM
I use Sandbox and Macintosh HD volumes on my main internal drive. All backups are done by copying Macintosh HD on the main drive to the backups located on two other internal hard drives and an external Firewire hard drive. The Macintosh HD volume will not unmount when I attempt to do maintenance on it while booted from other internal or external drives, but all of the clones of Macintosh HD do unmount. Among all volumes, there is only one named Sandbox and one named Macintosh HD. All others have unique names. There is no Sandbox going by another name. I have no problem with Macintosh HD when I boot from an install disk (OSX or Disk Warrior).

BTW, I apologize again for accidentally putting this thread in the wrong forum. I'd move it if I knew how.

dnanian
01-29-2010, 05:16 PM
I moved the thread for you.

The question here is if you've made a Sandbox. Naming the volume "Sandbox" doesn't mean it's a Sandbox. If you created it with the "Sandbox" scripts, it uses the original drive, too. That's the point of the Sandbox, and is what I've said above.

If it's not a Sandbox, and is, instead, a backup created with "Backup - all files", then if you name it the same as the original drive when you start from it, you should be able to unmount the other drive. If it's a Sandbox, though, you cannot unmount the original drive because it's in use, due to the shared files.

JoBoy
01-29-2010, 05:25 PM
It is a genuine sandbox created with sandbox scripts step by step from your user's guide. It is located on the same hard drive as the Macintosh HD volume. I know it shares data with Macintosh HD, but when I'm booted from another hard drive, internal or external, why would Macintosh HD on the main drive be "busy?" The boot drive is doing the work and it is NOT a sandbox.

dnanian
01-29-2010, 05:46 PM
Was the other hard drive created with SD! from the original drive?

JoBoy
01-29-2010, 06:43 PM
Yes. After partitioning the other drives (internal and external), and naming the newly-created volumes, I used SD! to clone the original Macintosh HD drive to each of the new volumes using Backup-all files and Smart Update. All subsequent backups, scheduled or not, were done the same way. But this answer is more complex than that. I later had a main hard drive failure. While waiting for the new main drive to arrive, I operated off Backup01 as though it were my main drive, but there was no sandbox on it since it was originally a backup clone that was pressed into service until the new drive arrived. I made several backups from Backup01 to the other volumes on the computer, but there was no sandbox on the computer at that time. After the new main hard drive arrived, I partitioned it into two volumes. They were named Sandbox and Macintosh HD. I cloned the then-current Backup01 to Macintosh HD using Backup-all files and Smart Update. I then carefully followed the users guide to create a real sandbox on the volume named Sandbox. I chose "Sandbox-shared users" because I wanted to isolate the applications as well as the OS. After creating the sandbox, I booted from the Snow Leopard install DVD and used Disk Utility to first Repair Disk and then Repair Disk Permissions on every volume on the computer except the Time Machine volume. I leave that one alone fearing that I'll do more harm than good if I try any kind of maintenance. I then ejected the OSX install disk and booted from the Disk Warrior install disk. I checked the hard drives, examined the files, and rebuilt the directory on every volume on the computer, internal and external, except Time Machine. Everything worked fine, but I didn't try to use the Disk Warrior app that was installed on the clones to rebuild the directory on Macintosh HD or Sandbox for a week or two. Then I tried to do it and found that Macintosh HD would not unmount when I booted from a clone located on a separate hard drive. This answer is too long. Do you want me to do another post to describe one other problem that may be related to this or should I go to email?

dnanian
01-29-2010, 06:45 PM
OK. Again, before starting up from the clone (NOT a sandbox), name it "Macintosh HD". Then start up from it. I can only say this so many times...

JoBoy
01-29-2010, 07:55 PM
OK. Again, before starting up from the clone (NOT a sandbox), name it "Macintosh HD". Then start up from it. I can only say this so many times...
OK. But it's counterintuitive. That's why I kept asking. Now, should I restore its regular, unique name when I have finished using it for maintenance?

JoBoy
01-29-2010, 08:36 PM
OK. But it's counterintuitive. That's why I kept asking. Now, should I restore its regular, unique name when I have finished using it for maintenance?

I tried it and it worked!, but it takes some fancy footwork to figure out in advance where the drive is located on the System Preferences startup disk window so you don't pick the wrong one after the name has been changed. Also, it was helpful to verify that the correct one was the boot drive after it booted. Disk Utility made that possible by selecting each name and looking at the mount point to see which one was the boot drive. Changing the name back after doing maintenance seems essential to avoid continual confusion.

Thanks a lot for the assist. I hope your programmers figure out a way to prevent the need for this workaround.

dnanian
01-29-2010, 11:09 PM
Yes: I understand this feels a bit counterintuitive, but some programs store the volume name with the file and may reference files on the original drive if it's present.

dnanian
01-29-2010, 11:10 PM
There's nothing we can do to work around this, sorry.