Updated: October 2026
Someone plugs in a USB stick, drags a file across, and Windows says the disk is write protected. Sometimes that's a worn-out drive, sometimes it's a stray flag, and sometimes it's a policy doing exactly what the security team asked. Here's how to tell which one you're looking at, fix the ones that should be fixed, and leave the rest alone.
What "The Disk Is Write Protected" Means
Windows is refusing to write because something marked the disk as read-only. That something can live in five places: a physical switch on the device, the flash controller inside the drive, a read-only attribute on the disk, a registry value on the PC, or a company policy.
You'll also see it worded as "the media is write protected", usually from the format dialog or from diskpart itself. Same cause, same five places to look.
The error looks the same for all five. The fix doesn't. Clearing a DiskPart flag does nothing for a drive whose controller has locked itself, and removing a policy on one laptop undoes a decision someone made on purpose.
So the first job is working out which layer said no.
One Drive or Every Drive?
Two quick swaps narrow it down fast. Try the drive in another PC, and try another drive in this PC.
| What you see | Likely cause | Fix or leave |
|---|---|---|
| This drive is read-only everywhere | Lock switch, or the drive is failing | Check the switch; otherwise copy the data off and replace it |
| This drive is read-only on one PC only | Disk attribute or a per-device policy | Clear the attribute, or check the policy first |
| Every drive is read-only on this PC | Registry value or company policy | Check policy before touching the registry |
| Every drive is read-only on every company PC | Company policy | Leave it, and ask for an exception if you need one |
If you manage the machine, gpresult /h report.html shows which policies are applied before you change anything.
The Lock Switch and the Dying Drive
Start with the boring one. Full-size SD cards and some USB sticks have a small slide switch on the side. If it's in the lock position, nothing on the PC can override it.
The less obvious cause is a drive protecting itself. SanDisk's support article explains that a flash drive will write protect itself "when the number of good blocks is lower than the preset threshold," or when corruption hits both copies of a block. That's the controller keeping your data readable after it stops trusting its own memory.
When that happens, don't format it and don't fight it. Copy the data off while you still can, then replace the drive. Formatting a drive in that state either fails or buys you a few more days on hardware that's already told you it's done.
Clear the Read-Only Attribute With DiskPart
If the drive works on other PCs, a read-only attribute on the disk is the next suspect. Microsoft's attributes disk reference documents the command that sets and clears it. Run these in an elevated command prompt:
codediskpart list disk select disk 2 attributes disk attributes disk clear readonly exit
If the disk shows as clear but writes still fail, the flag can sit one level down. Run list volume, select volume for the drive letter, then attributes volume clear readonly. Windows keeps disk, partition and volume as separate objects, and each can carry its own read-only state.
Check the size column before you pick the disk number. Selecting the wrong disk here is how a quick fix turns into a data recovery job.
The same flag is reachable from PowerShell with Get-Disk to find the number and Set-Disk -Number 2 -IsReadOnly $false to clear it. That version is easier to script, and our list of PowerShell commands covers the triage around it.
The Registry Value Nobody Remembers Setting
When every drive is read-only on one PC and no policy explains it, look at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies. A DWORD called WriteProtect set to 1 makes Windows treat removable storage as read-only.
Nobody remembers setting it. It arrives with old hardening scripts, imaging templates, or a tool that tried to lock things down years ago. Set it to 0, then unplug and reconnect the drive.
This r/sysadmin thread shows it hitting a server disk, not a USB stick. The admin had cleared every attribute and checked every BitLocker policy, and the disk stayed read-only until they created the StorageDevicePolicies key with WriteProtect set to 0.
When the Company Did It on Purpose
On a managed laptop, write protection is often the policy working as designed. Three controls produce this exact error.
The first is Group Policy or Intune. Windows has a setting called "Removable Disks: Deny write access" under System > Removable Storage Access, and Microsoft's policy reference lists it for both computers and users. Intune pushes the same setting through its administrative templates.
The second is BitLocker. The policy "Deny write access to removable drives not protected by BitLocker" lets people read any stick but only write to encrypted ones. Users see that as write protection until they encrypt the drive. If BitLocker keys are part of the story, our TPM troubleshooting guide covers backing them up first.
The third is device control. Defender for Endpoint's device control can block read, write or execute per device, allow specific drives, and log every hit as a RemovableStoragePolicyTriggered event. Third-party endpoint agents do the same job.
That's why write protection on a company laptop is a data-loss question as much as a support one. Our guide to data loss prevention software covers where those controls fit.
This r/techsupport thread is the classic version: every stick write-protected on one company laptop, fine everywhere else. The replies go straight to Group Policy, BitLocker and device-control agents.
If one of these is the cause, don't edit the registry to get around it. Ask whoever owns the policy for an exception, or get the specific drive allowed by its serial number. That keeps the control intact and gets the user unblocked.
This short walkthrough from Byte Geek covers the DiskPart and registry fixes for the cases where the block isn't a policy.
Fix It or Leave It
Write protection has two kinds of cause. Faults (a stuck attribute, a leftover registry value, a lock switch) get fixed. Decisions (a policy, BitLocker, device control) get respected, and changed only by whoever owns them. A dying drive sits in between: rescue the data and let it go.
On a fleet, the stray registry value is the one worth hunting, because it hides on the odd machine for years. If you run OpenFrame, a scheduled script with an approval gate can check WriteProtect across every endpoint and flag the ones that don't match.
Start with the two swaps, and you'll know which kind you've got in a couple of minutes. For the commands behind the fixes, our PowerShell commands guide is the next read.

Aliaska Varieva
Head of Platform
Hi! I’m Aliaska, and I’ve been working as a software engineer (mostly Java + a bit Kotlin) for over 8 years now. I mostly spend my time building backend services, integrating systems, fixing bugs (the fun part 🙃), and making sure things don’t fall apart behind the scenes.
