Sparce Image fails to umount

[Airbusky]

Backing up my Powerbook to a Firewire hard drive. Everything goes fine until the very end and then I get this error in the log. (see below)

The sparceimage is still on the firewire drive after manually dismounting it.

How can I correct this error and is the manually dismounted sparceimage still usable?

Thx.


|10:20:19 AM|Info| PHASE: Conclude Target Setup
|10:20:19 AM|Info| ...ACTION: Finalizing "Powerbook.dmg" session
|10:20:19 AM|Info| ......COMMAND => Unmounting /Volumes/Large Marge/Powerbook.dmg from /tmp/SVUmount
|10:20:23 AM|Info| hdiutil: couldn't unmount "disk2" - error 49153
|10:23:57 AM|Error| rm: /tmp/SVUmount: Resource busy

[dnanian]

Airbusky -- do you happen to have Norton AntiVirus running on that machine?

[Airbusky]

Yes, I do have Norton running. Is there a work around?

[dnanian]

I strongly suggest disabling Norton AutoProtect during a backup. NAV will try to scan every single file you're copying for viruses which is wasteful, slow and prone to crashing...

[Airbusky]

Thanks, That fixed the problem.

[mnc042]

Sorry to dredge this topic up from a while back, but suddenly my SuperDuper won't unmount my sparseimage.. suddenly started happening, after SD working fine for a year or so.

I do NOT have any AV or disk-scanning utilities installed, and I have two scripts that run at night, one fails this way, the other one does not.

Tail of the log shows the same error mentioned here:

| 04:31:16 AM | Info | PHASE: 3. After Successful Copy
| 04:31:16 AM | Info | ...ACTION: Restoring Spotlight state on Backup-Storage
| 04:31:16 AM | Info | ......COMMAND => Restoring Spotlight search indexing state on Backup-Storage
| 04:31:16 AM | Info | ...ACTION: Unmounting Backup-Storage
| 04:31:16 AM | Info | ......COMMAND => Unmounting '/Volumes/Mirror1/Backup-Storage.sparseimage'
| 04:31:20 AM | Info | hdiutil: couldn't unmount "disk7" - error 49153
| 04:31:20 AM | Info | PHASE: 4. And Finally...
| 04:31:20 AM | Info | ...ACTION: Quitting SuperDuper!
| 04:31:20 AM | Info | ......COMMAND => Quitting SuperDuper!
| 04:31:20 AM | Info | Copy complete.

But the other one, that runs first earlier in the morning, works fine:

| 02:15:46 AM | Info | PHASE: 3. After Successful Copy
| 02:15:46 AM | Info | ...ACTION: Restoring Spotlight state on Backup-Storage2
| 02:15:46 AM | Info | ......COMMAND => Restoring Spotlight search indexing state on Backup-Storage2
| 02:15:46 AM | Info | ...ACTION: Unmounting Backup-Storage2
| 02:15:46 AM | Info | ......COMMAND => Unmounting '/Volumes/Mirror2/Backup-Storage2.sparseimage'
| 02:15:47 AM | Info | "disk7" unmounted.
| 02:15:47 AM | Info | "disk7" ejected.
| 02:15:47 AM | Info | PHASE: 4. And Finally...
| 02:15:47 AM | Info | ...ACTION: Quitting SuperDuper!
| 02:15:47 AM | Info | ......COMMAND => Quitting SuperDuper!
| 02:15:47 AM | Info | Copy complete.

Any ideas? I am worried that one of the disk images is not reliable, thus my backups might not be working well..

Thanks in advance!

\marc

[dnanian]

Hm. Well, that generally means something has a file open on the image, marc. I don't think it means the image isn't reliable. Does it eject in the morning manually?

[mnc042]

Originally Posted by dnanian

Hm. Well, that generally means something has a file open on the image, marc. I don't think it means the image isn't reliable. Does it eject in the morning manually?

Hi and thanks for the reply!

Yes, in the morning I can just manually eject the image. I'm fine with that, but the engineer in me is (probably unnecessarily) curious about why it's happening. :-)

If the image is not in jeopardy then I suppose I can be content with ejecting it manually in the mornings. Just curious as to why it suddenly started happening.

\marc

[dnanian]

I can't answer that, except to suggest that *something* outside of SuperDuper! has a file open on the volume. You can try to figure out what it is by running "lsof" soon after the eject fails...

[mnc042]

Originally Posted by dnanian

I can't answer that, except to suggest that *something* outside of SuperDuper! has a file open on the volume. You can try to figure out what it is by running "lsof" soon after the eject fails...

Fair enough. I'll give it a try and see what I can get.

If I find out the problem I will be sure to update this thread for future searchers. :-)

Thanks!

\marc