NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
1002030001 - Commit Failed #27399265
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.
Any help or advise would be greatly appreciated.
Hi Eddie,
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.
14 Replies
- 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.
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?
You can run a disk check from the volume settings wheel. What disks are you using?
There's also a memory diagnostic that you can run from the boot menu. See pages 31-32 here: http://www.downloads.netgear.com/files/GDC/READYNAS-100/RN%20OS%206%20Desktop%20HW%20UM_15Oct2013.pdf There's a guide for understanding progress/results here: https://kb.netgear.com/25632/RN312-Memory-Test-Analysis
There's a disk check in the boot menu too, but I think you're better off using the on-line test.
I am thinking paid support (my.netgear.com) might be useful in finding the root cause.
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.Can you post the top of btrfs.log please?
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
