Forum Discussion

MikeLabatt's avatar
MikeLabatt
Brass Contributor
Dec 03, 2023
Solved

ReFS volume inaccessible after update from Windows 10 22H2 to Windows 11 23H2

The starting point of this post was an up-to-date Windows 10 22H2 system, with two mirrored Storage Spaces (one NTFS, the other ReFS).

 

ReFS always was officially supported in this scenario, as this is Windows Pro for Workstations. The ReFS volume was formatted directly with ReFS version 3.4, six months ago. BitLocker is enabled.

 

Today I gave in to the insisting Windows Update prompts, finally allowing it to update to Windows 11 23H2. All went apparently well, without pre-check warnings, and with no update errors.

 

After the update to Windows 11 (build 22631.2715, refs.sys 10.0.22621.2506), the ReFS drive shows up as "Local Disk", but cannot be opened in File Explorer. The event log contains entries like "Volume X: is formatted as ReFS but ReFS is unable to mount it; ReFS encountered status The file system encountered a metadata file with inconsistent data."

 

On the affected system, fsutil fsinfo refsinfo x: now gives "Error: The file system encountered a metadata file with inconsistent data. A local REFS volume is required for this operation."

 

The storage space still mounts and works well on a different (Windows 10) system, providing these details:

 

REFS Volume Serial Number : [redacted]
REFS Version : 3.4
Number Sectors : 0x0000000121994000
Total Clusters : 0x0000000121994000
Free Clusters : 0x0000000022f8ff75
Total Reserved : 0x0000000000084548
Bytes Per Sector : 4096
Bytes Per Physical Sector : 4096
Bytes Per Cluster : 4096
Fast Tier Data Fill Percentage : 0.0%
Slow Tier Data Fill Percentage : 0.0%
Fast Tier to Slow Tier Rate (Clusters/s) : 0
Checksum Type : CHECKSUM_TYPE_NONE

 

This reminds me of similar issues Windows Server had last year after a Windows Update, although at the time the affected ReFS version was 1.x, while now it is 3.4:

 

https://techcommunity.microsoft.com/t5/windows-server-for-it-pro/refs-volume-appears-raw-version-doesn-t-match-expected-value/m-p/4002933

 

I suppose that the (expensive) workaround will be, as in the past, to copy everything to a storage space with a newer ReFS version, so I already ordered some new disks.

 

Perhaps ReFS experts stephc_msft or @RajDas_FS can give the issue a look?

 

P.S.: I found a comment at https://gist.github.com/0xbadfca11/da0598e47dd643d933dc that says "11 v22H2 (refs.sys 10.0.2621.1) can't mount 3.1 3.2 3.3 and 3.4 with read-only, or with RefsDisableVolumeUpgrade. Maybe bug."

 

  • Since opening this thread in December, I'd like to share two "solutions" (workarounds):

    1) As mentioned before, I attached the ReFS 3.4 volume which wouldn't read on Windows 11, to a Windows Server 2022 system, which auto-updated it to ReFS 3.7. Moving the disks back to the Windows 11 system, I can confirm that they now work fine. Storage Spaces on Windows 11 prompted to upgrade the pool, but the data was readable both before and after this upgrade. The ReFS version remained unchanged at 3.7. This solution does not require purchasing new disks, but it does require access to a Windows Server 2022 system.


    2) The other method is to get new disks and copy the data, using an OS version like Windows 10, which can read the ReFS 3.4 volume which became unreadable after the upgrade to Windows 11.

25 Replies

  • Hi all, 

    When using ReFS for internal drives, please consider to disable ReFS upgrade before upgrading to Windows 11 23H2 or 24H2.

     

    Important: Do not use ReFS for Windows OS drives or external / removeable drives.

     

    How-to temporary disable ReFS upgrades:

    It needs to be set before connecting an "online / mounted" volume to a newer OS. 

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
    "RefsDisableVolumeUpgrade"=dword:00000001

     

    Effect of this setting:

    Mounting a ReFS volume to a (newer) OS, with this registry key set - for this OS instance - will prevent upgrading to the lastest ReFS metadata version. 

    If you are using multi-boot, it needs to be the same for all OSes

     

    Reasons:

    On this thread, but also on GitHub as well as the previous gist, there are different reports about the issue. 

    There's a risk of duplicate reports, however there are also singular reports for "Windows Server 2025 / Azure Local 23H2" based issues. Reports here and on gist focusing on Windows Client OS.

    Generally, I sense a number of issue reports with the upgrade. These either take longer than expected or ReFS upgrade worked but files still cannot be read / accessed correctly. 

    Setting up the registry key will not upgrade your ReFS. Downgrade or rollback to previous Windows OS version are possible. 

     

    Next steps:

    We would require support requests and reproducible conditions, quite hard as one needs to simulate quite some fair amount of files and folders. 

    With empty or near empty small drives, I doubt this is going to be reproducible. 

     

    Possible issues:

    Disable ReFS upgrades gives peace of mind at the moment. Yet can cause outlier configs if people forget to disable the setting. 

    Means: ReFS version and OS version no longer match. 

     

    Reverting the change:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
    "RefsDisableVolumeUpgrade"=dword:00000000

    Please mind, that ReFS upgrade will cause read and writes during the upgrade time. There's no progress visible. The upgrade takes time based on media type, like HDD vs NVMe, size, and number of TB of files. 

     

    Be mindful: There is no command to initiate the ReFS upgrade, monitor or revert (downgrade) ReFS. Mind when using Spaces Spaces, do not upgrade the Pool if you want to roll back to an older release or need to access the Pool from different OS Versions (multi-boot). 

     

    Recommendation for reporting issues:

     

    Before upgrading 

    Include the Windows version, build and Edition of the OS before upgrading to 23H2 /24H2. Find these with get-computerinfo or PC-Infos in settings app

    Include information or Screenshots from Get-Volume 

    Include Information about ReFS version

    fsutil fsinfo refsinfo DriveLetter:

    Windows 11 22H2, 23H2 and 24H2 do not share the same versions of ReFS. 

    Do you use Windows default storage drivers? 

    What's the amount of files, folders and TB of data? 

    Do you use AMD or Intel RAID / VMD? 

    Do you use Storage Spaces? 

     

    Post upgrade

    Include the same information. 

    If ReFS upgrade is not disabled, please let it work in the background to upgrade. Avoid reboots and other changes, storage driver updates etc. 

     

  • harlam357's avatar
    harlam357
    Copper Contributor

    Experienced the exact same issue. ReFS volume is in a storage space and is ReFS version 3.4. Update to Windows 11 23H2 rendered the volume inaccessible. I rolled back to Windows 10 22H2, which restored access to the volume.

    I then downloaded the Windows 11 24H2 iso and initiated the upgrade, from a usb drive formatted with Rufus, from within windows. After the upgrade the volume is visible, files and folders can be enumerated. However, all files are missing security info and cannot be accessed.

    I tried simply replacing all files security info with inherited permissions from the drive root, which did display accurate security information, but I received an error for each file stating that it was not accessible. I canceled the operation. Now what to do?

    Fortunately I have enough free space on my storage space array to carve out a new ReFS volume of the same size that is no longer accessible. Also fortunately, everything on the inaccessible ReFS volume is backed up on external SSDs. So, I simply restore everything from backups, deleted the original ReFS volume, and assigned the new volume to the previous volume's drive letter 🙂 and all is well.

    Sharing my experience because there are obviously still issues with ReFS compatibility when moving to newer versions of Windows, even the latest release. The only way to ensure your data is safe is to have multiple copies. The positive part of my "solution" is that the new ReFS volume is version 3.14. While less compatible with previous versions of Windows, I'm hoping the kinks are worked out with these later versions of the file system and I won't have to go through this same exercise in the future.

  • Mark Berry's avatar
    Mark Berry
    Copper Contributor

    Thanks for this post. I hit this issue after doing an in-place upgrade of Windows 10 23H2 Enterprise to Windows 11 24H2 Enterprise. A secondary disk (not the OS disk) was formatted as ReFS. In fact, all attempts to upgrade to 11 23H2 failed; even booting from the ISO caused a blue screen--I wonder if the ReFS volume was the issue. At least the 24H2 upgrade worked, but then I had an unreadable volume.

    To get access to the data, I booted from a Windows 10 installer ISO, got to a command prompt, and used RoboCopy to copy data from the ReFS disk to an NTFS disk. First use diskpart with "list vol" to get the drive letters as assigned in the recovery environment. Then, for example, to copy a E:\VMExport folder to F:\DriveE\VMExport:

    robocopy "E:\VMExport" "F:\DriveE\VMExport" /E /B /XJ /DCOPY:T /COPY:DAT /R:0 /W:0

    The params are described here;

    https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy

     

  • albert975's avatar
    albert975
    Copper Contributor

    We installed a Western Digital NVME Black in a Windows 10 Enterprise workstation with the latest build. The format of the drive is ReFS. When we upgraded the OS to the Windows 11 Enterprise, this drive was not recognized. This drive works well in the Windows 10 Enterprise environment and it is recognized in the BIOS. WD claims no one ever has reported such an issue as mine. What is the solution to this problem?

  • Hey MikeLabatt
    I am facing the exact same issue. 
    Updated to Windows 11 because of the annoying popups. 
    Going back to Windows 10 is not a solution. I can´t read the ReFs File system any more. 

    Running  ReFSUtil Salvage -QS I: C:\refsutil  get´s no errors as far as a can see. 
    Versión de ReFS: 3.4

    Using https://www.reclaime.com/ I can see that all the files are there. 

    I have 3 x 4TB drives in parity mode. No hardware problem found.
    Now I am waiting for a new drive to copy all my data. 
    This is not what I was expecting from a "Resilient " File System.

    No solution found yet. Let me know if you get some success.

  • takeota's avatar
    takeota
    Copper Contributor
    Just the other day, I had a BSoD caused by ReFS.sys when I connected my Windows 10 storage space (4 HDDs with ReFS format) to the SATA interfaces of my newly installed Windows 11 PC.
    Probably a similar problem.
    • MikeLabatt's avatar
      MikeLabatt
      Brass Contributor
      There is a terse "ReFS 3.10 is no longer compatible with ReFS 3.4." comment at https://gist.github.com/0xbadfca11/da0598e47dd643d933dc

      Could this be our scenario (if it means that 3.4 has been dumped from the latest Windows 11/Server 2022), and if so why is it not documented anywhere?

      Per the original post, I am unable to mount a 3.4 volume (which mounts fine on Windows 10) after an upgrade to Windows 11, and it seems like this is not an isolated case.

      Because I saw it mentioned in the linked GitHub post, I'd like to add that the affected system does not have RefsDisableVolumeUpgrade set. The volume also is not read-only.

      Thanks stephc_msft RajDas_FS
      • MikeLabatt's avatar
        MikeLabatt
        Brass Contributor

        Update... Out of curiosity, I attached the same ReFS 3.4 (mirrored storage space) volume which won't mount on Windows 11 (but works fine on Windows 10), to a Windows Server 2022 system. Not only it mounts fine, but it auto-updated to ReFS 3.7 (per fsutil fsinfo refsinfo x:)

         

        Right now I can't power off the Windows 11 box to see if the disks mount fine there as well after the update to 3.7, but I will post an update. There is some hope that the updated volume can now be seen by Windows 11 without requiring the lengthy copy process. Still a waste of money and time on new disks and troubleshooting before Christmas, while there has been no official answer here in more than two weeks...

    • Karl-WE's avatar
      Karl-WE
      MVP
      hi there it might be related had the same when upgrading from one version of Windows Server v.Next to a newer one, documented it in Windows Server Insider back then.
      • MikeLabatt's avatar
        MikeLabatt
        Brass Contributor
        Hello Karl-WE, are we talking about this thread:

        https://techcommunity.microsoft.com/t5/windows-server-for-it-pro/refs-volume-appears-raw-version-doesn-t-match-expected-value/m-p/3058652

        In that case, ReFS 1.x was silently deprecated by a Windows Update, and the error type was immediately helpful about the version issue ("Version 1.2 doesn't match expected value 3.4"). Here however we are dealing with ReFS 3.4 or higher, and the error is "The file system encountered a metadata file with inconsistent data". Sure, it's again an issue that came up with a Windows update/upgrade, which shouldn't have happened in the first place. I do see a pattern, and while we can accept things being deprecated for the sake of progress, the lack of warnings before this happens and then waiting a week or more for an answer are not good.

        Can somebody Deleted perhaps escalate this?

Resources