[Help]F2-424: Btrfs volume keeps going read-only after failed repair, RAID1 healthy, data still present

[Falco]

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.

[EriChan]

Thank you for providing the detailed diagnostic logs. Based on the current state of your Btrfs file system, the metadata corruption has reached a critical level. To prevent permanent data loss, please follow these instructions immediately:

• Cease All Operations: Please stop the Docker Engine and all related services immediately. Do not attempt the btrfs check --repair command again, as forced repairs on unstable metadata can lead to total file system collapse.

• Prioritize Data Backup: Since the volume is currently accessible in read-only mode, this is your best opportunity to secure your files. Please immediately copy your critical data to an external storage device via SMB or TOS File Manager.

• Schedule Remote Support: As the standard recovery procedures have not resolved the issue, a deep-level diagnostic by our engineers is required. Please visit our official website and contact our online customer service to schedule a Remote Technical Support session.In addition,please provide the link to your community forum post and your username. This will help our engineers review the historical context and logs you have already shared.

Our technical team will assist you in diagnosing and resolving the underlying issue.