Windows cannot run disk checking on a volume that blocks writes. Do not start by forcing a repair. CHKDSK’s fixing modes need to change file-system structures. First check whether the files are still readable and copy important ones to another healthy device. Then determine whether the restriction comes from a physical switch, a Windows attribute, a policy or encryption state, or a failing storage device. The right next step depends on that cause.
Understand what the error does—and does not—tell you
The message describes a blocked write operation. It does not identify why the volume became write-protected, and it does not prove that all files are already lost. A drive may still permit reading while refusing changes. That is a valuable opportunity to copy data before altering attributes or running a repair. Open a few representative documents or photos and test a read-only copy to a separate drive. Avoid creating test files on the affected volume.
Note the exact message and the command you ran. chkdsk X: can report information, while options such as /f or /r involve repair behavior. Replace X only with the verified drive letter if you later use a command. Do not run a command against a letter remembered from an earlier session; removable drives can change letters. Microsoft’s CHKDSK documentation explains what its parameters do.
This problem is not identical to “CHKDSK cannot continue in read-only mode.” That separate wording can arise from how CHKDSK was invoked or whether it can obtain access to a volume. Here the key question is why Windows considers the target protected against writing. If your exact error says read-only mode instead, follow the related read-only CHKDSK diagnosis.
Look for a simple physical or connection cause
Some SD cards and adapters have a small lock tab. Power down or safely eject the device, inspect the tab, and ensure it is not in the locked position. Reinsert it once and check whether the card is recognized at its expected capacity. Do not repeatedly slide a loose tab back and forth while the card is being read. A faulty adapter or reader can also misreport the state, so one known-good reader may be a useful control when the card itself seems stable.
USB sticks generally do not have the same SD-card lock mechanism, although particular models may have hardware protection. Look at the actual device rather than assuming every removable medium has a switch. Test a different port or cable only if the device is stable enough to do so. If it disconnects repeatedly, becomes extremely slow, or reports serious read errors, stop. Imaging or professional recovery is safer than repeated attempts to force a write.
Read access changes the priority
If files remain accessible, copy the irreplaceable ones now. Keep the folder structure and note any files that fail to copy. Verify several files on the destination before considering CHKDSK. If nothing is readable but the device stays recognized, the situation may be a logical file-system problem. Do not format or initialize it to clear the message. Those operations change the source and may complicate later recovery.
On a shared work computer, a policy or security tool may intentionally make storage read-only. Ask the administrator before changing attributes. An encrypted volume may also require unlocking before normal access; changing its disk flags is not a substitute for the correct key. The message is a clue to investigate, not permission to disable every safeguard.
Inspect Windows’ read-only state without changing it
After copying accessible files, you may inspect the disk attributes. Open an elevated Command Prompt and start DiskPart. Use list disk to display disk numbers and capacities. Match the target by size and connection, then use select disk N with the verified number. Run attributes disk to view the current read-only flags. Finally, type exit. These commands are for inspection in this order; selecting the wrong disk can make later operations dangerous.
A displayed read-only attribute can reflect a deliberate setting, but it can also appear with a device that refuses writes for another reason. Do not automatically follow inspection with attributes disk clear readonly. First establish why the state changed and whether a verified backup exists. Clearing an attribute will not repair a failing controller or damaged flash memory. If the drive is unstable, stop the command-line investigation instead of trying a different tool to force the same write.
Check Disk Management too. Does the target show the expected capacity and file system, or does it appear RAW or unallocated? An unexpected capacity or disappearing device is a stronger warning than the write-protection text alone. If the volume is RAW, a repair command may rewrite structures needed for recovery. Preserve the source, identify the physical disk, and consider a read-only recovery path first.
Recover missing files before a fixing pass
If important files are not accessible, do not use CHKDSK as an undelete tool. File-system repair aims to make a volume consistent, and it may change or discard damaged directory entries. Recover or image first. Drecov is Windows data recovery software for stable, recognized drives, USB storage, and memory cards. Its read-only recovery mode searches for lost files without treating CHKDSK as the first fix. Quick Scan, Deep Scan, filters, and preview help identify candidates before export to another healthy device. It cannot remove hardware write protection, repair a controller, or make an unstable drive healthy.
⚠ Warning: Install it on a drive different from the one where your data was lost to prevent overwriting.
When a partition has gone missing, Drecov’s Lost Partition Recovery can search for files associated with it. That does not repair the partition table or clear a policy lock. Use the file recovery for background and the Drecov for the Windows product. If the device clicks, disconnects, changes capacity, or reports severe errors, do not repeatedly scan it. Arrange an image or specialist assistance instead.
Step 1: Select the original protected volume
Stop writing to the affected storage. Connect a different healthy destination and make sure it has sufficient space. Do not install Drecov on the source volume. Open the program and select the original drive or card by its verified capacity and location. If the volume is absent but the physical disk remains stable and recognized, use the appropriate lost-partition path. Stop if the device becomes unstable during selection.
Step 2: Start Quick Scan and look for important files
Run Quick Scan first. Check expected folders and filter by filename, type, path, date, or size where available. Preview a few representative files. A result that shows only a name is not enough to prove the contents survived. If you can already copy intact files through File Explorer, prioritize that simple path rather than scanning without need.
Step 3: Use Deep Scan only while detection is stable
If Quick Scan misses the needed files and the device remains consistently accessible, try Deep Scan. It may uncover additional file candidates even when old folder paths are incomplete. Stop if read errors increase, the device drops offline, or response becomes erratic. More scanning cannot restore overwritten data or repair physical damage.
Step 4: Save to another device and verify
Recover selected results to the healthy destination, never back to the write-protected source. If the output is not where you expected, check for a Drecov folder or Recovery folder on that destination. Open documents, photos, and archives in their normal applications. Compare representative contents, not just filenames. Only after verification should you consider changing attributes or running a repairing disk check.
⚠ Warning: Install it on a drive different from the one where your data was lost to prevent overwriting.
Decide whether removing write protection is appropriate
There is no universal “unlock” step. A physical tab can be repositioned. An administrator policy must be handled by its owner. Encryption needs the proper unlock method. A Windows read-only attribute may be cleared when you know it was set intentionally, the device is healthy, and the data is protected. A failing flash device may remain read-only even when a software flag changes; forcing writes then is not a data recovery strategy.
If you have a verified backup and the disk remains stable, remove only the restriction whose cause you have identified. Then test a small, noncritical write on the volume if that is appropriate for the device. If the write fails again or errors appear, stop. Do not format just to see whether formatting succeeds. Repeated write tests can obscure the original problem and may make file recovery harder.
For USB-specific causes, the separate guide to a write-protected USB drive covers device settings in more detail. This page focuses on the CHKDSK error and on choosing whether a disk check belongs in the sequence at all.
Only then consider CHKDSK and verify its result
After the data is copied or recovered and the write-protection cause is resolved, decide whether the file system still needs repair. If ordinary reading and writing work and no file-system errors remain, a fixing pass may be unnecessary. If Windows continues to report errors, use the documented CHKDSK options for the verified volume and understand that /f modifies file-system metadata. Keep the backup available while the check runs.
Do not run a repair against an unstable drive. If CHKDSK stalls, the device disconnects, or new read errors appear, stop and reassess hardware health. A successful completion message also needs real-world verification. Reopen several files, compare folder counts, and test whether the original application can use its data. Check the destination backup rather than deleting it immediately.
If the write-protected message returns, record the exact wording and the observed disk state. The device may be reverting to read-only because of a deeper problem. Repeating a command without changing the underlying condition does not make the repair safer. At that point, protect the remaining readable data and consider replacement or specialist diagnosis.
Conclusion
When Windows cannot run disk checking on a write-protected volume, identify why writing is blocked before attempting repair. Copy accessible files, inspect the device’s physical and Windows state, and stop if it behaves like failing hardware. If files are already missing on stable storage, Drecov can scan the original location and recover verified candidates to another healthy device. CHKDSK comes later, only when the source is protected and a fixing pass is actually needed.
⚠ Warning: Install it on a drive different from the one where your data was lost to prevent overwriting.
