SD mounting images as read-only in 10.3.9?
 

Ok, so on my 10.3.9 machine, I try to set up a backup to a sparse image file on a network volume. I immediately run into the problem where SD can't create a sparse image on 10.3.9, so I create one manually in Disk Utility as per the workaround instructions here. Now, when I select it in SD and try to run the backup, SD appears to mount the image as read-only (icon in finder window, and can't copy anything to it manually), and fails. If I mount the image manually by double-clicking it, it mounts fine as read/write, and I can copy stuff to it in the Finder. Further, if I mount it manually in the Finder and then select it as a volume in SD, rather than as an image file, it also seems to work fine. It is a sparseimage, only about 50MB file when created for an 80GB image.

What's up?

Please check to see if the volume you're storing the image on is read/write for all users. Also, do the same for the permissions for the sparse image itself... see if that helps.

Nope, no help. I gave "other" write permissions for the Volume, all enclosing folders, and the image file itself, but SD behaves the same. Also tried with and without "ignore permissions on this volume" on the fileserver. My user account does own the image, btw.

Interestingly, SD also seems to be reverting the permissions of the image file:

I think the problem here is that your UID on the local system (501) is different than the UID of the authorized user on the share. The best way to work around this is to mount the image and point directly to the volume, rather than the file. We'll still automount, and since we won't be mounting as your UID, it should work as you'd expect.

This doesn't seem to work; as soon as I unmount the image, the volume disappears from SD's destination menu. In fact, automounting doesn't seem to be working at all on this machine; if I select the disk image file as the destination, then unmount the share, it gives me the 10.3.9 "hdiutil: create failed - Invalid argument" error instead of trying to mount the share as it does on 10.4.

Any idea on how to solve this, and/or how I would go about rectifying the mismatched UIDs?

The automount is only going to happen when you load settings (or launch SuperDuper, whether scheduled or manually). It won't happen if you unmount and then immediately click "Copy Now".

As far as rectifying the UID situation, it's a bit tough. Basically, the very first account you create on the system is going to be UID 501. Do you have more accounts on the share?

You're right; when I set the mounted disk image volume as the destination, it and its network share get mounted automatically for scheduled backups. However, they don't get automatically unmounted. That's fine for the share, but I'd like to see the disk image get unmounted. Do I need to add an "after copy" shell script to kludge this, or is there something I'm missing?

That's right -- it won't unmount automatically like that. You can use an after-copy script: if you're good at this kind of thing, you want to "nohup" a background process that waits 20 seconds or so and then ejects...