MacOS 12.16: dd with devices is all but useless? reading/writing to raw disk (APFS) fails with "permission denied" or "Invalid argument"

Question

Help!

When I run dd inputting from either buffered or raw device of an unmounted volume, which does show up in diskutil list, I get either "Permission denied" or "Invalid argument".

Please note:

• MacOS 12.6.1 (Monterey)
• Volumes are not mounted, nor are any snapshots of those volumes mounted.

# diskutil list |grep -E -- '-TM3|ExtData1'
   1:                APFS Volume ⁨ExtData1⁩                282.0 GB   disk5s2
   1:                APFS Volume ⁨Mac-TM3⁩                 954.4 KB   disk7s1
# mount |grep -q -iE 'disks5s2|disk7s1|timemachine' || echo nope
nope

• Security & Privacy settings: "Term", /bin/sh, and /bin/dd all have "Full Disk" permissions.
• SIP was disabled in recovery mode, and csrutil status shows it is disabled.

# csrutil status
System Integrity Protection status: disabled.

• The dd command works between /dev/null and /dev/zero, and the current tty device and to /dev/console.
• The dd command worked to read from the unmounted recovery-hd volume on the main internal drive. -- OH CRAP, HEREIN LIES THE ANSWER

The whole reason I'm doing this is to work-around Mac's horrible redesign of TimeMachine, which effectively makes backup devices unmovable and unclonable.

Answer 1

After posting as much information as I could find relevant, I discovered that the reason these devices cannot be copied is because MacOS "virtualizes" the AppleFileSystem disks into a "container". You can see that in the full diskutil list output :

# diskutil list
/dev/disk0 (internal):
  <redacted>

/dev/disk3 (synthesized):
  <redacted>

/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk4
   1:                        EFI ⁨EFI⁩                     209.7 MB   disk4s1
   2:                  Apple_HFS ⁨Boot21⁩                  12.0 GB    disk4s2
   3:                  Apple_HFS ⁨Boot22⁩                  6.0 GB     disk4s3
   4:                  Apple_HFS ⁨HighSierra2⁩             6.0 GB     disk4s4
   5:                  Apple_HFS ⁨10_11 ElCapitan⁩         51.4 GB    disk4s5
   6:                 Apple_Boot ⁨Recovery HD⁩             650.0 MB   disk4s6
   7:                 Apple_APFS ⁨Container disk5⁩         423.3 GB   disk4s7

/dev/disk5 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +423.3 GB   disk5
                                 Physical Store disk4s7
   1:                APFS Volume ⁨ExtData1⁩                282.0 GB   disk5s2

/dev/disk6 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *12.0 TB    disk6
   1:                        EFI ⁨EFI⁩                     209.7 MB   disk6s1
   2:                  Apple_HFS ⁨Reserved⁩                5.6 TB     disk6s2
   3:                 Apple_APFS ⁨Container disk7⁩         413.3 GB   disk6s5
   4:                  Apple_HFS ⁨Backups⁩                 6.0 TB     disk6s3

/dev/disk7 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +413.3 GB   disk7
                                 Physical Store disk6s5
   1:                APFS Volume ⁨Mac-TM3⁩                 954.4 KB   disk7s1

I successfully ran dd on the raw "container" volumes on the physical devices, rdisk4s7 and rdisk6s5

I will update later if I found that SIP was also involved.

With a hattip to David Anderson, asr man pages notes:

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.

This sounds like a crack team of Apple engineers should have gotten more real-world experience before redesigning a filesystem.