Ahh yes, it is good to get back to the geeky posts, isn't it.
I just found this out the hard way. I use Carbon Copy Cloner (thanks so much Mike Bombich) and Apple System Restore in my day job a lot. It allows me to clone a new Mac in about 15 minutes, and that is with about 10 GB of data.
Mac OS X 10.4.6 prevents me from even using 'sudo' to execute the 'asr' command in Terminal. My handy AppleScript even fails.
It turns out that you need to run the 'asr' command in a root shell, or login to the system as root. If you ask me, this is something that you should not have to do. As any BOFH will tell you, using root to do anything is not a good idea.
And I am not about to leave a root password in a "do shell script" AppleScript, as I don't even like putting in an admin password in there. Even though adding "user name "username" password "password" with administrator privileges" to the end seems to work if you enable root in OS X, and use that user in the script.
Using root allowed me to continue my ASR cloning as I always have in every previous iteration of OS X.
To make matters worse, you get an odd-ball error. The "Permission denied" error makes sense, but not the "Validating target" error. Why? Because in this case the Target had nothing on it, it was in fact a newly formatted HFS+ volume. The "The target volume will not be bootable" is also a little odd too. I chalk this up as another oddity of OS X/BSD integration.
See the entire CLI dump after the break.
ken-edwards-lacie:~ meancode$ asr -source /Volumes/CloneImageHD/Workstation_asr.dmg -target /Volumes/Workstation -erase
Validating target.../System/Library/Filesystems/ufs.fs/ufs.util: open /dev/rdisk0s10 failed, Permission denied
done
Validating source...done
The target volume will not be bootable. Continue anyway? [yn]: y
Erase contents of /dev/disk0s10 (/Volumes/Workstation)? [ny]: y
Erasing target device /dev/disk0s10...newfs_hfs: /dev/rdisk0s10: Permission denied
/sbin/newfs_hfs failed with error 256
/Volumes/Workstation
