SD clone fails when the source is a .dmg on a read-only network share?

[Robo]

At work we are trying out a deployment system using a SuperDuper-created compressed .dmg of a system located on a read-only AFP network share. Unfortunately, SuperDuper fails when trying to use that .dmg as a source to clone to a local drive. If we mount the .dmg in the Finder, the resulting volume can be used as a source, but this is an extra step and results in a slower cloning process. If the network share is mounted as read/write, SuperDuper handles the .dmg clone just fine, but we want it to be read-only.

Any known reason for this? Is there any way to make this work without allowing write access to the drive? The network share is on OS X server so we have full control over the permissions and ACLs on the share, if there is a special ACL setting or something that can help..

Thanks,

Robin

[dnanian]

Can you send me the log for the failure using the "Send to shirt pocket" button?

[Robo]

Hi Dave - actually, it doesn't even get to the point where there are any log entries to see (at least, the 'Show Log' option remains greyed out).

All I get is this, when I hit 'Copy Now':




The same disk image works fine when the share is mounted with read/write privileges.


Thanks,

Robin

[dnanian]

OK, will take a look. I don't think there's going to be a short-term fix for this other than making the volume read/write for now.

[Robo]

Thanks Dave.

[dnanian]

Are you sure, in the case you're showing me, that you don't have your advanced settings set to save a DMG to the share, rather than just a selection of the DMG in the source pop-up? We're unable to reproduce this with a read-only image hosted on a non-writable volume...