My ReadyNas 102 won't complete boot. Blinking power button
MacOS Sierra NAS RN102 Firmeware 6.9.1
Today, while in the midle of transfer from my NAS to a local drive, my NAS was not seen by my network and the transfer was cancelled. I tried to reconnect, which is when I realized the power button was blinking.
I tried to reboot as usual, which didn't work, so I unplugged the NAS. After several attempts, the light continues blinking. It appears in the network, but after a few minutes it becomes unresponsive again.
When it shows up on the network, I'm able to get its IP using RAIDar and I can reach the web admin, but I never even get passed the boot page. This doesn't allow me to update firmware or download logs.
RAIDar says "System is starting up...." for a few, and then goes back to saying it can't find a raid. When RAIDar does manage to see it, both drives have green check marks.
I'm attaching the mega screenshot with my network drive, RAIDar and the web admin all in one view.
Re: My ReadyNas 102 won't complete boot. Blinking power button
So this is strange.
I'm able to get to the admin page and view information on the drives, and even see the Volumnes and Shares in my NAS if I boot with one drive. Either one.
I'm assuming that I can't access any of the shares since the information is distribuited among two drives.
Re: My ReadyNas 102 won't complete boot. Blinking power button
Thanks @StephenB ! I had 2 4tb disks configured as one extended drive of 8tb with a bunch of shares.
I'm hoping the unit is the one failing, rather than disks (which is still a pretty big issue).
I found the last records of the two logs you mentioned.
System.log:
Dec 02 15:42:08 ndm_raid apache2[2260]: [error] [client 192.168.100.17] Connect rddclient failed, referer: https://169.254.116.184/admin/
Dec 02 15:44:07 ndm_raid apache_access[2195]: Suppressed 38 duplicate messages
Dec 02 15:44:08 ndm_raid apache_access[2195]: 192.168.100.17 "-" 408
Dec 02 15:46:13 ndm_raid connmand[2035]: eth0 {RX} 5994 packets 846843 bytes
Dec 02 15:46:13 ndm_raid connmand[2035]: eth0 {TX} 3314 packets 3045821 bytes
Dec 02 15:46:14 ndm_raid connmand[2035]: eth0 {update} flags 36867 <UP>
Dec 02 15:46:34 ndm_raid apache2[2200]: [error] [client 192.168.100.17] Connect rddclient failed, referer: https://169.254.116.184/admin/
Dec 02 15:46:35 ndm_raid connmand[2035]: eth0 {newlink} index 2 address 28:C6:8E:35:9A:16 mtu 1500
Dec 02 15:46:35 ndm_raid connmand[2035]: eth0 {newlink} index 2 operstate 2 <DOWN>
Dec 02 15:46:35 ndm_raid apache_access[2195]: Suppressed 4 duplicate messages
Dec 02 15:46:35 ndm_raid apache_access[2195]: 192.168.100.17 "POST /dbbroker HTTP/1.1" 200
Dec 02 15:46:37 ndm_raid avahi-daemon[2009]: Withdrawing address record for 169.254.116.184 on eth0.
Kernel.log:
Dec 02 11:59:23 ndm_raid kernel: [ 2468] 0 2468 11867 327 25 0 486 0 smbd
Dec 02 11:59:24 ndm_raid kernel: Out of memory: Kill process 2276 (apt-get) score 24 or sacrifice child
Dec 02 11:59:24 ndm_raid kernel: Killed process 2276 (apt-get) total-vm:35900kB, anon-rss:1612kB, file-rss:980kB
Is there any other way of accessing the contents of the drives? Most of the data was fortunately backed up on a sepearate archive drive... I'm just missing a couple of folders that I'm desperately trying to gain access to.
I had 2 4tb disks configured as one extended drive of 8tb with a bunch of shares.
Meaning you had set the unit up in flexraid using RAID-0? If that is correct, you shouldn't have tried to boot the system with one drive.
RAID-0 has no redundancy, and if either disk fails you do lose all your data. You always should have a backup of your data (since no RAID mode is enough to keep it safe). But it's particularly important if you run RAID-0.
Dec 02 15:42:08 ndm_raid apache2[2260]: [error] [client 192.168.100.17] Connect rddclient failed, referer: https://169.254.116.184/admin/
...
Dec 02 15:46:35 ndm_raid connmand[2035]: eth0 {newlink} index 2 operstate 2 <DOWN>
... Dec 02 15:46:37 ndm_raid avahi-daemon[2009]: Withdrawing address record for 169.254.116.184 on eth0.
Something bad is going on with your network access. One obvious thing is that the NAS is using an incompatible IP address. If your PC is using 192.168.100.x address, the NAS should be using a 192.168.100.x address also. But it's using 169.254.116.x.
How did you get the logs? Did you use RAIDar, or did you manage to log into the web admin page?
Do you know if the NAS is configured to use DHCP? Or did you configure a static address
Is there any evidence that the NAS was using a 192.168.100.x address before or after Dec 2?
Is there any other way of accessing the contents of the drives? Most of the data was fortunately backed up on a sepearate archive drive... I'm just missing a couple of folders that I'm desperately trying to gain access to.
I suggest powering down the NAS. Then test the drives in a Windows PC using vendor tools (Seatools for Seagate; Lifeguard for Western Digital). That will give you some confidence that the drives are ok. Label the drives by slot as you remove them. You can connect the drives either using SATA, or an inexpensive USB/SATA adapter or dock.
While the drives are removed, power up the NAS. Check that RAIDar gives you a "no disks" status, and that you have a valid IP address for your network.
If that works, you can then try using paid support (via my.netgear.com), and see if they can resolve the issue. They can access the system remotely if it is in tech support mode. Ask for per-incident support, don't get the gearhead support package (which doesn't cover what you need).
You could alternatively try connecting both disks to the PC, and use ReclaiMe RAID recovery software ( https://www.reclaime.com/ ) You can see if it can find files on your data volume by downloading before you purchase.
Note that if the disks are intact, you can purchase a new OS-6 NAS (for instance an RN212) and migrate your disks to it with the NAS powered down. However, migration will only work if the disks have no corruption (and of course are working). It's not clear that your disks do.
