How to mountain AFP for backup target?

[Dewdman42]

I can't seem to figure out how to get SuperDuper to automatically mount a remove AFP share for the purpose of doing a smartupdate to a bundle there.

How can we cause superduper to mount the AFP share ahead of time, then umount it after; while doing the smart update not to the entire share, but to a sparse bundle that is saved there?

[dnanian]

It'll certainly mount it (note that, on Lion, you may need to copy your Keychain entry from the local to the system keychain), but it won't unmount the share.

[Dewdman42]

Im' on SL, but I can't get it to mount at all. ??

[dnanian]

You have your credentials for the mount stored in the keychain?

[Dewdman42]

well I think so since I don't have to provide any credentials to mount the drive from finder. how would I know for sure?

[dnanian]

OK. So, delete the schedule you have. In the main window, reselect the image or bundle in the "Disk Image..." pop-up (even if it's grey), making sure to set the image type properly.

Reschedule for a minute or two from "now".

Quit SD! and wait to see what happens.

[Dewdman42]

well I tried that several times and its not mounting the AFP volume. This is the log:


| 10:12:57 PM | Info | ......COMMAND => Preparing mbp-dewd-10-6-full
| 10:12:57 PM | Info | Finished verify/repair permissions on disk0s2 Boot
| 10:12:57 PM | Info | ...ACTION: Mounting mbp-dewd-10-6-full
| 10:12:57 PM | Info | ......COMMAND => Preparing mbp-dewd-10-6-full
| 10:12:59 PM | Info | hdiutil: create failed - No such file or directory
| 10:12:59 PM | Error | ****FAILED****: result=256 errno=22 (Unknown error: 0)


If I manually mount the AFP volume first, then the backup runs fine.

Is there a way I can add something to the actual scheduled script to make sure the volume will be mounted? I am able to mount the volume from finder without having to supply any credentials, so I guess it must be in the keychain.

[dnanian]

We resolve an alias to the image file, and that should automatically mount the network volume (it certainly does here). The mount happens when the settings are loaded, actually, NOT when Copy now is pressed.

You're sure you did this scheduled (where it would actually load settings), and not by simply clicking Copy Now (where the settings are already loaded, and thus wouldn't mount)?

[Dewdman42]

yes I set the schedule and completely exited SD to make sure that it would do what it was supposed to. It launches SD on the appointed time, loads the settings, but the AFP volume is never mounted. It does the first part of checking perms on the source volume, then fails while trying to find the sparse bundle, since the AFP vol is not mounted

[dnanian]

I don't have an answer for you. I don't know why resolving the alias wouldn't mount the volume. But - you can use a small AppleScript application to mount the volume before the schedule fires if you want - just set that up, then schedule an iCal alarm to run the little program just before the schedule is set to go.

[Dewdman42]

Yea I can do it with launchd, no problem. I just wanted to make sure SD can't do it first. Thanks

[Dewdman42]

one question though, is it possible for me to launch a backup job myself from launchd instead of relying on SD scheduler? Somehow launch SD, load settings, start backup, all from external applescript, so that I can mount the AFP before and unmount after?

[dnanian]

You can look at how we're doing backup on mount...

[Dewdman42]

I don't understand

[dnanian]

Schedule a backup on mount and look at what we're doing in launchd...

[Dewdman42]

I'm not sure what you mean by "backup on mount". Is that a SD feature I'm not aware of? Also I was poking around in launchd trying to find your existing SD schedules, but I couldn't find it.

[Dewdman42]

Looking around in the scheduler, I see the checkbox for "when you connect foobar to your macintosh". However it is greyed out. foobar is the name of the sparsebundle by the way, not the AFP volume.

[dnanian]

I know. Set it up to write to some local drive, just so you can see how we're doing it in launchd...

[Dewdman42]

I don't know, i have tried every conceivable possbile type of destination and always the backup on mount checkbox is greyed out.

[dnanian]

You've tried a local, directly connected destination that's ejectable?

[Dewdman42]

you didn't say ejectable before. Let me find a usb drive to try.

[Dewdman42]

ok, using USB let me do what you said. It created the launchd entry, which I look at, this entry seemed to indicate the following script get called:

~/Library/Application Support/SuperDuper!/Scheduled Copies/Backup on Mount.scpt

This appears to be a sym link to a generic script found in your application bundle

Backup on Mount.scpt -> /Applications/Utilities/Backup/SuperDuper!.app/Contents/Resources/Backup on Mount.scpt


Having a look at that generic script, I think the following line is probably the line I would need to call if I want to manually launch a backup job myself from launchd:

do shell script "env IMMEDIATE=YES open " & quoted form of POSIX path of (((scheduleFile as string) & ":Copy Job.app") as alias)

which works out essentially to calling this from the command line from within the folder where the scheduled script exists:

env IMMEDIATE=yes open Copy\ Job.app

Here's the question though, I don't know how to create this copy job to my network share without actually scheduling it. But I don't want SD to schedule it, I want to schedule it so that I can manually boot the AFP volume first. If I remove it from the schedule, then this copy job applet is removed and I can't launch it manually. if I leave it scheduled here, then it will be called twice, one of the times manually by me and one time by SD, which may or may not work depending on if the backup volume is currently mounted. Chicken or the egg problem.

How about if I modify:

Copy\ Job.applescript
to mount the volume, will that be ok? Any other suggestions?

If you had a way to provide a pre backup script that gets called BEFORE you attempt to check for the dest volume, then this would be a lot easier.

[dnanian]

Schedule it without actually setting a time OR backup on connect...

[Dewdman42]

or I notice there is a copy template inside your app bundle. Can I modify this:


on beforeRunningCopy()
-- Put your own code here that should execute just before running the copy.

do shell script"mymountcript.sh"

end beforeRunningCopy

Then create a new schedule and never worry about this again?

[dnanian]

Yes, but don't change the one in the app bundle; change the one in the scheduled copy bundle. Note that there's an on error and an on completion action, too. (I would have pointed you here, but you seemed to want to do it another way.)

[Dewdman42]

I'm not inclined to do it any particular way, just trying to make it work and hopefully in such a way that if I reinstall SD later I won't be scratching my head again trying to remember how to configure it again to do this.

I do notice however, when I manually launch your Copy Job.app inside the scheduled bundle, it is actually mounting the volume automatically without calling a pre script. I don't know why that doesn't happen normally when your scheduler launches it, but for some reason if I am able to launch it with the IMMEDIATE=yes from the command line, then the backup volume does get auto mounted.

However, when I tried to create a scheduled Copy Job without an actual schedule as you suggested, the Copy Job.app didn't get created. Its creates the bundle for it, but inside is only a Logs folder and sdss file.

The preferable solution would be to figure out why your Copy Job auto mounts when called immediate and fix it so that it will work when scheduled too. Next favorite solution is to have me schedule it myself to call your Copy Job.app IMMEDIATE=yes, but that only works if I can figure out how to even create that without also creating a SD schedule for it. The least favorite option in some ways is modifying the copy script because every time I change the schedule I will have to go in there and manually tweak that script. If I put it in the template then it would be good forever, as long as I'm always backing up to the same volume for everything. But all of those get lost if I reinstall SD. Fixing Copy Job.app to automount right is preferable solution.

[dnanian]

Check in your Keychain to see if the credentials for the mount are in the system keychain.

[Dewdman42]

I don't know man, suddenly now the auto mounting is working from your scheduler. I don't know why.

I will try that for a while and see if somehow I accidentally fixed it.

One question that might be related, I read somewhere else that AFP does not support more than one login id at a time. My Time Machine backup is going through AFP to my NAS with a different login id then what i use to mount shared AFP volumes. Its a ReadyNAS. They have it setup to temporarily mount a hidden AFP share using the id they want to use for it, then it backs up to a sparseimage there, then unmounts.

if its true that AFP can only support one login at a time (do you know?), then perhaps SD will fail to automount the AFP volume if time machine happens to be running at that moment?

[Dewdman42]

another possible solution might be to use launchd to monitor the dir where scheduled copy scripts do their logging. Then when a scheduled copy script starts to write to that dir, I can have launchd mount the volume for me.

But I dunno, it seems to be magically auto mounting now, so I will run with this for a while. maybe I needed to completely clear out the old scheduled copy script somehow... I dunno

[dnanian]

I don't know whether that's true or not, sorry (AFP). Sounds like it's working as it should now, though!

[Dewdman42]

Well I just stumbled by accident onto the crontab entry that SD created for me. So apparantly you are using cron to schedule the backups, which makes sense now why I could not find in launchd.

so actually it should be very easy for me to simply write a wrapper script and schedule it myself.

[dnanian]

Yes, although you said you wanted to use launchd, which is why I pointed you there.