Storage Spaces Direct Pool Read-Only After NVMe Firmware Fault: Data Still There, Access Gone
Several NVMe SSDs fail simultaneously across different cluster nodes, the Windows Storage Spaces Direct pool switches to read-only and degraded – and can no longer be brought online in the normal way. In this state the data is usually still present, it simply can't be written to any more. And it is precisely the next move that decides whether it stays that way.
On 1 September 2026, an operator described exactly this case publicly in a Microsoft Q&A post: in his Windows Storage Spaces Direct cluster (S2D for short, Microsoft's software-based storage solution that combines the local drives of several servers into one shared pool), several NVMe drives across different nodes had failed at the same time – in his assessment because of a faulty firmware state. The affected pools were subsequently read-only and degraded and could no longer be activated normally.
An important point for context: so far this is a single publicly documented report. Manufacturer, model series, firmware level, Windows Server version, resiliency layout and number of nodes are not named in the report. The only reply in the thread comes from a community member identified as an "Independent Advisor" – not from Microsoft Support and not from the drive manufacturer. The firmware cause is therefore an operator statement, not an independently confirmed diagnosis. As of our research on 5 September 2026, there is no Microsoft KB article, no manufacturer statement, no recall and no named firmware level relating to this specific incident.
Why the pool switches to read-only in the first place – and why that's a good thing
The write protection is not a fault, it's a protective function. Microsoft documents this clearly:
"When a storage pool is in the Unknown or Unhealthy health state, it means that the storage pool is read-only and can't be modified until the pool is returned to the Warning or OK health states." – Microsoft Learn, Storage Spaces and Storage Spaces Direct health and operational states
If the pool additionally shows the state Read-only / Incomplete, according to Microsoft there may be a loss of quorum: the majority of the pool drives have failed or are offline. Storage Spaces then automatically sets the pool to read-only until enough drives are reachable again.
The background here is decisive for any later data recovery: the pool metadata – the management information about which data blocks are located where – is stored on every drive in the pool. If several drives fail at once, it is therefore not only capacity that is lost, but potentially also the quorum and secured access to the metadata. Anyone who forces write access in this situation may be writing to an inconsistent structure – turning "no access, data intact" into a genuine data loss scenario.
Is there a known firmware bug behind this?
For this specific case: no, nothing substantiated. There are, however, documented historical parallels showing that firmware on NVMe SSDs really can bring down entire clusters:
- Intel P3x00 family (NVMe), firmware prior to "Maintenance Release 8": In its S2D troubleshooting guidance, Microsoft describes a critical bug with symptoms such as Lost Communication, IO Error, Detached and No Redundancy, as well as slow I/O. At least Maintenance Release 8 is recommended; because of differing OEM version strings, Microsoft explicitly refers users to the OEM. This device family is not named in the current report.
- Samsung 980 PRO, firmware 3B2QGXA7: In 2023, Puget Systems reported – citing Samsung – on a problem with this firmware level and recommended updating to 5B2QGXA7. That is not an S2D case, and likewise not an identification of the drives affected here.
Both cases are comparative material, not an explanation. Technically, alongside a firmware bug, a common backplane, power, driver or network fault would be just as plausible – as long as no SMART/NVMe logs, event IDs, serial numbers and firmware levels are available.
Who and which devices are affected?
- Environment: Windows Storage Spaces Direct with several NVMe drives across several cluster nodes. Windows Server version not named.
- Drives: manufacturer and models not named, firmware levels not named.
- Publicly documented scope: 1 operator report dated 01/09/2026, 1 community reply, no comments. Number of organisations, drives or nodes actually affected: not publicly documented.
In practical terms this means: anyone running an S2D cluster with NVMe SSDs who is currently seeing a read-only or degraded pool should consider themselves affected – regardless of whether firmware, hardware or something else turns out to be the cause.
How to check whether your Storage Spaces Direct pool is affected
The following steps are purely read operations and documentation. They are explicitly not repair steps. Do not run any write tests, repair or reset commands.
- Record the situation: note the date and time of the failure, the affected nodes, and the last change carried out (update, maintenance, firmware, driver). Immediately protect existing backups and replicas against being overwritten – pause backup jobs that would write over the older states.
- Query the pool state read-only: Get-StoragePool -IsPrimordial $False | Select-Object FriendlyName,HealthStatus,OperationalStatus,ReadOnlyReason,IsReadOnly. Microsoft associates Read-only/Incomplete in particular with a possible loss of quorum.
- Record the virtual disks: Get-VirtualDisk | Select-Object FriendlyName,HealthStatus,OperationalStatus,DetachedReason. Note whether Degraded, Incomplete, Detached or No Redundancy appears.
- Inventory the physical drives: Get-PhysicalDisk | Format-Table FriendlyName,SerialNumber,HealthStatus,OperationalStatus,Size -Auto as well as, for slot and firmware information, Get-PhysicalDisk | Get-StorageFirmwareInformation. Document manufacturer, model, serial number and the full firmware level.
- Only view the resync/repair status: Get-StorageJob. As long as repair or resync jobs are running, no further node may go offline in the planned maintenance sequence.
- Check firmware against the approved list: exclusively against the list from your cluster OEM or integrator. With hardware based on the Intel P3x00 family, explicitly clarify whether the OEM firmware corresponds to a level prior to Maintenance Release 8.
- Save diagnostic data – but not onto the ailing pool: Get-StorageDiagnosticInfo collects event logs, existing traces and live dumps from all nodes; the exact syntax depends on the Windows version. The target directory must be an independent, healthy storage medium.
- Open tickets: with this inventory, with the hardware/S2D solution provider and with Microsoft. For S2D problems, Microsoft requires in any case that the certified model be verified and that you work together with the vendor of the suspect drives.
What you should do now – protective measures that don't make things worse
- Stop writing applications in a controlled manner. Every further write attempt to an inconsistent pool is risk without benefit.
- Do not start any further node maintenance before the state, resiliency and resync status have been clarified. Microsoft's regular maintenance sequence (check, drain node, apply Storage Maintenance Mode if applicable, resume node, let all storage jobs complete) applies to plannable maintenance on a healthy cluster – it is not a licence to keep working on a pool that is already read-only/unhealthy.
- Document everything: pool, virtual disk and physical disk states, serial numbers, firmware levels, timestamps. This data later determines whether reconstruction is possible.
- Isolate backups. Check which backup state is genuinely complete and readable – on a separate medium, not by writing back to the affected pool. If you want to rebuild your own backup strategy afterwards, you'll find guidance in the backup assistant.
- Involve the OEM, integration partner and Microsoft Support before any firmware activation, any write-protection reset and any recovery override. Because model and firmware data are publicly missing in this case, this is mandatory.
- Use only approved firmware – directly from the OEM, solution provider or drive manufacturer, after reviewing the release notes and after testing on identical hardware.
"Firmware updates are a potentially risky maintenance operation and you should only apply them after thorough testing of the new firmware image." – Microsoft Learn, Updating drive firmware
What you must not do under any circumstances
This section is the most important one. The following actions are exactly what turns a recoverable state into permanent data loss.
- Forcing the write protection off. A blanket "force mount" or an isolated Set-StoragePool -IsReadOnly $false while drives or nodes are still missing can trigger writes to an inconsistent structure. Microsoft only describes resetting to read-write in the Incomplete state after missing drives have been reconnected and, with S2D, all servers are back online. The Independent Advisor in the Q&A puts it like this: "There is no supported 'force-mount' switch to override that protection, because doing so risks corruption."
- Reset-PhysicalDisk on an affected drive. Microsoft describes this operation as deleting all data on the drive. Never as a first repair attempt.
- Clear-Disk, initialising, deleting partitions or volumes, formatting. That deletes volumes and therefore data – irreversibly.
- Disabling S2D, rebuilding the cluster or pool, removing cluster resources while analysis or data recovery is still pending. Microsoft's instructions for destroying an existing S2D cluster serve the purpose of reusing drives – not data recovery.
- DiskRecoveryAction, DiskRunChkDsk, Data Integrity Scan and other recovery overrides without diagnosis. Microsoft documents these only for very specific states; DiskRecoveryAction can bring a volume online read-write without any checks. A running crash recovery scan will also start again from the beginning after an abort or node restart.
- Installing unverified firmware or images from third-party sources. During NVMe firmware activation, a drive may temporarily stop responding to I/O because of an internal reset; according to Microsoft, direct firmware cmdlets on cluster drives can halt I/O. On an already degraded pool, that is an additional and avoidable risk.
- Papering over the symptoms. Anyone who "just rebuilds from scratch" when the pool is no longer readable destroys precisely those metadata remnants from which reconstruction would otherwise have been possible.
It is almost never the failures themselves that ultimately cost the data – it's the well-meant rescue attempts afterwards. The pool was read-only because the system wanted to protect the data. Anyone who overrides that protection before the actual situation is known removes the very basis for data recovery.
Why this case belongs in professional hands – and how RESQ helps in concrete terms
A read-only Storage Spaces Direct pool after multiple NVMe failures is not a single-disk problem, but a distributed metadata and consistency problem spanning several servers. That is precisely what separates professional data recovery from attempts made in live operation:
- Working on copies, not on the original. Before anything is reconstructed, the affected NVMe SSDs are read out sector by sector and secured. All further analysis runs on these images. The original remains untouched – the decisive difference from any repair command that writes directly to the drives.
- Handling suspect drives. SSDs that drop off the bus due to an internal error state, no longer respond cleanly or are only intermittently reachable need controlled read-out procedures rather than repeated power-on attempts. For cases involving physically damaged storage media, the cleanroom environment is available.
- Reconstructing the array structure. Because pool metadata is held on every drive, the mapping of the data blocks can often be traced from the secured images – even when the pool itself no longer comes online in the cluster. This is detailed work on structures, not a click-and-go solution. How this works with distributed storage arrays is described under RAID and NAS data recovery.
- Experience with exactly this failure pattern: several SSDs failing at once, loss of the majority in the array, degraded and read-only state – this is a recurring pattern in which the order of the steps determines the outcome.
Here's how it works at RESQ: you describe the case, we provide a free initial assessment – including an honest statement of what we consider realistic and what we don't. After that you receive a cost estimate, and only then do you decide whether we should go ahead. There is no obligation to pay upfront into the unknown. What we don't do: promise a successful recovery. Every storage array is an individual case, and that applies all the more with several NVMe drives failing at the same time.
If you want to be sure that your data isn't lost through a forced write access or an ill-considered reset, have the case assessed before you change anything: request a free initial assessment and cost estimate. You'll find an overview of services and procedures under Data recovery at RESQ; if you'd like to place the order directly, you can create an order via your customer account.
Conclusion: the write protection is your window of time – use it
The incident reported on 1 September 2026 is so far an isolated case with no independently confirmed cause, no named manufacturer, no specific firmware level and no official fix. What is solid about it: a Storage Spaces Direct pool in the Unknown or Unhealthy state is read-only, a pool in the Read-only/Incomplete state may have lost its quorum – and in both cases the data is as a rule still there, just no longer accessible.
This state is not an emergency in which you have to force something immediately. It is a window of time: document, save diagnostic data to a separate target, protect backups, involve the OEM and Microsoft – and no writes to the pool. If you aren't sure whether the next command will help or harm, it is the wrong command.
Have the case assessed before you lift the write protection. Go here for the free initial assessment – with an honest statement about the prospects and a cost estimate, before anyone touches a drive.
