How to fix a ReFS Dev Drive on Windows?

Ever tried editing a file on your ReFS Dev Drive only to get "This media is write-protected" or "unexpected error code 19"?

Welcome to the non-deterministic future of operating systems, where a sneaky update or a rogue policy can all but brick your drive - while tools like diskpart and chkdsk claim there's nothing wrong.

Buckle up for the failures: takeown/icacls flops, registry tweaks do nothing, and ReFS's locked metadata mocks NTFS fixes. The real culprit? A combination of broken identity and BitLocker, apparently.

Background

I don't use my Windows machine much anymore. Waiting for that expensive, incredibly powerful paperweight to slowly and painfully boot up, just to experience the sluggishness and instability of Windows 11 is not my idea of fun.

But sometimes I do. It still has a slightly better battery life than my Mac mini, so for that sweet 30-minute stint of working on the couch it's still my go-to device. That's as long as the battery lasts.

Anyway.

I booted up my trustworthy Dell AI-PC.

I call it trustworthy, because you can 100% trust it to screw up whatever you're trying to do 😅

And lo and behold, I couldn't even change ONE markdown file on my website's repository - because my Dev Drive had suddenly become write-protected.

Nice.

A Familiar Pattern Emerges

I've had my fair share of issues with Windows Updates in general, and some patches randomly breaking Access Control Lists - like this time, when winget just completely blew up because Windows decided nobody (and I do mean NOBODY, BUILTIN\Administrators and SYSTEM identities included) needs to access C:\Program Files\WindowsApps.

This time, a completely unrelated issue felt... oddly similar.

A drive shouldn't just become readonly/write-protected by itself. But mine had.

I knew a bunch of ways to fix this. Or so I thought.

What did I try?

Feel free to skip past this section, as I slowly descend into madness.

Attempt 1: takeown.exe

I tried running takeown.exe to take over all files and folders on the drive.

$path = "D:\"
takeown.exe /F $path /A /R /D Y | Out-Null
ERROR: The media is write protected.

Result: Failed immediately.

Attempt 2: Reset ACLs

And of course I tried to reset/modify the Access Control List (ACL):

$Path = "D:\"

# Reset ACLs to defaults
icacls $Path /reset /T /C

# Then try Set-Acl again
$acl = Get-Acl $Path
$acl.SetOwner([System.Security.Principal.NTAccount]"BUILTIN\Administrators")
Set-Acl -Path $Path -AclObject $acl

Can you guess how much of that works?

Drumroll, please...

The first line. The first line works flawlessly. Nothing else.

Result: Utter and pitiful failure.

Attempt 3: Check disk properties

Oh, and I did run diskpart to remove readonly bit:

diskpart

list volume

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     C   OS           NTFS   Partition   1828 GB  Healthy    Boot
  Volume 1     D   Dev Drive    ReFS   Partition     51 GB  Healthy

select volume 1
attributes volume

  Read-only              : No
  Hidden                 : No
  No Default Drive Letter: No
  Shadow Copy            : No

Right - it was NOT set to read-only! The drive should not be write-protected.

Result: Useless - diskpart thought nothing was wrong. 0 progress.

Attempt 4: Registry tweak

And I DID use the Windows Settings UI (also known as regedit) to modify this setting: HKLM\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies\WriteProtect by setting it to "0" (that's "false" in the "Easy Windows UI language").

What did that do? Nothing. It did nothing.

Result: Complete and total failure.

Attempt 5: chkdsk

And chkdsk? That doesn't do anything.

chkdsk D: /f /r /x
The type of the file system is REFS.
The ReFS file system does not need to be checked.

Result: Does Jack Sht for ReFS lol.

... what gives?

Problem

The problem with this particular case is that no matter what you do, you'll get one of these 2 exceptions or errors:

Error 1: Code 19 - "unexpected error code 19" or similar

• This sounds scarier than it should, because it can mean all kinds of driver issues or corrupted file system.
• If you ask Copilot what this means on a ReFS drive, it'll tell you the drive is about to implode because of corrupted ACLs and recommend you format the drive as soon as you can.

Error 2: Readonly - "This media is write-protected." or similar error.

• It's not REALLY write-protected.
• It's not really; this is just the way ReFS displays that you in particular are not allowed to do anything with the files.

Reason

You might have already realized what I - at the time - did not.

Practically none of the stuff that I tried works on ReFS. And that's exactly the file system I had chosen for my Dev Drive!

Why ReFS?

Because that's the point of the Dev Drive! Dev Drive is faster than your usual drive (on Windows anyway) because it uses ReFS, which ships with a locked-down root ACL and SYSTEM ownership by default (or so I thought based on Microsoft's documentation).

The truth is, ReFS does ship without some of the baggage that NTFS has. But it isn't quite as straightforward as I thought.

Dev Drive intentionally minimizes metadata updates and locks volume metadata for reliability and performance, so ordinary ownership/ACL changes kind of simply... do not work. Which is part of the reason why you see "media is write-protected" or error 19 when you run takeown/icacls as an administrator.

If you try Copilot's suggestions on what to do, it'll tell you to impersonate another admin, re-run takeown.exe & icacls again and again, and again.

The immediate reason for this is that the ReFS drive has somehow lost the ownership information for your user account. This can happen for various reasons, such as:

• You changed your user account
• You moved the drive to another computer
• A Windows update broke the ACL (again)

... but while all of that Set-ACL stuff probably will never work very well on ReFS, you SHOULD be able to run takeown and get the ownership of the files and folders back.

And in my case, it didn't work.

... what's up with that?

Solution

Well - remember that this is my Dev Drive, right? That's why I don't have BitLocker enabled on it.

Or, rather, I DID NOT have BitLocker enabled on it. Before now!

After a new Group Policy or a rogue Windows Update... I did. And never noticed!

Until after another Windows Update broke the ACLs somehow. That certainly did make me notice it!

Step 1: Check BitLocker Status

I ran manage-bde to see if this was correct:

manage-bde -status D:

Size:                 51.00 GB
BitLocker Version:    2.0
Conversion Status:    Used Space Only Encrypted
Percentage Encrypted: 100.0%
Encryption Method:    XTS-AES 256
Protection Status:    Protection Off
Lock Status:          Unlocked
Identification Field: Unknown

ERROR: An error occurred (code 0x80070490): Element not found.

How great is this?! Windows Update was really double-teaming me this time...

Step 2: What Should Fix It

Anyway - kind of random, but since I open this laptop up about once per week, something is bound to break every time I do.

So - the solution, of course, is to disable BitLocker, and THEN takeown.exe all of the directories (because ReFS will probably not let you take ownership of files anyway!)

But since BitLocker didn't even think it was enabled, I needed to start by enabling it:

manage-bde -on D:

And if this just throws a random error (or like in my case, BSODs the whole machine!), there's a fair chance you can enable it through the UI (like I did):

Step 3: Enable and Disable Protectors... To Turn BitLocker Off, Finally!

Then you can enable (selected) protectors on the drive... And then disable them.

manage-bde -protectors -enable D:
manage-bde -protectors -disable D:

I assume this is actually what fixes whatever broken metadata BitLocker had in place - because after running them, you can finally run this:

manage-bde -off D:

If you try disabling Disk Encryption while it's enabled but BitLocker doesn't think it is enabled, it will fail with the following error:

BitLocker Drive Encryption: Configuration Tool version 10.0.26100 Copyright (C) 2013 Microsoft Corporation. All rights reserved.
ERROR: An error occurred (code 0x80310001): This drive is not encrypted

Step 4: Take Ownership

Anyway. Your Via Dolorosa is almost at its end.

Now you can run takeown:

takeown /F D:\ /A /R /D Y

And if everything is good now, you should see something like this:

So after one BSOD, a lot of errors (and new error codes!) and a long wait on BitLocker, this fun trip down the Windows Administration lane is finally over, and you can get back to work. This is your dev machine, after all!

And hopefully you will never, ever have to figure this one out again.

... but because I'm 90% sure this'll blow up again, I'm writing the solution down. Maybe it'll help someone else too :)