macOS High Sierra - asr command not working for reimaging disks

The error message coming back is:
Source volume format on device "/dev/disk2s1" is not valid for restoring.
Could not validate source - Permission denied.

With High Sierra, asr cannot restore volumes in APFS format. This is a known limitation per Apple.

If you are restoring from the 10.13.x recovery hd using asr, Apple has added some new switches. adding some of the info below as you really won't be able to man from there. From the "man asr" in 10.13

RESTORING WITH APFS FILESYSTEMS Individual APFS volumes can not be restored directly, because their device nodes don't allow I/O from a standard process. However, asr can restore entire APFS containers, including all volumes. Or it can restore valid system configurations, which can get the effect of restoring a sin- gle system. This requires understanding what is meant by a valid system.

In order for an APFS volume to bootable, it must contain a properly installed macOS system. It must also be part of an APFS container which also has two special volumes in it: a Preboot volume and a Recovery vol- ume. A container may have arbitrarily many system volumes in it, but it must have only one Preboot volume and one Recovery volume, each with the corresponding APFS volume role set (see diskutil(1) for information on roles). The Preboot and Recovery volumes contain information which is tied to each system volume in the container. So for a system volume to be bootable, that information needs to be set up in the Preboot and Recovery volumes. A system which is part of a container that has these two special volumes, and for which the requisite information is set up in those volumes, will be referred to here as a valid system.

If the source of a restore is an APFS image (i.e. an image which contains an APFS container), then asr does different things depending on how target was specified:

Container Restore If target is an actual disk partition, either of type Apple_APFS or some other type, then asr will block restore the APFS container to the target partition, setting the partition type to Apple_APFS. The resulting container on the target will then contain all the same volumes as the container in the source.

Volume Restore If the target is an individual volume within an existing APFS con- tainer, then asr will block restore the APFS container to a file within that volume, after which it will invert the volume within the restored container, erasing the previous contents of the target volume and replacing them with the source volume contents. If the source container only has a single non-special volume (i.e. not Preboot or Recovery), then that is the volume which will be inverted. If the source container has more than one non-special volume, then either the --sourcevolumename or --sourcevolumeUUID option must be present and must specify the volume to invert. Additionally, if the volume being inverted is a valid system (as defined above), then the relevant contents of both the Preboot and Recovery volumes will be copied from the source to the target, cre- ating those volumes on the target if necessary.

Volume Restore with Creation if the --targetnewvolume option is used in place of --target, and its argument is the synthesized APFS whole disk, then asr will cre- ate a new volume in the given container, after which it will do a volume restore to that new volume, as with the previous section.

See the EXAMPLES section below for some command lines that show these operations.

Restoring a complete APFS image sudo asr restore -s <APFS image> -t /dev/disk1s2 --erase In this case /dev/disk1s2 is a partition of arbitrary type, potentially including Apple_APFS. The entire container is restored as-is, and all volumes in the source will be replicated in the target. The target par- tition is completely erased.

Restoring a single APFS volume sudo asr restore -s <APFS image> -t /Volumes/MyAPFSVolume --erase In this case the contents of MyAPFSVolume will be replaced by the con- tents of the source container's single APFS volume, possibly including any associated data for the Preboot and Recovery volumes, if the source is a valid system. If the source has more than one non-special volume, this is an error. No other volumes in the target will be affected.

Restoring one of many APFS volumes sudo asr restore -s <APFS image> --sourcevolumename SourceVolume -t /Volumes/MyAPFSVolume --erase This tells asr to select the volume named "SourceVolume" from the given APFS image. If there is no volume with that name, or if there are more than one with that name, it is an error. Use the info verb to see the volume names and UUIDs for an image. No other volumes in the target will be affected.

Creating a new APFS volume on the fly sudo asr restore -s <APFS image> --sourcevolumename SourceVolume --targetnewvolume /dev/disk2 --erase Here we get the same effect as the last example, except that asr will create a new volume on the target APFS container disk, given by /dev/disk2, and use that newly created volume as the target. Note that there is no --target (-t) option, instead the container disk is specified by the --targetnewvolume option.

Thanks @dmueller

That's a lot of information. But it sounds like something that would help me greatly. I'm going to have to test out the commands to see if it works for us.

@Bernard.Huang still having this issue? I found that you need to re-image the CONTAINER not the volume and it works if it already had High Sierra

@al786 Howdy, when you say reimage the container, and not the volume, how would one do this? Seems like 10.13.4 update broke something and now ASR can't find the container using the old hdiutil command. Any ideas?

@monaronyc Sorry - are you still in need of this? Just realized JAMF nation had a notification feature button. I usually user sudo ask restore --source (an APFS .dmg created with AutoDMG) then --target /dev/diskxx (usually disk3 if nothing else is connected t the machine) then some optional flags at the end like --erase --noverify so:

sudo asr restore --source /path/to/file.dmg --target /dev/disk3 --erase --noverify --noprompt

the machine HAS to have already had high Sierra on it but it takes about 30 seconds to image then you can either re-enroll via DEP or some other method