The ISO is verified, the drive worked yesterday, and Rufus dies at the start of the write with Access is denied. That error code belongs to Windows, not to Rufus - something on your own PC is standing on the drive. Here is the order to clear it.
Error 0x00000005 - Access is denied is a Windows permission refusal surfacing inside Rufus. Rufus needs raw, exclusive control of the USB drive to rewrite its partitions; the write fails the moment another program holds the drive open, a security feature blocks low-level disk access, or the drive itself has gone read-only. The fixes below run from most common to most final - and the last one is the honest possibility nobody enjoys: flash memory that has quietly died into permanent read-only mode.
Rufus must run elevated: right-click and choose Run as administrator, and accept the UAC prompt - without elevation, raw disk access is exactly what Windows refuses. Then check the silent blocker: Windows Security's Controlled Folder Access can prevent programs from writing to protected areas and devices. Open Windows Security, check the protection history for a Rufus block, and if it is there, allow the app explicitly rather than switching the whole feature off. Your antivirus may have an equivalent device-control rule - the fix is the same shape: an exception for the genuine Rufus, not a disabled shield.
Windows can flag a disk read-only after file system corruption, and the flag survives reboots. Inspect it from an administrator Command Prompt with diskpart:
diskpart, then list disk and identify the USB drive by its size - carefully, this tool does not forgive wrong selectionsselect disk N with your drive's number, then attributes disk to read its stateattributes disk clear readonly, exit, and retry RufusWhile you are diagnosing, Rufus's own log - the Log button, or Ctrl L - shows precisely where the write stopped, which separates a permissions refusal from a formatting failure.
If the read-only flag returns after clearing, or every PC refuses writes to this drive, the flash memory has reached end of life - NAND chips lock themselves read-only to protect your data when they can no longer write reliably. No software, including Rufus, can argue with that; the drive is a read-only archive now, so copy anything needed off it and replace it.
One related honesty note: only ever troubleshoot the genuine Rufus from rufus.ie. The tool needs administrator rights and deep disk access by design, which is precisely why trojanised copies on random download sites are dangerous. A permissions error is annoying; handing admin rights to a fake Rufus is a catastrophe of a different order.
The access denied case is worked through live in the video - the holder process, the Controlled Folder Access block, and the diskpart check that exposes a dying drive.
Watch Full VideoNot usually. Most cases are a program holding the drive, a Controlled Folder Access block, or missing administrator rights - all fixable in minutes. Death is the diagnosis only when the read-only state returns after being cleared, or the drive refuses writes on several different PCs.
For the genuine Rufus downloaded from rufus.ie, yes - it legitimately needs low-level write access to build bootable drives, which is what the security prompt is noticing. Verify the source before allowing anything; the same click for a copy from an unknown site would be a mistake.
No. Both builds perform the same operations and need the same elevation. The portable version simply keeps its settings in the folder it runs from. If one is being blocked, the other will be too - fix the block, not the edition.