shell script before copy

[bthom]

Hi,

This q'n pertains to automating backups.

I was hoping I could write a shell script to mount my n/w file server when necessary. I've tried using "run shell script" option in SD to no avail. Although I've tested my script (and it mounts desired share), if I tell SD to do a bu and the share isn't mounted, even though it runs the script, I get a can't mount error.

Any ideas?

Thx,

--b

[dnanian]

If your keychain has your login information/password, we should automatically mount the share, 'b'. We do it at "settings load" time, so it won't happen if you eject while you're in SD, but it should when you restart (or on a schedule).

[bthom]

David,

Thanks for the responive replies! You advised:

If your keychain has your login information/password, we should automatically mount the share, 'b'. We do it at "settings load" time, so it won't happen if you eject while you're in SD, but it should when you restart (or on a schedule).

I've tried what I think you're suggesting ... I first have the share on my network file server (NFS) mapped (via AFP). I then open SD, select a sparse image on the share, schedule SD to run the job later, and then quit SD. After that, I eject the mount. When SD schedules the job, its not able to mount the drive. Here's a log:

----
| 07:45:19 PM | Info | SuperDuper!, 2.1.4 (82), path: /Applications/SuperDuper!.app, Mac OS 10.4.10 build 8R218 (ppc)
| 07:45:19 PM | Info | Started on Sat, Nov 10, 2007 at 7:45 PM
| 07:45:19 PM | Info | Source Volume: tweedledum, mount: /, device: /dev/disk0s2, media: ST3160023AS, interconnect: Internal ATA, file system: "Journaled HFS+", OS: 10.4.10 (8R218), capacity: 149.05 GB, used: 126.32 GB, directories: 183124, files: 1041720, ejectable: NO, ACLs: Enabled
| 07:45:19 PM | Info | Target Image: /Volumes/afp_bthom_bootables/tweedledum_auto.sparseimage, name: tweedledum_auto
| 07:45:19 PM | Info | Copy Mode : Smart Update
| 07:45:19 PM | Info | Copy Script : Backup - all files.dset
| 07:45:19 PM | Info | Transcript : BuildTranscript.plist
| 07:45:20 PM | Info | PHASE: 1. Prepare to Copy Files
| 07:45:20 PM | Info | ...ACTION: Preparing tweedledum
| 07:45:20 PM | Info | ......COMMAND => Verifying the integrity of volinfo.database
| 07:45:20 PM | Info | volinfo.database OK
| 07:45:20 PM | Info | ......COMMAND => Enabling permissions on tweedledum
| 07:45:20 PM | Info | Refreshing Disk Arbitration ...
| 07:45:20 PM | Info | ......COMMAND => Verifying that permissions are enabled for tweedledum
| 07:45:20 PM | Info | Permissions on '/' are enabled.
| 07:45:20 PM | Info | ...ACTION: Mounting tweedledum_auto
| 07:45:20 PM | Info | ......COMMAND => Preparing tweedledum_auto
| 07:45:21 PM | Info | hdiutil: create failed - No such file or directory
| 07:45:21 PM | Error | ****FAILED****: result=256 errno=0 (Unknown error: 0)
-----

It is the case that my keychain does have my acct/pwd for the NFS's desired AFP share.

I'm not sure, but suspect the limiation might have to do w/my NFS and AFP. There's numerous ways to connect to the share; I've done w/Finder (via cmd+k), both using just the address and using the address in combination w/my acct/pwd. I can also use the Network icon in the Finder sidebar to find the device. What I think might be causing the problem is that in any method where I'm not hardcoding my acct/pwd into the address, AFP queries me about HOW I want to mount (e.g. as admin, as bthom, all unique accts on my NFS, not my Mac) and what to mount (which share; I have many).

So perhaps when SD starts up, it tries to mount the appropriate share but doesn't know enough?

Important note: My keychain has ALL the info it needs to know to mount, e.g. AFP protocol, IP addr, share name, my acct and pwd.

In any event, your suggestion has not provided me with a solution. For now, I'll use the following workaround: schedule my own cron job minutes before the SD one. But it would be nice to have a more elegant solution.

Advice appreciated.

Thanks,

--b

p.s. I'm using a readyNas as my NFS.

[dnanian]

I'm using a ReadyNAS as well, and I don't have this problem: it mounts right up (since my information is in the keychain)... but if you tried that, I'm not sure what else to suggest. We don't "explicitly" mount the share. Rather, we dereference an alias to our file, and that should automatically do it...