[Help]F2-424: Btrfs volume keeps going read-only after failed repair, RAID1 healthy, data still present
Posted: 31 Mar 2026, 01:15
Hello everyone,
I am posting here because TerraMaster support has not replied yet, and I would like to ask the community for advice before making the situation worse.
My NAS is a TerraMaster F2-424 with:
- 2 x Seagate IronWolf Pro 8TB
- RAID1
- Btrfs
Problem summary:
My data volume became read-only.
The RAID itself appears healthy, and the disks do not seem to show obvious hardware failure, but the Btrfs volume keeps falling back to read-only mode.
At the moment, my data is still present on the NAS, so I have not lost files yet.
However, the NAS is not stable, Docker is no longer usable, and my Nextcloud container is down.
What I checked:
mdadm --detail /dev/md0 shows the RAID1 array is clean and both disks are active.
btrfs device stats shows:
- write_io_errs = 0
- read_io_errs = 0
- flush_io_errs = 0
- corruption_errs = 1
- generation_errs = 0
Kernel logs repeatedly show Btrfs metadata errors followed by: - forced readonly
What I already did:
I followed the official TerraMaster guide: “How to repair a corrupted file system?”
Following that guide, I:
1) unmounted the Btrfs volume and related mount points
2) ran: btrfs check /dev/mapper/vg0-lv0
This reported extent/backref mismatches and fs root errors.
Then, following the next step in the guide, I ran: btrfs check --repair /dev/mapper/vg0-lv0
The repair started, deleted one damaged extent record, but then aborted with:
failed to repair damaged filesystem, aborting
After that, again following the guide, I ran: /etc/tos/scripts/mntdata
The volume mounted again in read-write mode temporarily, and for a short time /Volume1 was writable.
What happened next
As soon as I re-enabled Docker Engine / Docker Manager and resumed normal activity, the volume went back to read-only.
Now the logs show errors such as:
- extent item not found for insert
- failed to run delayed ref
- BTRFS: error ...
- forced readonly
Current situation:
- the volume still mounts
- but it becomes read-only again
- Docker is no longer usable
- Nextcloud is down because Docker does not work correctly
- I also cannot create new SMB folders or write normally once the volume returns to read-only
Important note:
There may have been a power outage before this started, but I am not completely sure whether that was the direct cause.
My questions:
At this point, since I already followed the official repair guide and the problem still returns:
1) Has anyone seen this kind of recurrent Btrfs forced readonly issue on an F2-424?
2) Does this sound like recoverable metadata corruption, or is it more likely that the safest solution is now to copy data out and rebuild the volume?
3) Is there any TerraMaster-specific recovery procedure beyond the official guide?
4) Since btrfs check --repair already failed, would it be safer to stop using the volume immediately and copy all data out first?
5) Would Reset system configuration or Factory Default help at all here, or is this clearly a Btrfs metadata problem inside the data volume?
6) Has anyone successfully recovered from this state without losing data?
My main goal is to restore stable write access and get Nextcloud working again, preferably without losing the existing data.
If needed, I can also post the full command outputs and kernel logs.
Thanks in advance.
I am posting here because TerraMaster support has not replied yet, and I would like to ask the community for advice before making the situation worse.
My NAS is a TerraMaster F2-424 with:
- 2 x Seagate IronWolf Pro 8TB
- RAID1
- Btrfs
Problem summary:
My data volume became read-only.
The RAID itself appears healthy, and the disks do not seem to show obvious hardware failure, but the Btrfs volume keeps falling back to read-only mode.
At the moment, my data is still present on the NAS, so I have not lost files yet.
However, the NAS is not stable, Docker is no longer usable, and my Nextcloud container is down.
What I checked:
mdadm --detail /dev/md0 shows the RAID1 array is clean and both disks are active.
btrfs device stats shows:
- write_io_errs = 0
- read_io_errs = 0
- flush_io_errs = 0
- corruption_errs = 1
- generation_errs = 0
Kernel logs repeatedly show Btrfs metadata errors followed by: - forced readonly
What I already did:
I followed the official TerraMaster guide: “How to repair a corrupted file system?”
Following that guide, I:
1) unmounted the Btrfs volume and related mount points
2) ran: btrfs check /dev/mapper/vg0-lv0
This reported extent/backref mismatches and fs root errors.
Then, following the next step in the guide, I ran: btrfs check --repair /dev/mapper/vg0-lv0
The repair started, deleted one damaged extent record, but then aborted with:
failed to repair damaged filesystem, aborting
After that, again following the guide, I ran: /etc/tos/scripts/mntdata
The volume mounted again in read-write mode temporarily, and for a short time /Volume1 was writable.
What happened next
As soon as I re-enabled Docker Engine / Docker Manager and resumed normal activity, the volume went back to read-only.
Now the logs show errors such as:
- extent item not found for insert
- failed to run delayed ref
- BTRFS: error ...
- forced readonly
Current situation:
- the volume still mounts
- but it becomes read-only again
- Docker is no longer usable
- Nextcloud is down because Docker does not work correctly
- I also cannot create new SMB folders or write normally once the volume returns to read-only
Important note:
There may have been a power outage before this started, but I am not completely sure whether that was the direct cause.
My questions:
At this point, since I already followed the official repair guide and the problem still returns:
1) Has anyone seen this kind of recurrent Btrfs forced readonly issue on an F2-424?
2) Does this sound like recoverable metadata corruption, or is it more likely that the safest solution is now to copy data out and rebuild the volume?
3) Is there any TerraMaster-specific recovery procedure beyond the official guide?
4) Since btrfs check --repair already failed, would it be safer to stop using the volume immediately and copy all data out first?
5) Would Reset system configuration or Factory Default help at all here, or is this clearly a Btrfs metadata problem inside the data volume?
6) Has anyone successfully recovered from this state without losing data?
My main goal is to restore stable write access and get Nextcloud working again, preferably without losing the existing data.
If needed, I can also post the full command outputs and kernel logs.
Thanks in advance.