Take a disk image out of a share and write it straight onto a physical drive — a USB stick, an SD card, an SSD — streaming it from Usenet as it writes.
You do not need space for the image. It is never stored as a file. Bytes arrive from Usenet, are decrypted, and go onto the target device. Writing a 500 GB image needs 500 GB on the target, and nothing on your system disk.
This is what you want for a bootable installer, a pre-built system image, or a ready-to-run media drive.
Requirements
The desktop app, running elevated. Writing to a raw block device needs administrator on Windows or root on Linux. The Write to Disk menu item only appears where that is available — if you cannot see it, the app is not elevated, or you are on Docker where it does not apply.
A target drive you are willing to erase. This overwrites the whole device.
The image already imported, index-only. On the Download page use Import (Index Only). Do not use Import & Download — that would download the whole image first, which is the thing this feature exists to avoid.
Steps
- Import the share containing the image with Import (Index Only).
- Open the share. For a single-image share, Write to Disk is in the header. Otherwise find the image in the file list and use its Write to Disk action. You can also start from the Write to Disk page and pick the share there.
- 1 · Source image — confirm the image.
- 2 · Target device — pick the drive. Your system disk and other protected devices are listed but not selectable.
- 3 · Confirm & write — tick the box acknowledging the device will be erased.
- Watch Progress.
Check the target twice
The device list shows size and model to help you identify the right one. Read them before confirming: a 64 GB stick and a 64 GB stick look identical in a dropdown, and this operation cannot be undone.
The app refuses your system disk and other protected devices. It cannot know which of your removable drives you meant.
Try it without writing
A dry run option is available. It exercises the whole path — fetch, decrypt, target checks — without writing to the device. Worth one minute before a long write onto a drive whose contents you are about to lose.
While it runs
You get bytes written, speed, ETA, and a verify stage, plus Pause, Resume and Cancel.
Pause and resume work. So does surviving a crash: the job is checkpointed, and after an unexpected restart it resumes rather than starting the drive again.
Do not unplug the drive. Pause first, or cancel.
It ends with a SHA-256 verify — the written device is read back and hashed against the published value. That is the difference between "the bytes were sent" and "the drive actually holds them", and cheap USB sticks fail this more often than you would like. Let it finish.
Expected speed
The slower of two things: what your provider delivers, and what the target device absorbs. USB sticks are frequently the limit — many write far more slowly than they read, and a cheap one can sit at single-digit MB/s regardless of your connection.
If a write is much slower than your downloads, the drive is the reason. The speed test can confirm it: When something is wrong.
What this is not
Three adjacent features, easy to confuse:
| You want | Use |
|---|---|
| A few files out of an image, no spare drive needed | Browse inside a disk image |
| The share as a drive letter, files read on demand | Mount a share as a drive |
| The image as a file on your disk | An ordinary download — Download a share |
If you only need a handful of files from inside the image, guide 11 is what you want — it fetches a small percentage of the image and needs no device at all.
When it goes wrong
No "Write to Disk" menu item. The app is not elevated. Restart it as administrator (Windows) or with root (Linux). It is not available in Docker.
The drive is not listed. Some USB enclosures and card readers do not present as raw block devices. Try Rescan, a different port, or a different reader.
The drive is listed but greyed out. It is protected — your system disk, or a device holding a mounted filesystem the app will not overwrite.
It failed part-way. Press write again; it resumes from its checkpoint. If it fails repeatedly at a similar point, suspect the device — a failing stick often dies at a consistent offset. Try another one before suspecting the share.
Verify failed at the end. The device did not keep what was written. Nearly always failing media. Try a different drive; if a second drive also fails at the same point, verify the share itself with Verify and repair.
It is much slower than downloading. The target device. See above.