Flamingo Raises $4.5M Seed Round

Skip to content

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 seeLikely causeFix or leave
This drive is read-only everywhereLock switch, or the drive is failingCheck the switch; otherwise copy the data off and replace it
This drive is read-only on one PC onlyDisk attribute or a per-device policyClear the attribute, or check the policy first
Every drive is read-only on this PCRegistry value or company policyCheck policy before touching the registry
Every drive is read-only on every company PCCompany policyLeave 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:

code
diskpart
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

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.

Related Content

Blog Posts

Product Releases

Podcasts

Webinars

Case Studies

Events

Onboarding Guides

Frequently Asked Questions

Disk Write Protected

If it happens on every PC, the drive has usually worn out and switched itself to read-only to protect the data still on it, so copy the files off and replace it. If it only happens on one PC or on company laptops, look at the DiskPart read-only attribute, the StorageDevicePolicies registry value, or a removable storage policy pushed by IT.
Only when the cause was file system corruption. Formatting does nothing against a lock switch, a registry value or a company policy, and on a flash drive that has locked itself it either fails or buys a few days on hardware that is already failing. Copy the data off first either way.
Yes, when the protection comes from the switch, a DiskPart attribute or a stray registry value. When the controller has locked the drive because it is running out of good blocks, the fix is to recover the data and replace it. When a policy is the cause, ask whoever owns the policy for an exception instead of working around it.
Open an elevated command prompt, run diskpart, then list disk, select disk followed by the number of the USB drive, and attributes disk clear readonly. Check the size column before selecting a disk so you clear the right one. If writes still fail, repeat with attributes volume clear readonly on the drive's volume.

MSP AI Agents

On a five-person desk, reported deployments show $78,000 to $130,000 in annual direct labor savings, roughly 30% fewer escalations, and 15% to 20% better SLA compliance. Broader MSP adoption data adds ticket handling time cut by 45% and five to 12 points of margin, all from reclaimed capacity rather than headcount cuts.
Yes. In production MSP shops today, 10% to 25% of tickets close before a human opens them. Thread alone has processed 173 million tickets across 750-plus MSP partners at 96% triage accuracy, handing back 490,000-plus technician hours. Agents own the low-risk, high-volume work (password resets, MFA enrollment, known installs, onboarding and offboarding) and flag anything that touches production data or needs judgment for a human to take.

About OpenFrame

OpenFrame isn't built to plug into your stack. It replaces it. Instead of duct-taping a dozen tools together (RMM, MDM, SIEM, patching, remote access, each its own login and bill), we bundle it into one unified platform: RMM, MDM, monitoring, automation, remote access, patch management, security monitoring, and ticketing, plus built-in AI copilots. So "does it integrate with X?" usually means: you won't need X anymore.
Most platforms give you one piece and expect you to bolt the rest on. OpenFrame unifies the whole stack in one place, with AI copilots built in. Fewer logins, fewer bills, less duct tape.
In the cloud, on US soil. Your data stays stateside.
Both. It's built for MSPs and MSSPs alike.