FW 6.6.0 was running so smoothly on my RN204. FW 6.6.1 **bleep**ed up the Anit-Virus Protection and now I read that 6.7.0 is bricking the whole NAS. This is a huge **bleep** up which should be fixed immediately!!!
My Admin Page still says that 6.6.1 is the actual firmware, has NetGear withdrawn 6.7.0?
6.7.0 isn't bricking the whole NAS for us. We need to have a look at systems running into issues preferably without an attempt to downgrade that complicates troubleshooting.
6.7.0 was released last week. It hasn't been posted on the update page yet.
Well norcis then send in the logs downloaded using normal mode. Where in the boot menu process are you getting stuck?
Have you got my logs (pm)? Also we occasionally expierence samba problems (https://community.netgear.com/t5/Using-your-ReadyNAS/Samba-hangs/m-p/1216233) and haven't found solution yet. Maybe OS reinstall fixed it too (could say in few days). Haven't tried but was thinking about factory reset, but it would take time to backup/restore all data. Maybe you will see from logs what could cause it too.
This problem is really frustrating and sorry when I say that, this dialog is too... Do I have to mention that I use this device for important data, not as a toy?
As I mentionend before, there are no errors in the logs. The attempt to download the logs via the web-interface ends in freezing the system. It's remarkable that many items in the log are about deleting snapshots from the past days (especially for one share). But when it freezes after a few minutes (I turn it off than), where are so many snapshots from. In the changelog there is a new feature making hourly snapshots when spindown is activated. Is it possible that this feature turns wrong in RN102? Unfortunately I cannot deactivate spindown or snapshots, because system crashes.
Can't do OS reinstall as steps described in manual does not work. 1) holding reset button when starting NAS makes red, two blue led blinking, and green stready on. At this stage I press reset button, but leds doesn't change.
The boot menu on the RN2120 can be a little bit confusing.
If you hold the reset button too long at the beginning, it "blocks" the boot menu and you can't scroll through the options. Instead, you should release the button immediately when you see the pattern, then you'll be able to scroll through the options.
If necessary, I can find you some videos showing the behavior.
@mdgm-ntgr In my case, an upgrade from 6.6.1 to 6.7.0 resulted in the RN104 running for a while, steadily getting more and more bogged down (noticable in SSH session, with Admin Page becoming unavailable, and RAIDar no longer able to connect, etc.), until the SSH connections hang altogether and the system eventually seems to crash with this:
bfq_lookup_next_entity+dc
on the LCD display. I don't think it's gone more than an hour, and has been as quickly as ~15min., before things grind to a halt. Have had to power-cycle a few times, as clean shutdown/reboot (by cmd line or power button) seems impossible by the time things really bog down.
While the system is churning, CPU seems to be split between kswapd0 (~40+%) and high I/O wait time. Here is the last 'top' screen from one of the SSH sessions before it hung:
Reinstalled OS by using Boot menu. Seems that fixed it. If you need logs for further investigation, I have it.
Your system was OOMing and you have a huge amount of snapshots. Clearly the disabling of quotas on the OS Re-install on 6.7.0 did the trick. Note if you change share settings quotas will be re-enabled in the volume (we've got a fix for this for the next release 6.7.1).
SMB was one of the services that was being killed as a result of entering the OOM (Out of Memory) condition so this may well be the explanation for why that service has been crashing for you too.
When the system runs Out of Memory (RAM) it has to forcibly shut off services to try to free up memory. If this doesn't quickly resolve the problem and it has to keep on shutting down services the system will crash.
I'd try an OS Re-install as well as this will disable quotas on the volume. As I mentoned in my post above this change won't survive share settings changes. So best to minimise share settings changes till you've updated to the next firmware 6.7.1 (once that's available).
Once the system is up in normal mode you could delete some snapshots and reduce the frequency of them and the number kept and this may alleviate the issue somewhat even if quotas get enabled again.
msnasx you could check the logs zip to see if there are e.g. large backup job logs or something and perhaps split the logs into two separate zip files or let us know which log files you've left out in case we need them.
@mdgm-ntgr thanks very much for looking at the logs. I did try the OS Re-install, and that did seem to take care of the churning and out-of-memory issues, for now (until quotas get enabled again, presumably).
I am curious at your description of "a huge amount of snapshots". I have snapshots enabled on only 4 of 8 shared folders, and they are all set to Daily and are under Smart Snapshot Management. I wouldn't have thought that to be unreasonable, especially enough to cause such serious system problems.
I have searched very hard in the KB and forums for any guidance on best practices for snapshots, and how much is "normal" as opposed to "huge", but have not had any success. Can you make any suggestions on this, or point me in the right direction?
msnasx you could check the logs zip to see if there are e.g. large backup job logs or something and perhaps split the logs into two separate zip files or let us know which log files you've left out in case we need them.
I have sent logs splitted in 2 emails. I don't have backup jobs. I still haven't rebooted my NAS but from time to time with is again not accessible and again after some time it comes back to normal. Definitely something isn't correct in this FW version. I'm looking forward to your feedback.
Is the issue related to the number of snapshots, or the size (individually or in total), or both?
Just trying to wrap my head around this, since it seems that volume quotas are enabled by default (since, as you mentioned, quotas will get enabled again with a change to share settings) even if there are no share-level quotas set, and that the available/consumed calculations for shares seems to be dependent on them.
If it would be better to take this to a new thread, I'd be happy to do that.
One more question on the original topic, though: My snapshot setup has been largely unchanged for quite some time, and has survived several firmware updates prior to 6.7.0. Was there something in particular that changed with the 6.7.0 release that made it an issue?
Was there something in particular that changed with the 6.7.0 release that made it an issue?
The option to disable quota accounting (at volume level) was added in 6.7.0. The release notes showed minor changes with snapshots. That's for the public knowledge.
It seems that 6.7.0 was pulled from the update server because of a quota issue of some sort:
