balenaEtcher Stuck at Starting on macOS: Erase the USB Drive as exFAT
An APFS-formatted USB drive stops Etcher’s helper before it writes a byte; erased as exFAT, the same drive flashes normally.

On this page
TL;DR
When balenaEtcher stays at “Starting…” with no progress bar and no error,
check the USB drive’s format. On a drive formatted as APFS, Etcher’s helper
receives the write request and never starts writing. Running Etcher as sudo
doesn’t change that. Erase the whole drive as exFAT and flash again.
The erase deletes everything on the drive. Replace N in diskN with the
number diskutil list shows for your USB drive, and check it before the last
command.
$ diskutil list
$ diskutil unmountDisk force /dev/diskN
$ diskutil eraseDisk ExFAT USB GPT /dev/diskNIf Etcher still stops, write the ISO with dd instead, as described in
Create a bootable Linux USB drive on macOS with dd.
I wanted to repurpose my old Mac, a 2011 iMac, by putting Linux Mint on it.
I wrote the installer USB drive on my Apple Silicon MacBook Pro with
balenaEtcher. Etcher stopped at “Starting…” and gave no reason, so I wrote
the drive with dd, and the iMac booted from it. Later I reproduced the hang
on a second drive to find the cause.
Symptoms
balenaEtcher (also searched as Balena Etcher) detects the drive and loads the ISO. After you click Flash, the window stays at:
Starting...No progress bar appears and no error is raised. Launching the app from a terminal with elevated permissions makes no difference:
sudo /Applications/balenaEtcher.app/Contents/MacOS/balenaEtcherEtcher’s DevTools console shows the flasher starting and then stopping short of the write. This is Etcher 2.1.6 with an APFS-formatted drive:
Starting priviledged flasher sidecar on port 3435
/Applications/balenaEtcher.app/Contents/Resources/etcher-util
... with privileges ...
elevated pending
...
elevated granted
etcher-<id>
Connection to sidecar flasher process attempt 1 / 10 failed; retrying in 1000ms...
etcher-<id>
CHILD READY
start heartbeat
params Object
CHILD LOG: Ready ...
CHILD LOG: write requested
CHILD LOG: Image: /Users/<user>/Downloads/<image>.iso
CHILD LOG: Devices: /dev/diskN
CHILD LOG: Auto blockmapping: true
CHILD LOG: Decompress first: trueThe log reaches write requested, echoes the job’s settings, and no bytes
follow. In the log, <user> is your account name and <image> is the ISO
you selected. N is your drive’s disk number, and <id> is a random name
Etcher gives each helper run.
APFS drive that stops the helper before the write
Etcher doesn’t write the disk itself. The Electron app launches a separate
privileged helper, the “sidecar flasher”, and hands it the image and the
device. The CHILD LOG lines after write requested are the helper echoing
that request back. Etcher asks macOS for administrator rights for the helper
itself, which is what the elevated pending and elevated granted lines
record, so sudo adds nothing. Run as sudo, the log is identical.
The log doesn’t show why the helper stops. The drive’s format does. I reproduced the hang with a second USB drive, a different ISO and Etcher 2.1.6, and changed only the format between two runs:
| Drive format | What Etcher did |
|---|---|
| APFS, GUID partition map | Stopped at “Starting…”; the log ended at Decompress first: true |
| exFAT, GUID partition map | Started writing; the next log line was the first progress line |
Erased as exFAT, the same flash continued straight into progress:
CHILD LOG: Decompress first: true
Flashing 1 device, 0% at 1.60 MB/s (total 1.60 MB/s) eta in 235s with 0 failed devicesThat matches the reports on balena’s forums. One thread (opens in a new tab) states that Etcher doesn’t work on an APFS drive and surfaces no error. Another (opens in a new tab) with this hang was resolved by erasing the drive as exFAT.
A USB drive isn’t APFS unless someone made it so. Disk Utility offers APFS
only when you erase the whole device with a GUID partition map, not when you
erase a volume on a drive with the older MBR layout. I don’t know what the
first drive was formatted as when it hung. dd wrote the Mint image to it
without an error, so the ISO and the drive weren’t at fault.
Erase the USB drive as exFAT
The erase replaces the drive’s partition map and every volume on it. Copy off anything you need from the drive first.
1. Find the USB drive
$ diskutil listFind the header that reads external, physical and matches your drive’s size.
Its number replaces N in the next step.
An APFS drive also appears a second time, as a synthesized container. Use
the external, physical identifier, not the container’s.
2. Erase it
$ diskutil unmountDisk force /dev/diskN
$ diskutil eraseDisk ExFAT USB GPT /dev/diskNforce matters when Spotlight is indexing the drive. Without it, the erase
can fail with Couldn't unmount disk. : (-69888) and name the process mds.
USB is the new volume name; any name works, because the flash overwrites it.
3. Flash again
Select the ISO and the drive in Etcher, and click Flash. Within a few seconds,
the window shows Flashing... with a percentage, and the DevTools log shows
Flashing 1 device lines.
Write the ISO with dd instead
If Etcher still stops after the erase, dd writes the image without Etcher’s
helper. That’s how the Mint drive in this article was written. The steps, the
checks that keep dd off the wrong disk, and how to confirm the write are in
Create a bootable Linux USB drive on macOS with dd.
Tested with
- macOS
- Tahoe 26.3.1, MacBook Pro (Apple Silicon)
- USB
- PNY 32 GB USB 3.0
- ISO
- Linux Mint 22.3 Cinnamon 64-bit
- Reproduction
- balenaEtcher 2.1.6, CHIPSBNK 1 GB USB 2.0, Alpine 3.24.2 x86_64
- Date
- March 2026