Your NAS Went Read-Only. That's the Copy-It-Now Window.

Written and maintained by the Desert Data Recovery lab team. · Updated October 22, 2026

We already wrote about Synology Volume Crashed and Repair, about QNAP Volume Not Active and Recover, and about a DSM update on a Degraded pool. We wrote about Unraid Format and a TrueNAS pool that will not import, about a ZFS scrub and Replace, and about zpool import -F. A Storage Spaces Direct pool that went read-only after NVMe drives dropped is that page. Several bays that emptied in the same minute are the controller page. This page is the screen those jobs are not: the share is still up, and the volume will not take a write.

Read-only means the next write was refused

A NAS volume is a stack. Under the share there is a RAID or a pool, then a filesystem — Btrfs or ext4 on a lot of Synology and QTS volumes, ZFS on TrueNAS and QuTS hero, XFS on a stock Unraid array disk. Read-only is a decision at one of those layers to stop changing the disk. It is not a diagnosis of which layer failed, and it is not a statement that the files have been erased.

The honest reading, when the share is still up, is the protective one. The system hit an error it would not write through. On btrfs, that can be a metadata block that failed the tree checker. On a QNAP RAID group, it can be more disk failures than the RAID type tolerates. On ext4, it can be the errors=remount-ro behavior. The volume is still mounted, and the files can still be read. That is often the last quiet moment. The clicks people reach for next are the ones that write, unmount, or reboot, and any of those can be the moment the share stops opening.

Two other read-only states are not this failure. An administrator can import an OpenZFS pool with readonly=on on purpose. That property can only be set at import. And Synology documents a second cause on the same status: a volume migrated from another Synology that has, or used to have, a feature this model does not support, such as WriteOnce or immutable snapshots. Their article says that incompatibility does not cause data corruption. Their fix for that cause is to update the operating system, or to move the drives to a compatible Synology and assemble the pool. If you know that is the banner you have, it is not a drive-error window. Copy anyway if this volume is the only copy, because the update does not put the files on different media. If you cannot tell a feature mismatch from a disk error, treat it as the disk error.

What each system actually calls it

Synology. Storage Manager shows the volume as Read-only. The article "My volume has become read-only," updated September 30, 2026, applies to DSM 7.0 and above and to DSM Enterprise. Under hardware malfunctions they name drive or filesystem failures, and they say those often lead to volume crashes. Their order for that path is File Station first: copy the data to another volume on the same Synology or to another storage device. Then Remove the volume, create a new one, and copy the backup back. The copy is the part to follow. Remove is a delete of that volume, and it belongs after a backup you have already opened on another machine.

The file-system-error article, updated March 20, 2025, is the check people run to "clear" the warning. On DSM 7.1 and above the system unmounts the volume and tries to repair it. On DSM 7.0, and on DSM 6.2 and below, it shuts the NAS down and tries to repair it. Either way the share goes away before you have the files. Data scrubbing is a different job: the DSM help calls it a feature that amends data that is incorrect or incomplete, and it can check and repair a shared folder only when that folder has data checksums turned on. A degraded pool is pulled out of the scrubbing schedule until it is repaired. An abnormal pool is listed as a reason scrubbing cannot run. Don't reboot the NAS to get a scrub to run.

QNAP. QTS 5.2's storage-pool table has Warning (Read-Only): one or more RAID groups are Not Active, and the note says it might be possible to recover some data from volumes and LUNs. QuTS hero h5.3 uses the same pool status. The note there says shared folders and LUNs. Not Active, on the QTS 5.2 RAID-group table, means one or more disks failed and the number of failures exceeds what that RAID type tolerates. If the share still opens, copy. If it does not, you are on the Not Active page. Recover RAID, in QTS 5.2, rebuilds a group whose disks were disconnected and put back in the original bays. QNAP says it does not help a failed disk, and while the group is Error the volumes are Inactive and the data is inaccessible.

QTS 5.2's Check File System "scans for and automatically repairs" errors on a thick, thin, or static volume. The volume is unmounted and inaccessible while it runs. The storage global settings also offer a RAID scrubbing schedule that scans for and fixes bad sectors on RAID 5 and RAID 6, and a scheduled file-system check that scans and automatically fixes volumes where QTS has already seen errors. None of those is a copy. QuTS hero is ZFS. A scrub or a forced import on that pool is the scrub page and the -F page, and moving the disks to TrueNAS to import them is a different mistake.

TrueNAS and OpenZFS. TrueNAS does not document a volume status named Read-only. The Import Pool steps are the Storage Dashboard, Import Pool, pick the pool, Import. Those steps do not include a read-only choice, and the same page says TrueNAS supports pool imports from the WebUI or the API only — a manual import from the command line can cause unexpected behavior. Don't drop to a shell to force this pool open.

OpenZFS has three states people flatten into "read-only." The pool property readonly=on can be set only at import, and the pool is then imported read-only. OpenZFS's troubleshooting ladder puts zpool import -o readonly=on -N before any rewind: import without mounting and without writing, so you can look. That ladder is for a pool that is not already up. If your shares are already open, you do not need it. zpool import -F is a rewind, covered on that page, and -F is ignored when the pool is already importable. A scrub reads the allocated data and, where another replica still matches, rewrites the bad copy. That is the scrub page. Don't export a pool you can still read so that a scrub or a replace has a read-write pool to work on.

A suspended pool is the state that is not a copy window. OpenZFS's failmode property, on the zpoolprops page, handles catastrophic pool failure, typically a loss of connectivity or a failure of all devices. wait, the default, blocks all I/O until the devices are back and the errors are cleared with zpool clear. continue returns EIO to new writes and still allows reads from healthy devices. Uncommitted writes stay blocked. panic crashes the system. zpool clear says that if the pool was suspended it is brought back online provided the devices can be accessed. Clearing a pool whose disks are still dropping is a resume through the fault. If the reads are already blocked, power it down and treat it as the path page or the import page, depending on what the status line actually says.

Unraid. Unraid's docs do not use Synology's Read-only volume status. A write error disables the disk. The replacing-disks page says Unraid has stopped using that disk for writes, the mark is a red X, and the disk is not always physically dead. With enough parity, Unraid emulates the disk and the data stays readable. The same page is blunt past that point: if more disks have failed than parity can protect, halt all write operations and do not rebuild. Copy what still opens. The filesystem check is a later step. For XFS or ext4 it is done in Maintenance Mode, which does not mount the array, so you cannot copy while it is running. Unraid's data-recovery page describes the WebGUI default for XFS as a read-only check, usually with -n. The file-systems page also shows xfs_repair -v with no -n, and if that command asks for -L, Unraid says to add it and calls that usually safe. The xfs_repair man page says -L zeros the log even when the log is dirty, and that this can lose user files and data. btrfs scrub on a replicated profile repairs from a good replica. btrfs balance moves the data. btrfs check --repair is the repair Unraid's file-systems page says to use only if you have been advised to, because it can lead to further issues. If the line on screen is "Unmountable" or Format, stop and use that page.

A generic Linux volume, under any of those boxes. The kernel's ext4 mount options include errors=remount-ro, which remounts the filesystem read-only on an error. errors=continue keeps going. errors=panic halts the machine. Those options override the behavior stored in the superblock, which tune2fs -e sets. We will not claim your NAS used remount-ro unless the mount options or the status say so. The same kernel document says ext4 replays the journal, and therefore writes, even when mounted read-only. ro,noload is the option that skips that replay. A reboot is a remount.

Btrfs documents the flip in two places. The tree checker verifies metadata before it is written. If a block fails, the filesystem refuses further writes and turns itself read-only to prevent further damage. The same section says some of the newest metadata updates are only in memory, so copy the files that matter before you unmount — once it is unmounted, those updates are lost. It also says the filesystem stored on the device is still consistent and should mount fine. That sentence is about this pre-write check. It is not a promise about a RAID group that has already lost too many disks, and it is not a reason to reboot before the copy. A transaction that cannot allocate memory also flips the filesystem read-only; the troubleshooting page calls that out under ENOMEM and says it is rare in a normal workload. btrfs check --repair carries a warning not to use it unless you have been told to, and only after accepting that repair cannot fix every corruption. Balance without filters moves data and metadata across the filesystem. A scrub on a replicated profile repairs damage by copying a good replica, and the scrub manual says a read-only scrub of a filesystem that is still mounted read-write can itself write. rescue= mount options require a read-only mount and do not allow a remount to read-write. They are a salvage mount, not a command to run tonight on the original disks.

What not to do while the files still open

Do not remount read-write, and do not "force" the volume. The read-only flag is the protection. Clearing it puts writes back on the disks that just failed a write. On Storage Spaces Direct that click is a different product, covered on that page. On a NAS it looks like a remount, a toggle, or a forum command. Same result.

Do not run the repair. Synology's file-system check unmounts or shuts down and then repairs. QTS Check File System unmounts and repairs. e2fsck -p preens the filesystem, and e2fsck -y answers yes to every question it asks; -n is the switch that opens the filesystem read-only, and it cannot be combined with either of those. btrfs check --repair repairs. xfs_repair without -n repairs, and -L zeros a dirty log. The man page says that can lose files and data. A no-modify check is still a full read of a volume that just reported trouble, and on these NAS screens the button in front of you is the repair, not the no-modify check. Copy first. The check can wait until the files exist somewhere else.

Do not scrub, balance, or rebuild. Synology data scrubbing amends data. QTS RAID scrubbing fixes bad sectors. A btrfs scrub reads the devices and, on a replicated profile, repairs from a good copy. A btrfs balance relocates block groups. A ZFS scrub rewrites a bad copy where another replica still matches. A RAID rebuild or a resilver reads every surviving member and writes a new one. That is the write in RAID rebuild vs. data recovery. If a scrub or a rebuild is already running, let it stop. Don't start a second full-volume job beside the copy.

Do not reboot, and do not install DSM, QTS, QuTS, or drive firmware. Ext4 replays its journal on a read-only mount. Btrfs replays its tree log on a read-only mount unless the mount also says nologreplay. A reboot is that remount, and it is also how a volume that still opened comes back crashed. The DSM update page is the degraded pool that is still writable. A read-only volume is a worse time to take the restart. Synology's own update path on the read-only article is the unsupported-feature case, not the drive-failure case. A firmware update does not copy a file to another disk.

Do not swap the disk, and do not pull the set apart. Replacing a member and repairing is a rebuild. On a RAID group that has already exceeded its tolerance, a replacement does not give the parity back. QTS documents Recover as a rebuild after disks are put back in the original bays, and it says that path does not help a failed disk. Label the bay before a drive comes out. A drive goes back only to the slot it left.

Do not Remove the volume, delete the pool, or create a new one on these disks. Synology's hardware steps end in Remove and a new volume, after the backup. QNAP's Not Active path is not a license to delete the pool and start clean. A new volume on the same members is a new filesystem over the one you can still read.

How to copy while it still reads

1. Send the files to a different device. A disk on another computer, or an external drive that is not a member of this NAS. Synology's article allows "another volume on the same Synology storage system." Another volume on the pool that just went read-only is the same set of disks. A USB disk plugged into the NAS still depends on that chassis. The copy that counts is the one that is not on these drives.
2. Most important first. The files that exist only here: the job folder, the photos, the mail, the database, whatever you cannot download again. A full-volume copy reads every allocated block. That is the right second pass when the first files copied cleanly and the disks are quiet. It is the wrong first pass when the log is already full of I/O errors.
3. Read, don't write. Copy off the NAS. Do not save, upload, edit, extract an archive, or take a snapshot on it. A snapshot is a write. Do not point a sync or a backup job at the NAS as the destination. Do not "fix" permissions on the way out if the client wants to write them back.
4. One quiet copy. Don't scrub, don't parity-check, and don't start a second full copy beside this one. If the NAS is slow or a disk is noisy, a smaller folder beats a heroic whole-volume read.
5. Skip a file that errors, and write the name down. Retrying the same file is the same failed read, again. Move on. The names you could not copy are the list a lab needs. When the copy finishes, open a few of the important files on the other disk before you trust it.

If the volume is encrypted — a Synology or QNAP encrypted shared folder, or a ZFS dataset with a key — the copy only works while it is unlocked. Leave it unlocked until the files are off. The key does not make a repair safe. If you have to power the NAS off, bring the key with the disks. We cannot brute-force that passphrase.

When to stop and call

Stop when the copy itself is the thing failing. I/O errors, files that will not open, a folder that hangs, a disk that drops out of the list, or a share that disconnects mid-copy. Power the NAS off if a disk is clicking. A clicking drive does not get better because the folder was important.

Stop when the status changes under you. Read-only that becomes Crashed, Not Active, Inactive, unmountable, unavailable, or a pool at SUSPENDED with failmode=wait is the window closing. Don't reboot to get the share back. Don't click Repair or Recover because the copy was interrupted.

Stop when several disks go at once. Four bays in the same minute are not four filesystems having the same thought. That is a shared path — the HBA, the backplane, the cable, the enclosure, or the power — and a copy through that path is how the next disk drops.

Photograph Storage Manager, Storage & Snapshots, or the pool status before you shut it down, if you can do that without accepting a repair. Keep the exact status words, the RAID type, and which bay is marked failed. Then leave it off.

How a lab handles it

We do not remount your volume read-write. We do not run the filesystem repair, the scrub, the balance, or the rebuild on the original disks. We do not zpool clear a suspended pool, zpool import -F, or import a QuTS hero pool on TrueNAS. We do not Remove the volume and create a new one to "see if the files were copied."

Each member is imaged write-blocked, including a disk the UI had already marked faulty. The filesystem is read from those images. A wrong guess costs a clone, not the original. Imaging uses the lab tools already named on this site, including the ACE Lab PC-3000 and DeepSpar Disk Imager. Those tools image the drives. They are not a second NAS.

The public case log does not have a job that arrived as a NAS volume still mounted read-only. We will not invent one. The published Synology job is DDR-2026-0003: a four-drive RAID 5, already offline, two members failed, nothing rebuilt in the NAS, each member imaged and the array reconstructed from the images. Use it for what "image first" looks like after the window has closed. Do not use it as a twin of a share that is still open tonight. We don't advertise a success rate.

If the button is Repair or Recover, start with the Synology or QNAP page. If the pool will not import, start with zpool import -F. If a disk has to be shipped, pack it like any other failed drive and keep the bay label on it. For the work itself, see RAID data recovery.