This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
ReadyNas 312. Current Firmware (6.7.4). For the second time in under a month, this ReadyNAS has become 'Read Only'. The first time was after a firmware upgrade and I was also setting up access rights for ReadyNas Remote and so I thought I'd caused the issue. This time is after a power fail and restart of the NAS drive.
I've checked the logs and there's no report of disk errors or problems. However, the share is read-only (when accessed from user PCs) and when I try and change any of the security setttings via the Admin page I get the error: 100203001 Commit Failed. I can't create a new share (same error) or create or rename folders in this share (no error via Admin page / disk full error via PC).
I have tried to run the backup manually (there's an overnight backup to USB as well as a continuous backup to ReadyVault) but the backup to USB job status remains as 'In Queue'.
I have the data secure and I know I can restore to factory settings, set it up again and copy all the data back as that's what I did last time. However I need to know it's not going to happen again.I'm guessing there could be some underlying hardware issue (disk error?) but there's nothing I can see in the logs.
Is there any way of running a check or test?Currently all users can access the files they need and are saving changes to their local PCs and will copy back once the NAS is working again, and it's Friday, so I have a day or two to resolve this.
The long way, I'm afraid. I had an USB backup from the night before. The files on the NAS were read-only so I could still access them over the network so I ran a robocopy on a connected PC and secured any files that had changed since the last backup by copying them to the local PC over the network (I just copied any files that had changed in the last two days to be safe).
I made sure I could read the data from the USB drive by connecting it to a PC and copying all the file over. Fortunately, in my case, there was only around 50gb of data so it was manageable. This step wasn't really needed but I was being ultra-cautious.
Once I was 100% certain I had all the data and could recover it, I performed a factory reset on the NAS drive and set it up again. Once I'd got it working, I re-connected the USB drive to it and used the admin interface to copy the contents of the USB drive back to the share. Once that was done, I then copied the 'recently changed' files back to the NAS.
Nothing techincal or clever so not really a practical solution to this problem, I'm afraid.
If the whole volume is read only, it could be that it's mounted read only. Have you tried rebooting the NAS?
It could also be that the BTRFS volume is corrupted after the power loss. If you download the logs from the GUI and check dmesg.log and systemd-journal.log for BTRFS messages. btrfs.log also contains valuable info.
Thanks, I didn't realise there was so much more information in the logs when downloaded. Problem is now understanding them. There are messages but not sure if it's an error. For example, this:
Jun 23 08:55:33 KNAPMAN-NAS kernel: ------------[ cut here ]------------
Jun 23 08:55:33 KNAPMAN-NAS kernel: WARNING: CPU: 2 PID: 4147 at fs/btrfs/qgroup.c:2967 btrfs_qgroup_free_meta+0x92/0xa0()
Jun 23 08:55:33 KNAPMAN-NAS kernel: Modules linked in: ufsd(PO) jnl(O) vpd(PO)
Jun 23 08:55:33 KNAPMAN-NAS kernel: CPU: 2 PID: 4147 Comm: smbd Tainted: P W O 4.4.68.x86_64.1 #1
Jun 23 08:55:33 KNAPMAN-NAS kernel: Hardware name: NETGEAR ReadyNAS 312/ReadyNAS 312 , BIOS 4.6.5 01/07/2013
Jun 23 08:55:33 KNAPMAN-NAS kernel: 0000000000000000 ffff880077f9bd50 ffffffff883d3e98 0000000000000000
Jun 23 08:55:33 KNAPMAN-NAS kernel: ffffffff88cf2bad ffff880077f9bd88 ffffffff8806b27c ffff88007827e000
Jun 23 08:55:33 KNAPMAN-NAS kernel: 0000000000000050 ffff88007827e000 ffffffffffffffe4 ffff8800390250e8
Jun 23 08:55:33 KNAPMAN-NAS kernel: Call Trace:
Jun 23 08:55:33 KNAPMAN-NAS kernel: [<ffffffff883d3e98>] dump_stack+0x4d/0x65
Jun 23 08:55:33 KNAPMAN-NAS kernel: [<ffffffff8806b27c>] warn_slowpath_common+0x7c/0xb0
Jun 23 08:55:33 KNAPMAN-NAS kernel: [<ffffffff8806b365>] warn_slowpath_null+0x15/0x20
Jun 23 08:55:33 KNAPMAN-NAS kernel: [<ffffffff88359fd2>] btrfs_qgroup_free_meta+0x92/0xa0
Jun 23 08:55:33 KNAPMAN-NAS kernel: [<ffffffff882eef92>] start_transaction+0x3f2/0x440
Jun 23 08:55:33 KNAPMAN-NAS kernel: [<ffffffff881444d4>] ? generic_permission+0x164/0x190
Jun 23 08:55:33 KNAPMAN-NAS kernel: [<ffffffff882ef446>] btrfs_start_transaction_fallback_global_rsv+0x26/0xc0
Jun 23 08:55:33 KNAPMAN-NAS kernel: [<ffffffff882f8890>] btrfs_unlink+0x30/0xb0
Jun 23 08:55:33 KNAPMAN-NAS kernel: [<ffffffff88144834>] vfs_unlink+0x104/0x180
Jun 23 08:55:33 KNAPMAN-NAS kernel: [<ffffffff881493ed>] do_unlinkat+0x23d/0x290
Jun 23 08:55:33 KNAPMAN-NAS kernel: [<ffffffff88149b01>] SyS_unlink+0x11/0x20
Jun 23 08:55:33 KNAPMAN-NAS kernel: [<ffffffff88a50617>] entry_SYSCALL_64_fastpath+0x12/0x6a
Jun 23 08:55:33 KNAPMAN-NAS kernel: ---[ end trace cea84c9661a966aa ]---
That says smbd Tainted, which I guess means an issue with the share access. Is that right?
Thanks - I didn't realise that option was there. I've set a scrub running, still waiting for results (30 mins in and <8% complete so will need to check back later).
Can't remember disk models as I'm not on site so no physical access to the NAS, but the model numbers are ST2000VN0001-1SF174 if that helps.
Same issue here (same error CommitFailed Code : 1002030001 after upgrade to 6.7.4). Only I can't even get logs (click on button opens new page, but then it times out after several minutes). I have another RN104 unit that is not upgraded and runs OK (logs are collected normally). I can't even turn on SSH on this faulty unit after upgrade so can't access via SSH. Reset does not help either. Please help.
Model: RN10400|ReadyNAS 100 Series 4-Bay (Diskless)
Label: '5e27460a:data' uuid: 3efd78ce-168b-44fb-bb95-19dc29dc7836
Total devices 1 FS bytes used 48.17GiB
devid 1 size 1.81TiB used 51.02GiB path /dev/md127
Metadata, DUP: total=1.50GiB, used=825.97MiB
While the metadata allocation isn't very high (I've seen volumes with 500GiB of metadata and more), the ratio metadata / data is surprisingly high. In comparison, on my 1.81TiB backup volume containing 1.20TiB of data, the metadata allocation is 368.75MiB.
Do you have bit rot enabled? Do you really need all these snapshots? Is the data hugely fragmented? An enormous number of small files? What's the write pattern?
At 50GB, I think it would be just as easy to Factory Default, reconfigure and reimport the data.
Thanks for your help looking into this. I have already done as you suggested and rebuilt the NAS and restored the data as it needed to be up and working again by start of this week. As it was the second time in recent weeks this had happened I wanted to be sure there was no underlying hardware fault.
The long way, I'm afraid. I had an USB backup from the night before. The files on the NAS were read-only so I could still access them over the network so I ran a robocopy on a connected PC and secured any files that had changed since the last backup by copying them to the local PC over the network (I just copied any files that had changed in the last two days to be safe).
I made sure I could read the data from the USB drive by connecting it to a PC and copying all the file over. Fortunately, in my case, there was only around 50gb of data so it was manageable. This step wasn't really needed but I was being ultra-cautious.
Once I was 100% certain I had all the data and could recover it, I performed a factory reset on the NAS drive and set it up again. Once I'd got it working, I re-connected the USB drive to it and used the admin interface to copy the contents of the USB drive back to the share. Once that was done, I then copied the 'recently changed' files back to the NAS.
Nothing techincal or clever so not really a practical solution to this problem, I'm afraid.
Thank you for the answer. I was afraid it would require evacuation of all data and clean start. In my case we are talking terabytes of data, so it will not be so easy.
And one more thing. I have a message for person who put your last reply as "solution" to this issue. I'm technical support engineer myself, and if I was "RESOLVING" my cases like this, I would be out of job in no time. So dear Netgear community, no this issue is not resolved. Upgrade to your firmware 6.7.4 obviously can make device unusable and causes business interruption. While I understand lack of motivation for further troubleshooting, I cannot but take this "resolution" as an insult.
Hi Eddie, I agree. I don't see that as a solution to the error just a pretty time consuming work-around. I also suspect it was the firmware so not going to upgrade any of the other drives I support until the next release just in case.
Seeing similar symptoms doesn't mean the root cause is the same. You should create your own thread and I'll have a look at your logs from there. If you wish to talk to NETGEAR Support, you should contact NETGEAR Support. Most people here don't work for them, we come here in our own time, because we want to help people.
