NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Can't go back to RW mode after system "protected" itself
Hi all, I've been struggling with this for a few weeks and can't use my NAS since this started. I was transferring some files to the NAS as a mounted "network drive" from my Macbook. I cancelled th...
I am seeing two things.
One is that sde and sdf (disks 5 and 6) are showing some errors in disk_info.log
Device: sde Health Data: Current Pending Sector Count: 3 Uncorrectable Sector Count: 3 Device: sdf Health Data: Current Pending Sector Count: 5 Uncorrectable Sector Count: 4Raid-5 can't handle two disk failures, so that might be part of the puzzle here. Though these counts are small, it might be good to power down, and connect these disks to a PC (sata or USB dock). Test them with WD's dashboard software - running the long (full) non-destructive test. Label the disks as you remove them, so you can put them back in the right slot. Keep the NAS powered down until you replace the disks.
The other error (which is what is driving the read-only status is here:
Apr 08 10:50:54 BananaS kernel: BTRFS error (device md127): bdev /dev/md127 errs: wr 1, rd 0, flush 0, corrupt 0, gen 0 Apr 08 10:50:54 BananaS kernel: BTRFS error (device md127): bdev /dev/md127 errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 Apr 08 10:50:58 BananaS kernel: BTRFS error (device md127): bdev /dev/md127 errs: wr 3, rd 0, flush 0, corrupt 0, gen 0 Apr 08 10:50:58 BananaS kernel: BTRFS error (device md127): bdev /dev/md127 errs: wr 4, rd 0, flush 0, corrupt 0, gen 0 Apr 08 10:50:58 BananaS kernel: BTRFS error (device md127): bdev /dev/md127 errs: wr 5, rd 0, flush 0, corrupt 0, gen 0 Apr 08 10:50:58 BananaS kernel: BTRFS error (device md127): bdev /dev/md127 errs: wr 6, rd 0, flush 0, corrupt 0, gen 0 Apr 08 10:50:58 BananaS kernel: BTRFS error (device md127): bdev /dev/md127 errs: wr 7, rd 0, flush 0, corrupt 0, gen 0 Apr 08 10:50:58 BananaS kernel: BTRFS error (device md127): bdev /dev/md127 errs: wr 8, rd 0, flush 0, corrupt 0, gen 0 Apr 08 10:50:58 BananaS kernel: BTRFS error (device md127): bdev /dev/md127 errs: wr 9, rd 0, flush 0, corrupt 0, gen 0 Apr 08 10:50:58 BananaS kernel: BTRFS error (device md127): bdev /dev/md127 errs: wr 10, rd 0, flush 0, corrupt 0, gen 0 Apr 08 10:50:58 BananaS kernel: BTRFS: error (device md127) in btrfs_commit_transaction:2249: errno=-5 IO failure (Error while writing out transaction) Apr 08 10:50:58 BananaS kernel: BTRFS info (device md127): forced readonlyOne thing that is odd is that I am not seeing any corresponding mdadm or raw disk errors in kernel.log - which normally we would see.
Not sure yet on what you might do with ssh, but I strongly recommend making a backup of any data you care about before attempting a repair. If it were my system, I'd start over with a fresh volume (factory default), because the repair might not fix everything.
dbrami wrote:
To "fix" any issues, i pulled out a drive and put it back in, knowing some file scanning happens. The system status shows "healthy" but i still can't write any data.
Very bad idea actually. You are lucky you didn't lose all your data.
dbrami wrote:
My research has led me to believe i need to unmount my subvolumes and remount as rw.
No. The mitigation needed depends on exactly what the file system error is - but unmounting/remounting the subvolume is never the answer.
The error you posted is saying that you couldn't roll back a snapshot. That of course will fail if the volume is already read-only, because the roll back requires write access to the volume. So we don't yet have the info needed to tell what is wrong. Possibly it is in the full log zip file, so I suggest downloading that right away. But that is also problematic, since the error happened on 8 April or before, so the needed detials might no longer be in the logs.
If you don't have a full backup of your data, then the first step is to do that. It is definitely at risk. If you don't have enough storage, then purchase external drives, or whatever you need. Back up what critical (irreplacable) data you can while waiting for the storage to arrive.
After you've ensured data safety, you have two basic options. One is to try to repair what is wrong. The other is to do a factory default, reconfigure the NAS, and restore data from backup. Although the second option can be a lot of work, in practice it is often quicker than trying to repair the problem (and success is more certain).
dbrami wrote:
Rolling back to snapshots doesn't work and Tech Support won't respond to me.
As I said above, rolling back to snapshots requires writing to the volume. The NAS isn't allowing that. The rationale is that any any writes to the volume is llikely to result in data loss.
Unfortunately many folks here are finding Netgear support to be non-responsive. My own opinion is that Netgear has been quiet-quiting their storage business for some years now, and that they no longer have trained support staff. Netgear hasn't announced anything - but the facts are that new ReadyNAS can't be found for purchase, and Netgear hasn't introduced a new ReadyNAS product since 2017.
Thanks for clear, categorical response!
BTW, it's a ReadyNAS 516 and I can't even find it on the product search when entering new topics.
I have no problem sharing the logs (I saved them on April 10th). This forum does not allow me to share zip files so here's URL:
<redacted>
If you think from looking at logs there's a simple command-line fix, that would be great.
If you don't, then it sounds like a need to buy 4TB of portable storage and copy my data over.
Netgear NAS == Never Again.
There is privacy leakage when you post logs publicly. They should be sent using the private message (PM) facility in the forum. I downloaded yours, and then redacted your URL.
dbrami wrote:
If you don't, then it sounds like a need to buy 4TB of portable storage and copy my data over.
FWIW, you should have a backup strategy in place anyway (with any NAS). RAID isn't enough to keep your data safe. In general, if you don't have a proper backup, then you will eventually lose data - it's just a matter of when.
I am seeing two things.
One is that sde and sdf (disks 5 and 6) are showing some errors in disk_info.log
Device: sde Health Data: Current Pending Sector Count: 3 Uncorrectable Sector Count: 3 Device: sdf Health Data: Current Pending Sector Count: 5 Uncorrectable Sector Count: 4Raid-5 can't handle two disk failures, so that might be part of the puzzle here. Though these counts are small, it might be good to power down, and connect these disks to a PC (sata or USB dock). Test them with WD's dashboard software - running the long (full) non-destructive test. Label the disks as you remove them, so you can put them back in the right slot. Keep the NAS powered down until you replace the disks.
The other error (which is what is driving the read-only status is here:
Apr 08 10:50:54 BananaS kernel: BTRFS error (device md127): bdev /dev/md127 errs: wr 1, rd 0, flush 0, corrupt 0, gen 0 Apr 08 10:50:54 BananaS kernel: BTRFS error (device md127): bdev /dev/md127 errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 Apr 08 10:50:58 BananaS kernel: BTRFS error (device md127): bdev /dev/md127 errs: wr 3, rd 0, flush 0, corrupt 0, gen 0 Apr 08 10:50:58 BananaS kernel: BTRFS error (device md127): bdev /dev/md127 errs: wr 4, rd 0, flush 0, corrupt 0, gen 0 Apr 08 10:50:58 BananaS kernel: BTRFS error (device md127): bdev /dev/md127 errs: wr 5, rd 0, flush 0, corrupt 0, gen 0 Apr 08 10:50:58 BananaS kernel: BTRFS error (device md127): bdev /dev/md127 errs: wr 6, rd 0, flush 0, corrupt 0, gen 0 Apr 08 10:50:58 BananaS kernel: BTRFS error (device md127): bdev /dev/md127 errs: wr 7, rd 0, flush 0, corrupt 0, gen 0 Apr 08 10:50:58 BananaS kernel: BTRFS error (device md127): bdev /dev/md127 errs: wr 8, rd 0, flush 0, corrupt 0, gen 0 Apr 08 10:50:58 BananaS kernel: BTRFS error (device md127): bdev /dev/md127 errs: wr 9, rd 0, flush 0, corrupt 0, gen 0 Apr 08 10:50:58 BananaS kernel: BTRFS error (device md127): bdev /dev/md127 errs: wr 10, rd 0, flush 0, corrupt 0, gen 0 Apr 08 10:50:58 BananaS kernel: BTRFS: error (device md127) in btrfs_commit_transaction:2249: errno=-5 IO failure (Error while writing out transaction) Apr 08 10:50:58 BananaS kernel: BTRFS info (device md127): forced readonlyOne thing that is odd is that I am not seeing any corresponding mdadm or raw disk errors in kernel.log - which normally we would see.
Not sure yet on what you might do with ssh, but I strongly recommend making a backup of any data you care about before attempting a repair. If it were my system, I'd start over with a fresh volume (factory default), because the repair might not fix everything.
Thank you Guru StephenB for taking care of me - both with logs security and with your time to go through these and share your thoughts. Maybe the universe return the good karma you put out.
Will follow the the two same suggestions: back up the data (on an external drive), do a factory reset, and if possible, test each drive separately.
Best,
Daniel
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
