5 Replies Latest reply: Mar 4, 2008 11:01 AM by George Machen
George Machen Level 1 (20 points)
Some of us over on the SuperDuper! vendor's support forum have difficulty unmounting a FireWire disk to which a bootable backup of a Mac OS X Server volume has been cloned.

This never occurs when making a bootable backup of a regular Mac OS X client volume. Is there something peculiar to Mac OS X Server that would make it difficult to unmount when it resides on an external drive, and from which the Mac of course hasn't been booted, or made a share?

You can read all the gory details over there:
http://www.shirt-pocket.com/forums/showthread.php?p=17968

But the salient points are:

- Even if the drive is moved over to and mounted on a Mac booted from regular Mac OS X client, it will not unmount in the Finder or in Apple Disk Utility.

- Doing in Terminal:
sudo lsof | grep /Volumes/[volumeName]
... reveals that no processes are running from the offending drive.

- It's not SuperDuper! per se; even a clone done with Apple Disk Utility or Carbon Copy Cloner 3 behaves the same.

- One curiosity is that if the drive has been "touched" in a certain manner, it will unmount once & only once; thereafter following the next re-mount it resumes being unable to unmount. Those two circumstances are 1) right after the clone is performed, and 2) right after a Verify Disk Permissions is done on it in Apple Disk Utility.

Has anyone else actually encountered this inability to unmount a Mac OS X Server backup volume, and if so, were you ever able to identify the culprit?

Intel G5 tower, Mac OS X (10.4.11)
  • DaddyPaycheck Level 6 (16,030 points)
    Hi George Machen-

    Are you sure the drive works otherwise?

    LaCie drives have been known to have power supply bricks fail intermittently with no other symptom except stuff like this. The drive still spins up and the little blue light comes on and it works most of the time.

    Could touched mean static discharge?

    Luck-

    -DaddyPaycheck
  • George Machen Level 1 (20 points)
    Let me pose the question this way:

    Has anyone out there cloned a bootable backup of Mac OS X Server with SuperDuper!, Apple Disk Utility, or Carbon Copy Cloner, and been able to unmount the destination FireWire drive?
  • DaddyPaycheck Level 6 (16,030 points)
    Yes.

    However, the answer is no if the server was booted from the drive.

    -DaddyPaycheck

    Message was edited by: DaddyPaycheck

    Message was edited by: DaddyPaycheck
  • paul@macsupport.com Level 1 (0 points)
    try this:

    sudo umount -f /<Volumename>

    but be sure there's nothing really open or it might kill the file. I did this when I was trying to format a drive and it wouldn't unmount--I had been using Synchronize Pro X and got the dreaded "can't unmount volume".
  • George Machen Level 1 (20 points)
    Thanks for the suggestion, Paul. But I'm concerned about the "f" qualifier, which is a force-unmount (which of course was your point about making sure there are no open files). I'm afraid of possibly doing some damage in the absence of knowing why the system insists that the drive otherwise is "in use" when attempting to unmount.

    As I said earlier, an lsof reveals that there are no open files, and I double-checked that nothing on that drive is being shared, so what I'm really seeking is someone who's actually experienced this problem and found the culprit.

    You see, we're running three rotating bootable backups per week, and one of my people regularly needs to be able to swap drives in-and-out to take one off-site. It presents a problem to connected users to have to restart the server just to catch the short window when the dive's plug safely can be pulled.

    But what's really piqued my interest - and might provide a clue to others in diagnosing this - is the aforementioned curiosity that the drive temporarily is unmountable in at least two circumstances:
    1) immediately after a backup with SuperDuper!
    2) immediately after a Verify Disk Permissions in Apple Disk Utility
    ... but if it's re-mounted it promptly ceases being unmountable again.
    Strange!