Hello,
ive replace sda HDD and i've same problem.
i send your report generate with claude :
Incident Report — TerraMaster F5-221 / TOS 5.1.67
Summary
After replacing a failed disk and rebuilding the RAID5 array, the data volume /Volume1 remains stuck in read-only mode (forced readonly) on every boot, despite fully healthy hardware, RAID, LVM, and BTRFS metadata. The lockup is perfectly reproducible: it occurs systematically ~48 to 50 seconds after mount, with no visible triggering event in the logs.
Configuration
Model: TerraMaster F5-221
Firmware: TOS 5.1.67
Storage stack: RAID5 (mdadm, md0, 4 disks) → LVM (vg0/lv0) → BTRFS (/Volume1)
BTRFS mount options: nodatasum,nodatacow,nobarrier,space_cache=v2,autodefrag
Incident timeline
Disk failure (initially identified as sda via SMART: Reallocated_Sector_Ct=99, Current_Pending_Sector=69).
Disk replaced, RAID5 successfully rebuilt.
Since then, /Volume1 mounts read-only; all shared folders except /homes are inaccessible for writing.
Replaced sda with a new disk (WD30EFRX) + reboot → the problem persists identically, ruling out the disk as the sole cause.
Checks performed (all clean/healthy)
Check Result
Unix permissions / ACLs Correct (RW via interface, RWX via SSH)
SMART on all 4 disks (post-replacement) All clean, no anomalies
cat /proc/mdstat md0 healthy and fully synced [UUUU], no ongoing rebuild
pvs / vgs / lvs / dmsetup No anomalies, LV active, no read-only flag on the LVM side
btrfs check --readonly --force "no error found" — metadata structurally sound (only a stale free-space cache to rebuild, harmless)
fuser -m / ps (process holding the mount) No identifiable process
Key kernel log (reproducible on every boot, near-identical timing)
[ 71-75s] BTRFS info (device dm-0): using free space tree / has skinny extents
... no events logged for ~48s ...
[ 121-123s] BTRFS error (device dm-0): bdev /dev/mapper/vg0-lv0 errs: wr 1, rd 0, flush 0, corrupt 0, gen 0
[ 121-123s] BTRFS: error (device dm-0) in btrfs_commit_transaction
errno=-5 IO failure (Error while writing out transaction)
[ 121-123s] BTRFS info (device dm-0): forced readonly
[ 121-123s] BTRFS warning (device dm-0): Skipping commit of aborted transaction.
[ 121-123s] BTRFS: error (device dm-0) in cleanup_transaction
errno=-5 IO failure
Every subsequent attempt to remount read-write (hot remount, fresh umount/mount, lazy umount + clear_cache/nospace_cache options) fails with:
BTRFS error (device dm-0): Remounting read-write after error is not allowed
Current status
/Volume1 is mounted read-only and the data is accessible and not at risk (backup completed).
No hardware, RAID, LVM, or metadata corruption cause could be identified despite thorough SSH-level investigation.
The behavior points to an issue in TOS 5.1.67's mount orchestration for this volume (RAID5 + LVM + BTRFS sequencing at boot), rather than an actual hardware fault or real corruption.
Question for support
Is there an official TOS procedure to clear this "forced readonly" flag without risking the data (beyond the attempts already made above)?
Does this reproducible timing (~48s post-mount) match a known bug in the storage boot sequence for this TOS version?
Looking forward to reading you.
errno=-5 IO failure (Error while writing out transaction)
errno=-5 IO failure