View Full Version : Target volume not unmounting
I'm not sure when this started happening but my target volumes are no longer unmounting at the end of a scheduled smart update. SD mounts the volume fine and the copy is ok, but does not unmount it. This did use to work.
Leopard 10.5.8 and SD! 2.6.1
dnanian
10-03-2009, 08:35 AM
When did it work previously? With 2.6.1? Have you changed anything? The drives should unmount when SuperDuper! exits, but we don't "force" unmounting: we "request" an unmount. If Spotlight (or anything else) is busy on the drive, they will not unmount...
I don't think it has worked in the current version which I've had running on 10.5.7 and 10.5.8 - so It also seems unrelated to the OSX version.
Each night I schedule smart copy of 2 volumes - one a boot and the other a data volume. Neither target is mounted. The copies work but both volumes are left mounted.
This definitely worked at some point in the previous version of SD. I can't say exactly when it started not working as I had my external drive powered off for a few weeks.
I'm also not getting Growl email notifications anymore - have it set to MailMe for all SD! activities - is there any other config required?
dnanian
10-03-2009, 11:01 PM
Have you deleted and recreated your schedules with v2.6.1?
Hi Dave,
I recreated the 2 schedules and let them run as scheduled at 2am. When I checked this morning the source Data volume had been unmounted, but the source System volume had not. The only diff in the 2 schedules is that the System copy has a post-run shell script that fixes the pre-bindings.
dnanian
10-05-2009, 08:35 PM
Is spotlight enabled for one and not the other? (Check in the Spotlight preference pane's "Privacy" tab.)
Hi David,
I've checked the Spotlight settings and it is disabled for both target volumes.
dnanian
10-05-2009, 09:23 PM
2.6.x automatically prebinds, so let's turn that off and see if it makes a difference.
David,
No, that didn't help. The System source remains mounted, the Data source was un-mounted.
dnanian
10-06-2009, 06:39 PM
I really don't know why that would be. I've tried to reproduce here with equivalent drive names, but it works fine... any logging in the system log that might indicate what's preventing the unmount?
Dave,
Absolutely no messages in system log from SuperDuper or anything else at the time the scheduled jobs run. Are there any options to have SD log messages?
dnanian
10-07-2009, 08:33 AM
No, no options to do this. Drop me a note to support; I want to get a bit more information about your setup.
Michael@wengam
10-07-2009, 10:59 AM
I am also experiencing this since 2.6/2.61 (whenever it was that we had to do schedules reset). I have one single-partition working drive in my MacPro and three internal drives that are each SD! clones (Daily, Weekly and Monthly). Previously SD! would automatically mount and unmount the internal clone drives, but since 2.6.1, although it mounts and backs up OK, the program is unable to also unmount the drives.
Incidentally, I had forgotten to put the clones in Spotlight's 'no search' privacy preference, but still have this behavior after doing so.
dnanian
10-07-2009, 11:10 AM
"The drives" meaning it does not unmount any of them, Michael, on quit?
Michael@wengam
10-07-2009, 11:25 AM
Only my main drive is mounted when I turn on the machine and log in, thanks to a login script that unmounts each other volume, one at a time, by name.
I said drives (plural) because I have seen the unmount fail for each my three scheduled SD! backups (Daily, Weekly, Monthly) to their respective drives.
Normally, I only have the main drive mounted and when SD! runs it mounts the one drive it needs, then unmounts it.
dnanian
10-07-2009, 11:29 AM
Is it consistent in its failure? That is, does it always fail to Daily/Weekly/Monthly but not for others?
Michael@wengam
10-07-2009, 11:38 AM
Not sure I understand the question. These three schedules are the only SD! backups I run to real internal hard drives. And all three now leave their target drives mounted after the SD! run.
My drives are actually called OSX_metal, Daily_OSX_metal, Weekly_OSX_metal and Monthly_OSX_metal
They occupy the four hard drive bays of my MacPro
dnanian
10-07-2009, 11:46 AM
Ah, internal drives. OK, quite different, and will look at it. I think we actually disable eject of drives that do not indicate they're ejectable in Finder (no eject symbol).
Michael@wengam
10-07-2009, 11:55 AM
I guess I could also run the same 'unmount drives' script that I run at login, after the SD! run (actually, it is an AppleScript that calls a Unix command). But I get confused by having pre- or post-run scripts, especially updating schedules, and I would prefer if the application could do this natively.
greengrass
10-07-2009, 07:08 PM
OS X 10.5.8, SD 2.6.1
I too have recently begun to see SD fail to unmount the backup drive (directly connected via firewire) after a successful scheduled backup. This used to work perfectly. I can't say for certain when it started but my guess is after upgrading to 2.6 or 2.6.1.
I just tried forcing a backup clicking "Copy Now" from the Scheduled Copies window. The target drive was not mounted when I started. The copy completed successfully, SD quit but the target was still mounted. I'm attaching the last few lines of the log which indicates a dyld shared cache error. Could this be part of the problem? Does the error message require action? If so, what?
| 06:36:21 PM | Info | PHASE: 3. After Successful Copy
| 06:36:21 PM | Info | ...ACTION: Making G4iMac Clone bootable
| 06:36:21 PM | Info | ......COMMAND => Blessing OS X System Folder
| 06:36:22 PM | Info | Successfully blessed Mac OS X folder on G4iMac Clone
| 06:36:22 PM | Info | ......COMMAND => Blessing OS 9 System Folder
| 06:36:22 PM | Info | Did not bless Mac OS 9 System Folder on G4iMac Clone because it does not exist.
| 06:36:22 PM | Info | ...ACTION: Updating prebinding on G4iMac Clone
| 06:36:22 PM | Info | ......COMMAND => Updating boot cache on '/Volumes/G4iMac Clone'
| 06:36:31 PM | Info | update_dyld_shared_cache[99606] current cache invalid because /System/Library/PrivateFrameworks/QuickLookUI.framework/Versions/A/QuickLookUI has changed
| 06:37:00 PM | Info | Successfully updated boot cache on G4iMac Clone
| 06:37:00 PM | Info | ...ACTION: Restoring Spotlight state on G4iMac Clone
| 06:37:00 PM | Info | ......COMMAND => Restoring Spotlight search indexing state on G4iMac Clone
| 06:37:00 PM | Info | Copy complete.
dnanian
10-07-2009, 07:16 PM
No, that cache logging is fine... was this particular schedule deleted and recreated after installing v2.6.x?
greengrass
10-07-2009, 09:14 PM
I deleted the schedule and created a new one when I updated to 2.6. I don't remember if I did it again when upgrading to 2.6.1.
My previous note said SD quit. That was a mistake on my part. It didn't quit, and shouldn't have, because I ran the scheduled backup from the Copy Now button while SD was open.
Ah, internal drives. OK, quite different, and will look at it. I think we actually disable eject of drives that do not indicate they're ejectable in Finder (no eject symbol).
Dave,
Ahh, this might be the cause. My drives are external connected with eSata - so they don't show as ejectable in Finder - they have to be dragged to Trash to unmount. Did you change this unmount logic because it did previously unmount my eSata drives.
dnanian
10-07-2009, 10:08 PM
OK: so, the drives are marked for eject, but won't eject until SD! is quit.
dnanian
10-07-2009, 10:08 PM
The eject logic was moved internal to SD, and is pickier about what it will and won't eject. I've logged a bug against it for internal drives (and eSATA is likely treated similarly).
OK: so, the drives are marked for eject, but won't eject until SD! is quit.
Both my scheduled copies have 'Quit SuperDuper!' under 'On successful completion'
The eject logic was moved internal to SD, and is pickier about what it will and won't eject. I've logged a bug against it for internal drives (and eSATA is likely treated similarly).
Thinking about it now, this may not be the issue. Both my scheduled backups are to the same eSata external drive - each a separate partition - and the data backup unmounts. The system backup does not.
dnanian
10-07-2009, 10:50 PM
Yes, but a scheduled copy leaves SD! in the state it was in, regardless of that value: it leaves the UI & application as it was found.
Yes, but a scheduled copy leaves SD! in the state it was in, regardless of that value: it leaves the UI & application as it was found.
dave,
Just to clarify:
1. SD! is not running when my scheduled backups start
2. The first backup (Data -> L1 Data) mounts and unmounts
3. The second backup (System-> L1 System) - 1 hour later - mounts but does not unmount.
Would it be worth swapping the order of the 2 schedules to see if it's the second backup not unmounting?
dnanian
10-08-2009, 08:01 AM
Well... if the first backup mounts and unmounts, that means that SD! quit when it was done with that copy. The second backup ran entirely after the fact... and SD! was open when it completed?
Dave,
No, SD! was not open when the 2nd backup completed.
I changed the order, System first and Data 2nd. Same thing happened, System target stayed mounted, Data target was unmounted. So, order had no effect.
dnanian
10-09-2009, 08:28 AM
Please send the log from the "System" backup to me using the send to shirt pocket button.
Please send the log from the "System" backup to me using the send to shirt pocket button.
Dave,
I'm on vacation for two weeks and don't have access to my system. I'll send through the log when I return around 26th.
Dave,
Same problem after updating to SD 2.6.2.
Two logs sent to you - System and Data copies.
Mark
vBulletin® v3.8.9, Copyright ©2000-2024, vBulletin Solutions, Inc.