i've tried replacing 3 of the 6 disks, only 1 of which had shown any errors in the "ATA error" item when you hover the mouse over it in the web interface. Its getting to expensive to just replace disks for the "heck of it".
If I copy all the data off, what do I do to resolve this?
Its getting to expensive to just replace disks for the "heck of it".
Read-only is usually triggered by a problem with the BTRFS file system, not the disk drives.
You could try downloading the full log zip file from the NAS, and looking in there for details. There is a lot of info there, I could help you analyze it if you like. (Don't post a link to the logs publicly, as there is some information leakage when you do that).
If I copy all the data off, what do I do to resolve this?
Do a factory default (either from the boot menu or system->settings->update in the admin web ui). Then reconfigure the NAS (recreating shares, etc) and copy the data back.
What you have been doing is may create more issues, it won't solve the problem. The volume has gone read-only to prevent you from doing further damage before you back up the files, so take the hint.
You should be able to save the configuration and restore it again later rather than completely re-configure manually. Note that you do need to use the same volume name for that to work. You likely can also just destroy and re-create the data volume.
If your NAS set-up is pretty standard without a lot of users, it won't matter much. Note that you will need to restore apps in either case, which now takes extra effort.
10+ yrs ago I spent time in the u*ix/l*ix space but dont know brfs at all. I did download the logs & in dmesg.log I see:
NTFSJ support included Hfs+J support included Build_for__Netgear_RN314_x86_64_k4.1.16_2016-04-19_lke_9.6.4_b635 [Wed Sep 11 17:18:28 2024] ufsd: PAGE_SIZE=4K, THREAD_SIZE=16k [Wed Sep 11 17:18:28 2024] ufsd: Can't open /proc/config.gz [Wed Sep 11 17:18:28 2024] ufsd: Kernel .config hash: original unknown, current can't check. [Wed Sep 11 17:18:28 2024] ufsd: Kernel .config hash: original unknown, current can't check [Wed Sep 11 17:18:31 2024] ufsd: "mount" (sdh2): is mounted as NTFS(rw) at 2024-09-11 07:18:31 [Wed Sep 11 17:18:32 2024] nfsd: last server has exited, flushing export cache [Wed Sep 11 17:18:32 2024] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory [Wed Sep 11 17:18:32 2024] NFSD: starting 90-second grace period (net ffffffff88d782c0) [Wed Sep 11 17:18:37 2024] nfsd: last server has exited, flushing export cache [Wed Sep 11 17:18:37 2024] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory [Wed Sep 11 17:18:37 2024] NFSD: starting 90-second grace period (net ffffffff88d782c0) [Wed Sep 11 17:30:57 2024] BTRFS error (device md127): bdev /dev/md127 errs: wr 1, rd 0, flush 0, corrupt 0, gen 0 [Wed Sep 11 17:30:57 2024] BTRFS error (device md127): bdev /dev/md127 errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 [Wed Sep 11 17:30:57 2024] BTRFS error (device md127): bdev /dev/md127 errs: wr 3, rd 0, flush 0, corrupt 0, gen 0 [Wed Sep 11 17:30:57 2024] BTRFS error (device md127): bdev /dev/md127 errs: wr 4, rd 0, flush 0, corrupt 0, gen 0 [Wed Sep 11 17:30:57 2024] BTRFS error (device md127): bdev /dev/md127 errs: wr 5, rd 0, flush 0, corrupt 0, gen 0 [Wed Sep 11 17:30:57 2024] BTRFS: error (device md127) in btrfs_commit_transaction:2249: errno=-5 IO failure (Error while writing out transaction) [Wed Sep 11 17:30:57 2024] BTRFS info (device md127): forced readonly [Wed Sep 11 17:30:57 2024] BTRFS warning (device md127): Skipping commit of aborted transaction. [Wed Sep 11 17:30:57 2024] BTRFS: error (device md127) in cleanup_transaction:1864: errno=-5 IO failure [Wed Sep 11 17:30:57 2024] BTRFS info (device md127): delayed_refs has NO entry [Thu Sep 12 08:55:14 2024] md: md127: recovery done. [Thu Sep 12 08:55:17 2024] RAID conf printout: [Thu Sep 12 08:55:17 2024] --- level:5 rd:6 wd:6 [Thu Sep 12 08:55:17 2024] disk 0, o:1, dev:sda3 [Thu Sep 12 08:55:17 2024] disk 1, o:1, dev:sdb3 [Thu Sep 12 08:55:17 2024] disk 2, o:1, dev:sdc3 [Thu Sep 12 08:55:17 2024] disk 3, o:1, dev:sdd3 [Thu Sep 12 08:55:17 2024] disk 4, o:1, dev:sde3 [Thu Sep 12 08:55:17 2024] disk 5, o:1, dev:sdf3 [Thu Sep 12 09:36:30 2024] BTRFS error (device md127): Remounting read-write after error is not allowed [Thu Sep 12 09:36:53 2024] BTRFS error (device md127): Remounting read-write after error is not allowed [Thu Sep 12 10:16:39 2024] BTRFS error (device md127): Remounting read-write after error is not allowed [Thu Sep 12 17:36:38 2024] BTRFS error (device md127): Remounting read-write after error is not allowed
Trusting the RAID5 too much, I did think replacing the erroring disk (4 ATA erros, but not enough for the RN316 to change it to status RED) would help, but clearly not.
The answer is right there in the log you posted: Remounting read-write after error is not allowed.
I had an EDA500 that went read-only due to an error caused by a loose eSATA cable. So, the cause of the error had been corrected by securing the connection. Even though I had a full backup, I ran some experiments to see if I could recover to read/write mode. The result was: no, it can't be done. A couple things seemed to work, then it went re-only again quite quickly.
Here is something many don't realize about RAID. RAID is at as lower level than the file system. So if a file system error occurs, it's often duplicated in the RAID. That's just one reason RAID is not "backup".
Since you do not know what caused this error, you need to back up the files before something more happens and you loose access to the volume. Note that there is a good chance some of the files are corrupt.
Thanks for that very informative post! I read in another ticket 1 user said the SATA connector in 1 bay was faulty & caused this. Mine is a pure NAS so no eSATA cables involved.
I think i'll bit the bullet & destroy it & re-build once the last of the copy-off completes in the next day or 2.
Definitely yes, I have been backing up all this time. A very slow process. Had to go buy more gear to do that!
As soon as its complete I'll destroy the current config & start again.
That is the best path.
Before you destroy the volume (but AFTER the backup), I suggest running the disk test from the volume settings wheel. That will do a full non-destructive test of all the drives - which will take a while. You'll see the completion on the logs page.
