Read-only storage recovery
A Synology volume that becomes read-only is signaling that DSM is limiting writes while data may still be accessible. That can be frustrating for applications, but from a recovery perspective it is often better than an unreadable crash because the remaining readable files may still be copied to another destination. The mistake is trying to force the volume writable before understanding whether drive errors, filesystem problems or a broader storage fault triggered the protection.
Quick answer
Use the read window to evacuate valuable data
If important folders remain readable, copy them to independent storage and verify the copies before experimenting with repairs. Pause services that continually write databases, thumbnails or logs because they will fail anyway and may complicate diagnosis.
Current Amazon listings
Replacement and migration DiskStation options
Product cards are supporting purchase references only; they do not determine whether your failed drives are recoverable or whether a specific migration pairing is supported.
Technical decision
Read-only is a preservation state, not proof the disks are healthy
Treat the mode as evidence that normal write operations are unsafe. Determine whether Storage Manager also reports degraded, crashed, critical, bad-sector or I/O conditions, then choose a recovery path based on the exact combination instead of simply remounting writable.
Interactive recovery tool
Synology Failure Triage Tool
This tool routes the symptoms you select to a safer next step. It does not issue destructive commands. Before initializing a disk, deleting a pool, reinstalling DSM or moving the only copy of important data, verify the exact live Synology procedure for your model and DSM build.
Recovery safety checklist
Four rules before you change a failing Synology system
Preserve readable data first
If unique files can still be opened, copy or back them up before changing storage metadata, reinstalling DSM or running stressful diagnostics.
Record drives and bays
Capture drive serial numbers, bay positions, health states and DSM messages before swapping disks or moving them to another chassis.
Match the action to the failure layer
A degraded pool, crashed volume, failed system partition, bad drive and failed bay have different supported recovery paths.
Keep a rollback path
During migration or recovery, do not erase the source system until the destination data, permissions, applications and backups have been verified.
Read-only can be safer than forced write access
When DSM limits a damaged volume to reads, the restriction can preserve what remains accessible. The immediate objective is to move important files elsewhere, not to defeat the protection. A writable mount is useful only after the underlying condition has been understood and addressed.
In a read-only-volume case, read-only can be safer than forced write access is valuable because DSM may be preserving access while refusing unsafe writes. Use that temporary stability to inventory readable shares, pause write-dependent services, and move unique files to storage outside the affected pool. Do not treat an application failure as proof that every file is gone; test ordinary data separately. Before converting this section into a repair action, verify the copied destination and confirm what underlying drive or filesystem warning caused DSM to stop accepting changes.
Application failures are expected in this state
Packages that depend on databases, logs or temporary files may stop even while ordinary documents remain readable. That difference can make the NAS look more broken than the actual data path is. Test representative user files separately from application health.
In a read-only-volume case, application failures are expected in this state is valuable because DSM may be preserving access while refusing unsafe writes. Use that temporary stability to inventory readable shares, pause write-dependent services, and move unique files to storage outside the affected pool. Do not treat an application failure as proof that every file is gone; test ordinary data separately. Before converting this section into a repair action, verify the copied destination and confirm what underlying drive or filesystem warning caused DSM to stop accepting changes.
Copy small irreplaceable data before huge archives
Prioritize family photos, business documents, encryption keys, configuration exports and active project files before large replaceable media libraries. A failing drive can worsen during a multi-terabyte copy, so recovery order should reflect value rather than directory size.
In a read-only-volume case, copy small irreplaceable data before huge archives is valuable because DSM may be preserving access while refusing unsafe writes. Use that temporary stability to inventory readable shares, pause write-dependent services, and move unique files to storage outside the affected pool. Do not treat an application failure as proof that every file is gone; test ordinary data separately. Before converting this section into a repair action, verify the copied destination and confirm what underlying drive or filesystem warning caused DSM to stop accepting changes.
Check Storage Manager for the companion status
Read-only mode rarely exists in isolation. Look for degraded pools, crashed volumes, failed drives, bad sectors, I/O errors or system-partition warnings. The companion status usually provides the more useful explanation for why DSM stopped trusting writes.
In a read-only-volume case, check storage manager for the companion status is valuable because DSM may be preserving access while refusing unsafe writes. Use that temporary stability to inventory readable shares, pause write-dependent services, and move unique files to storage outside the affected pool. Do not treat an application failure as proof that every file is gone; test ordinary data separately. Before converting this section into a repair action, verify the copied destination and confirm what underlying drive or filesystem warning caused DSM to stop accepting changes.
Do not run repair commands from random forum posts
Filesystem tools can modify metadata aggressively. A command appropriate for a clean unmounted Linux volume may be unsafe on an SHR or Btrfs layout managed by DSM. Preserve data and use Synology-supported procedures unless you are intentionally doing expert forensic recovery on copies.
In a read-only-volume case, do not run repair commands from random forum posts is valuable because DSM may be preserving access while refusing unsafe writes. Use that temporary stability to inventory readable shares, pause write-dependent services, and move unique files to storage outside the affected pool. Do not treat an application failure as proof that every file is gone; test ordinary data separately. Before converting this section into a repair action, verify the copied destination and confirm what underlying drive or filesystem warning caused DSM to stop accepting changes.
Snapshots are not a substitute for an external copy
A snapshot stored on the same failing pool depends on the same physical media and filesystem. It can help with logical rollback, but a read-only or damaged volume should push you toward an independent backup target that does not share the fault domain.
In a read-only-volume case, snapshots are not a substitute for an external copy is valuable because DSM may be preserving access while refusing unsafe writes. Use that temporary stability to inventory readable shares, pause write-dependent services, and move unique files to storage outside the affected pool. Do not treat an application failure as proof that every file is gone; test ordinary data separately. Before converting this section into a repair action, verify the copied destination and confirm what underlying drive or filesystem warning caused DSM to stop accepting changes.
Watch for disks that disappear and reconnect
Intermittent SATA contact, a failing drive or a bad slot can produce I/O errors before a permanent disappearance. Review Drive logs in Log Center, note whether one bay dominates the errors and use a controlled drive-versus-slot diagnostic only after data is protected.
In a read-only-volume case, watch for disks that disappear and reconnect is valuable because DSM may be preserving access while refusing unsafe writes. Use that temporary stability to inventory readable shares, pause write-dependent services, and move unique files to storage outside the affected pool. Do not treat an application failure as proof that every file is gone; test ordinary data separately. Before converting this section into a repair action, verify the copied destination and confirm what underlying drive or filesystem warning caused DSM to stop accepting changes.
Encryption keys must be included in the evacuation
If encrypted shared folders or encrypted volumes are involved, confirm that the keys or recovery material exist outside the NAS. A copied ciphertext dataset without the required key can still be unusable after the damaged system is rebuilt.
In a read-only-volume case, encryption keys must be included in the evacuation is valuable because DSM may be preserving access while refusing unsafe writes. Use that temporary stability to inventory readable shares, pause write-dependent services, and move unique files to storage outside the affected pool. Do not treat an application failure as proof that every file is gone; test ordinary data separately. Before converting this section into a repair action, verify the copied destination and confirm what underlying drive or filesystem warning caused DSM to stop accepting changes.
A rebuild should start on known-good media
If the underlying issue is filesystem corruption or failed storage, recreate the volume only after deciding which disks are trustworthy. Rebuilding onto suspect drives can turn a recoverable event into another failure before the restored data has a stable home.
In a read-only-volume case, a rebuild should start on known-good media is valuable because DSM may be preserving access while refusing unsafe writes. Use that temporary stability to inventory readable shares, pause write-dependent services, and move unique files to storage outside the affected pool. Do not treat an application failure as proof that every file is gone; test ordinary data separately. Before converting this section into a repair action, verify the copied destination and confirm what underlying drive or filesystem warning caused DSM to stop accepting changes.
Measure the copied data instead of assuming success
After evacuation, open representative files, compare counts, verify archives and, where possible, compare checksums. A copy process can finish while silently skipping corrupt files or permissions. Recovery is complete only when the destination data is actually usable.
In a read-only-volume case, measure the copied data instead of assuming success is valuable because DSM may be preserving access while refusing unsafe writes. Use that temporary stability to inventory readable shares, pause write-dependent services, and move unique files to storage outside the affected pool. Do not treat an application failure as proof that every file is gone; test ordinary data separately. Before converting this section into a repair action, verify the copied destination and confirm what underlying drive or filesystem warning caused DSM to stop accepting changes.
A read-only event can justify a migration
Older hardware with repeated I/O symptoms may be better retired than repaired repeatedly. Once the data is safe, compare the cost of new drives and diagnostic downtime with moving to a current DiskStation and restoring clean data.
In a read-only-volume case, a read-only event can justify a migration is valuable because DSM may be preserving access while refusing unsafe writes. Use that temporary stability to inventory readable shares, pause write-dependent services, and move unique files to storage outside the affected pool. Do not treat an application failure as proof that every file is gone; test ordinary data separately. Before converting this section into a repair action, verify the copied destination and confirm what underlying drive or filesystem warning caused DSM to stop accepting changes.
Escalation is cheaper than data loss
When the volume contains the only copy of important information, the cost of professional help can be lower than the value of the data. Stop before any action that formats, initializes, recreates or writes heavily to the original disks.
In a read-only-volume case, escalation is cheaper than data loss is valuable because DSM may be preserving access while refusing unsafe writes. Use that temporary stability to inventory readable shares, pause write-dependent services, and move unique files to storage outside the affected pool. Do not treat an application failure as proof that every file is gone; test ordinary data separately. Before converting this section into a repair action, verify the copied destination and confirm what underlying drive or filesystem warning caused DSM to stop accepting changes.
Questions people ask
Synology Volume Read-Only questions
Why did my Synology volume become read-only?
DSM may restrict writes when it detects storage or filesystem conditions that make normal writes unsafe. Check the exact Storage Manager and drive status for the real cause.
For read-only storage, the safest answer usually begins with copying accessible data and identifying the companion Storage Manager warning before forcing writes.
Can I still copy files from a read-only volume?
If files remain readable, yes. Copy important data to independent storage and verify it before attempting destructive changes.
Should I try to remount the volume read-write?
Not as a first response. Forcing writes can worsen a damaged filesystem or unstable storage condition.
Will Hyper Backup work from a read-only volume?
It may not work normally because packages need writable working state. A direct file copy to another machine can be more dependable during emergency evacuation.
Do snapshots protect me here?
Snapshots on the same pool share the same physical failure domain. Use an independent copy for recovery.
Can a single bad drive cause read-only behavior?
Drive errors can contribute, but the exact cause may also involve the filesystem or controller path. Use Storage Manager and logs to identify the companion fault.
Should I replace the drive immediately?
Protect readable data first when possible, then replace confirmed bad media according to the RAID/SHR and Synology repair procedure.
How do I know if copied files are good?
Open representative files, compare directory counts and use checksums where practical. Do not assume a completed copy means every source file was readable.
What about encrypted data?
Preserve recovery keys and passwords outside the NAS before rebuilding. Recovery without the key may be impossible even if the encrypted files copy correctly.
When should I rebuild the volume?
After the required data is safely copied or a recovery plan is accepted, and after you have identified known-good drives for the new storage pool.
Official references and methodology
Verify the live DSM state before any destructive recovery step
This read-only guide treats write protection as a diagnostic state rather than a reason to force remounts or recreate storage immediately. The workflow prioritizes copying files that still open, documenting the filesystem and drive-health evidence, and identifying why DSM restricted writes. Recovery choices should be verified against the exact DSM build and storage configuration before changing the affected volume.
- Synology: What can I do if one of my volumes crashed?
- Synology: Repair a storage pool
- Synology: Determine whether errors come from the drive or slot
As an Amazon Associate, Cloudzat may earn from qualifying purchases. Failure states, DSM behavior, migration compatibility and recovery options can change by model and DSM build. Preserve readable data and verify Synology's current Knowledge Center instructions before initializing drives, deleting pools, reinstalling DSM or changing the only copy of important data.