dd Command on Mac: rdisk4s1 Accepts Writes While Mounted

I wrote one megabyte of zeros to /dev/rdisk4s1 while the volume on it was mounted. macOS let it happen and dd exited 0. The file I had just saved to that volume still opened, because the system was serving it from cache. When I unmounted and tried to mount again, I got Volume on disk4s1 failed to mount. Writing to /dev/disk4, /dev/rdisk4 and /dev/disk4s1 was refused with Resource busy. The raw partition node was the gap.

That was a throwaway disk image, not a USB stick, and the gap showed up on HFS+, FAT32 and exFAT. APFS refused all eight of its device nodes. This post covers how dd on macOS 26.4.1 actually behaves: the safe recipe for writing an image to a USB drive, progress output (built in since macOS 12.3), the block-size suffixes that mean different things than on Linux, the disk vs rdisk speed difference, and a pipe case where count=100 copied less than 4 MB and still exited 0.

The short answer

# 1. find the USB drive: look for "external, physical" and the size you expect
diskutil list external

# 2. unmount every volume on it (unmountDisk, not unmount)
diskutil unmountDisk /dev/disk4

# 3. write to the raw WHOLE-DISK node: rdisk4, not rdisk4s1
sudo dd if=ubuntu.iso of=/dev/rdisk4 bs=4m status=progress

# 4. flush and eject
sync
diskutil eject /dev/disk4

Mac dd is the FreeBSD dd, not GNU dd. Apple ships it in /bin/dd and there's no --version flag. If you're coming from Linux, two habits break. bs=4M works, but bs=4MB fails with dd: bs: illegal numeric value. GNU-only flags like oflag=dsync fail with exit 1. Both fail before writing anything, which makes them the harmless kind of difference. Picking the wrong device node is not harmless, and diskutil list is the lsblk replacement on a Mac you use to avoid that.

Unmounting is what protects you, until you pick a partition node

For each node I formatted a 1 GiB disk image, attached it as /dev/disk4, mounted it, saved a file, then ran dd if=/dev/zero of=NODE bs=1m count=1:

Format	disk4 / rdisk4 (whole disk)	disk4s1	rdisk4s1	Mounts afterwards?
Mac OS Extended (HFS+)	Resource busy	Resource busy	written, exit 0	No
MS-DOS (FAT32)	not run	Resource busy	written, exit 0	No
ExFAT	Resource busy	Resource busy	written, exit 0	No
APFS (plus the synthesized disk5 nodes)	Resource busy	Resource busy	Resource busy (disk5s1: Read-only file system)	Yes

GNU dd from Homebrew did the same thing to rdisk4s1, so the kernel allows the write and dd plays no part in it. Two practical points follow. First, Resource busy on the whole disk is the protection doing its job. Run diskutil unmountDisk instead of looking for a node that lets the write through. A partition node will let it through, and it lands on top of a mounted file system. Second, an image file such as an ISO or a Raspberry Pi .img carries its own partition table, so it belongs on the whole-disk node. Writing it to s1 puts a partition table inside a partition, which firmware won't treat as a bootable drive.

Without sudo, my own disk image's nodes were writable because hdiutil hands them to the user who attached them. A real USB drive's nodes belong to root. Reading the internal disk without sudo gave dd: /dev/rdisk0: Operation not permitted. Permission errors on raw devices are a separate macOS privacy layer from file permissions. I covered how that layer answers a terminal in Full Disk Access for Mac Terminal.

status=progress works on a Mac now

The most-viewed dd question on Ask Different, How can I track progress of dd, has 97,618 views. Its top answers date from 2016 to 2018. The highest-scored one (144 points) says to press Control-T. The next (62 points) says to install Homebrew coreutils and run gdd with bs=1 status=progress, which uses one-byte blocks, the slowest setting dd has. The answer saying stock dd supports status=progress was posted on October 28, 2025 and has a score of 0.

Apple's open-source drops date it. In file_cmds-353.100.22, dd's argument parser gained progress, fullblock and speed. In the version before it, 352.40.6, none of the three exist. Apple's macOS distribution index pins 352.40.6 to macOS 12.2 and 353.100.22 to macOS 12.3, 12.4 and 12.5. So any Mac on macOS 12.3 or later has it:

$ dd if=/dev/zero of=/dev/null bs=1m count=600 speed=200m status=progress
  69206016 bytes (69 MB, 66 MiB) transferred 1.143s, 61 MB/s
  ...
600+0 records in
600+0 records out
629145600 bytes transferred in 9.755627 secs (64490535 bytes/sec)

The progress line overwrites itself with a carriage return once per second, so a copy that finishes in under a second prints no progress line. Control-T still works, and so does kill -INFO <pid> from another window. I sent SIGINFO at 1.5 seconds and got 106954752 bytes transferred in 1.640070 secs while the copy kept going to a clean exit 0. Note the speed in that example: I asked for speed=200m and got 61 MB/s. The limiter undershoots at every rate I tried. 100 MiB at speed=10m took 11.5 seconds instead of 10, at 50m 6.9 seconds instead of 2, and at 1g 0.36 seconds instead of 0.1.

Block-size suffixes: same letter, different number

I ran bs=VALUE count=1 through both /bin/dd and Homebrew's gdd (coreutils 9.12) and recorded the bytes copied:

bs=	macOS dd	GNU dd
1M	1,048,576	1,048,576
1m	1,048,576	invalid number
1MB	illegal numeric value	1,000,000
1MiB	illegal numeric value	1,048,576
1kB	illegal numeric value	1,000
1w	4	2
4x1m	4,194,304	invalid number (4x1M works)
0x100000	1,048,576	invalid number

Uppercase M, K and G mean the same thing in both, so a script that sticks to those is portable. Every mismatch above stops with exit 1 before copying except 1w, which silently copies a different amount. GNU's MB meaning powers of 1,000 is documented in the coreutils dd manual. The BSD letters, including b for 512 bytes, are in the FreeBSD dd manual, which matches the Mac man page.

Operands that exist on Linux and fail here with exit 1: oflag=dsync, oflag=append, conv=fdatasync, conv=nocreat, conv=excl, iflag=count_bytes. Ones that work: status=progress|none|noxfer, iflag=fullblock, oflag=sync, oflag=direct, conv=fsync, conv=sparse, conv=notrunc.

disk vs rdisk: the raw node is only fast with big blocks

The usual Mac advice is to write to /dev/rdiskN because it skips the buffer cache. I wrote 256 MiB of random data to the attached image through both nodes at five block sizes, three runs each:

With 512-byte blocks, which is dd's default when you leave out bs, the raw node took 60.4 seconds against 3.96 for the buffered one. At 1 MiB the raw node finished in 0.063 seconds against 0.892. Adding a sync to the timing didn't change the order: 0.13 to 0.14 seconds for rdisk, 1.02 to 1.05 for disk. The buffered node flattens out around 270 to 300 MB/s whatever block size you give it. The raw node passes each block straight down, so small blocks mean tens of thousands of tiny writes. Use rdisk together with bs=1m or bs=4m. With the default block size, rdisk is the slowest option here. The Ask Different question about rdisk being very slow on Sierra (22,591 views) may be a case of the same thing.

These absolute numbers come from an image file on the Mac's internal SSD, so the 4,260 MB/s is the SSD and the page cache, not a USB stick. A USB 3 flash drive will cap both nodes far lower. I'd expect the ratio at small block sizes to hold because the per-write overhead is on the Mac's side, but I haven't measured a real stick. If you want a scratch device to try this on, an hdiutil-attached image works the same way I used it here, and a RAM disk on Mac is another throwaway target.

count without fullblock: 100 asked, under 4 MB copied, exit 0

This one bites scripts that pipe into dd:

$ cat big.bin | dd of=part.bin bs=1m count=100
0+100 records in
2+1 records out
2883584 bytes transferred in 0.000870 secs (3314464368 bytes/sec)
$ echo $?
0

A pipe hands dd whatever is ready, usually 64 KiB or less, and count counts reads, not full blocks. Three runs copied 2,883,584, 3,276,800 and 3,899,392 bytes out of the 104,857,600 I asked for. gzip -dc file.gz | dd bs=4m count=64 copied exactly 4 MiB out of 256. Adding iflag=fullblock fixed it: 104,857,600 bytes, every time. GNU dd has the same short-read behavior. One more catch: the GNU manual's rescue example combines conv=noerror,sync iflag=fullblock, and macOS dd rejects that pair with dd: sync: illegal conversion combination. When the input is a file rather than a pipe, as with an ISO, this doesn't come up. If you're checking that a copy came out whole, sha256sum on Mac covers the built-in hash tools.

FAQ

Does dd status=progress work on Mac?

Yes, on macOS 12.3 and later. Apple's dd gained status=progress, iflag=fullblock and speed= in file_cmds-353.100.22, which first shipped in macOS 12.3. It prints a progress line once per second. On older macOS, press Control-T while dd runs, or send kill -INFO to its process ID, to print the current byte count.

Why does dd say Resource busy on Mac?

A volume on that disk is still mounted. Run diskutil unmountDisk /dev/diskN, which unmounts every volume on the disk, then run dd against /dev/rdiskN. Don't get around the error by writing to a partition node such as /dev/rdiskNs1: on HFS+, FAT32 and exFAT that node accepted the write while mounted, and the volume would not mount again afterwards.

Should I use bs=1m or bs=1M with dd on Mac?

Both mean 1,048,576 bytes in macOS dd, but only bs=1M also works with GNU dd on Linux. Avoid bs=1MB on a Mac: macOS dd rejects it with "illegal numeric value", while GNU dd reads it as 1,000,000 bytes. Use 1 MiB or 4 MiB blocks with /dev/rdisk; at dd's default 512 bytes the raw node was 15 times slower than the buffered one.

How this was tested: Mac mini (Mac16,10), macOS 26.4.1 (25E253), Apple's /bin/dd and Homebrew coreutils 9.12 gdd, on October 13, 2026. Every write went to a 1 GiB raw disk image attached with hdiutil attach -nomount, and I checked before each write that the target was a "Disk Image" device. No USB drive or internal disk was written to, so I didn't test sudo or Full Disk Access prompts, and the speeds describe the internal SSD and cache, not flash media. SIGINFO was sent with kill -INFO rather than a keyboard Control-T. The macOS 12.3 date comes from comparing dd/args.c across Apple's file_cmds tags and the file_cmds version recorded in Apple's distribution-macOS tags; I didn't run a 12.2 machine. Question view counts and scores are from the Stack Exchange API on the same day. The image and test files were deleted afterwards.