Windows Will Stop Mounting ReFS USB Drives in January. Copy Yours Off Now.

Written and maintained by the Desert Data Recovery lab team. · Updated November 13, 2026

Most of what we write is about drives that actually failed. This one is about a drive that will look failed on a date you can put on a calendar. We would rather you copy it off in December than ship it to a lab in February.

What Microsoft changed

Microsoft's KB5130741, "Hardening changes for ReFS volumes on removable media", published October 13, 2026, says ReFS on removable media, such as a USB disk, is not a supported configuration. The change applies to all supported Windows platforms and comes in two phases:

• October 13, 2026 update, audit phase. Windows still mounts the volume. It logs a warning, Event ID 524 from source ReFS in the System log, saying the volume is on a removable or externally attached disk and will not be mounted if a block policy is enabled.
• January 2027 security update, enforcement phase. Auditing and blocking are both on by default. A ReFS volume on qualifying external media is blocked from mounting unless an administrator changes the setting. January's Patch Tuesday falls on January 12.

NTFS, exFAT, and FAT32 drives are not part of this. Neither is an internal ReFS data volume.

Who actually has a ReFS USB drive

Almost nobody by accident. Windows does not format a new USB stick as ReFS on its own, and store-bought external drives ship as exFAT or NTFS. The people who have one picked it: a backup target formatted ReFS for a backup tool, an external disk moved off a Windows Server, a big USB enclosure someone set up as ReFS because it is the "resilient" filesystem. Those are exactly the drives that tend to be the only copy of something.

Check now. It takes a minute and writes nothing.

1. In File Explorer, right-click the external drive, choose Properties, and read File system.
2. Or in PowerShell, run Get-Volume and look at the FileSystemType column.
3. Or in Event Viewer, open Windows Logs, System, and filter for Event ID 524 from source ReFS. If the PC has the October update and you have plugged in an affected drive since, the warning is there, once per volume per boot.

If it says ReFS, the fix before January is boring: copy the data to a supported place, verify the copy opens, and only then decide what to do with the drive. If the drive is the backup, the supported place can be an NTFS external disk. We wrote about proving a copy before deleting the old one, and the same rule applies here. Reformat the ReFS drive only after you have opened the files from the new copy.

After January: it won't open. Don't "fix" it.

Microsoft's article does not describe exactly what File Explorer or Disk Management shows for a blocked volume, so we will not guess at the screen. What you will know is that a drive that opened last week does not open now. Every reflex from there is a write:

• Format. If Windows offers to format the disk, cancel. A format writes a new filesystem over the ReFS one.
• CHKDSK or Scan and repair. They are writes when they run, and nothing on the drive needs repairing. See CHKDSK /f is a write.
• Initialize Disk, Delete Volume, diskpart clean. Those make a new empty disk. See Initialize Disk is a wipe.
• A recovery program that writes to the same disk. Nothing was lost, so there is nothing to undelete. A scan that saves results to the patient drive overwrites it.

Getting the files back is an access problem

Microsoft built in the way out. The setting is RefsRemovableDeviceMountPolicy: 0 is off, 1 is audit (the current default), 2 is block. It exists as a Group Policy value under HKLM\SYSTEM\CurrentControlSet\Policies and as a registry value under HKLM\SYSTEM\CurrentControlSet\Control\FileSystem. When both are set, Group Policy wins, and the change needs a restart.

On a home PC, setting it back to audit long enough to copy the drive off is the use Microsoft describes. On a managed work PC, a local registry change will not override what IT pushes through Group Policy, and it should not. Ask them. Either way, the order is the same: let it mount, copy everything to a supported disk, open the copy, then stop depending on ReFS over USB.

Microsoft's own deployment notes say to make sure required data is available from supported storage before enforcing the block. That is the whole article for a home user, too.

When it really is a recovery case

The block can sit on top of a real failure. If the policy is off and the volume still shows RAW, the ReFS metadata may be damaged, and that is our ReFS RAW page. If the drive clicks, drops off the bus, or is not detected at all, the filesystem is not the first problem. See external drive not recognized and clicking hard drives. And if someone already formatted it, ran repair, or initialized it, stop there so nothing else writes, and note exactly what ran.

We image the drive first and work from the image. What is recoverable depends on the drive and on what was already done to it. We find that out in the evaluation and tell you before you owe anything. The public case log has no ReFS volume and no drive blocked by this policy, and we will not invent one. We don't advertise a success rate.

Pack it the way any failed drive is packed, with a note of what Windows showed and any command anyone ran. Arizona drop-off is on the locations page. Everywhere else is mail-in. The work is external hard drive data recovery. The phone number on this site is (602) 686-2622, Mon–Fri 9:00am–5:00pm.