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.
This week has been a MAJOR ClustrFrack brought to us by the incompetance of NetGear.
Sparing the rant and moving to the current problem
After finallygetting this thing back online with 6.10.1, my final step was to change the admin password from the default.
Since then, I have been locked out of the admin interface. It does not accept the CORRECT password OR the default password. It locks me OUT five minutes at a time before I can try again... And, to add another kick in the 'nads... Yes! That's right! Password reset/recovery will not work!
Anyone got any real options besides resetting this thing AGAIN?
Deciding just to give up... I reset the system to factory settings. Again.
On the web-based setup, it prompts for all the password information and recovery options....
When clicking 'Next', it displayed an error that the 'Recover Password" method was not successful. After going back to the previous steps, I tried default AND the password I entered... No access... And, locked out again.
That would be funny if it weren't so utterly (and typically) dismissive of the problem..
HTF do I lock myself out by just updating a password and logging back in? How does a system just become unresponsive to proper login credentials. Please explain using small workds - as you obviously think I am too stupid to change a password and log back in properly... ALSO.... not the only one here with this problem ace!
Now... has anyone found a solution for this? or do you just want to continue insulting my intelligence?
if it makes you feel any better... you are not crazy... the same thing happened to me - I had an RN528X & RN628X Running 6.9.5 - I backed up the data.. did a firmware upgrade to 6.10.1 then did a factory reset.. when to change the default password to something else.. seemed to login OK... then about 20mins later it kept telling me my user/pass was incorrect & locked me out -- in my case (since no data on the NAS) Did another Factory Reset & password change.. and I've not had a problem since - it's probably a bug introduced since 6.9.5 but happens in rare situations so it's hard to Reproduce (therefore hard to fix) -- I always have a 2nd NAS Server as a Mirror backup to the 1st - then mission critical data on the NAS devices backed up to the cloud... so 3 copies..
Model: RN528X|ReadyNAS 528X - Premium Performance Business Data Storage - 8-Bay, RN628X|ReadyNAS 628X - Ultimate Performance Business Data Storage - 8-Bay
HTF do I lock myself out by just updating a password and logging back in? How does a system just become unresponsive to proper login credentials. Please explain using small workds - as you obviously think I am too stupid to change a password and log back in properly... ALSO.... not the only one here with this problem ace!
While it may not be the cause of your issue, the typical reason for this is that you have some other system on the network that is logged in, or is attempting to do so, using the old admin login credentials. Since OS6.10.1 implemented login lock-out with too many wrong login attempts, that other system is trying too many times and all attempts, including those you are performing, are locked out.
This is one of many reasons that it is unwise to use the admin login as your general login, though the consequences are newly more dire.
I had originally suspected the same thing. But, multiple admin connection attempts over the network wasn't the issue in my case. After I sorted the NAS with a new IP address , I checked every device. There were none set to login with the original admin credentials. There were three that were trying to log in with user credentials which did not yet exist on the NAS at that point in the recovery.
Do these failed user logins count towards the 5 fails? I don't know. As usual, NG implements these nightmare features with very little documentation, forethought or concern for the obvious downside to users. And, they never EVER provide the simplest solution of all which is to disable the 'feature' if it causes problems. ANY new feature should be considered beta and, have a kill switch for just such cases.
Most home users do not have their NAS set up as an internet-facing applicance. And, those of us who DO - well, your router and firewall are there to prevent these kinds of things from occurring. USE THEM!
If the 'feature' whitelisted the LAN and WLAN IP ranges, it would make some SOME sense. But, lacking that, you are asking your NAS to do the job of a router/firewall... without ANY of the configurable settings required to do it correctly and efficiently.
What this feature is designed to accomplish is beyond my limited understanding. What I DO know is that it is NOT implemented in any reasonable way that enhances the user experience or actual security.
What this feature is designed to accomplish is beyond my limited understanding.
The feature was requested in the forum - the idea was to block brute-force attacks on the NAS admin password - a concern for people who have ssh forwarded in their router to the NAS.
Obviously the implementation has some significant side effects.
Actually many attacks are also done from the internal network. And firewall is nothing that will do any comparable security effect like admin lockout, you only are able to enable or disable the complete access. Some ways to do a little defeat against brute-force attacks are making sense, and lockout after some failed logins is absolutely one of them no matter internal try, or external try.
I have to say: This feature is very reasonable in many ways.
I also think, it maybe could have some more features (specifiy how many attempts, how long the lockout occures etc..) or maybe better documentation. but:
The feature was requested in the forum - the idea was to block brute-force attacks on the NAS admin password - a concern for people who have ssh forwarded in their router to the NAS.
Obviously the implementation has some significant side effects.
Ahh! I see. So... this feature should only be enabled for those who have set up SSH connections... (I could live with that - since I would NEVER set up a permanent SSH tunnel to my devices.) So , these SSH connections are set up via their router... which has a firewall function... that should be properly configured to deny incoming SSH connections from offending and unauthorized IPs. So basically, SSH users want their NAS to perform a function of a router's firewall. But, instead of blocking the offending IP address, NG locks out the admin. YET... user accounts are left wide open with no such protection.
You really can't make this stuff up. <LOL>
I apologize. CERTAINLY No disrespect is directed towards anyone here, But, you have to admit - that's some pretty bone-headed decision making, by NG, right there.
The feature was requested in the forum - the idea was to block brute-force attacks on the NAS admin password - a concern for people who have ssh forwarded in their router to the NAS.
Obviously the implementation has some significant side effects.
So... this feature should only be enabled for those who have set up SSH connections...
The same threat also applies to https access (via the web admin ui). FWIW, I haven't actually tested the feature against ssh.
Actually many attacks are also done from the internal network. And firewall is nothing that will do any comparable security effect like admin lockout, ...... Multiple failed admin logins will lock the account for 5 minutes.
So if that's your problem, you could take of the Readynas from you network, and try it directly with an attached cable / config.
I can grant that it may have some limited use to business users. But, I still hold to the claim that configuration options - including the option to disable it is more reasonable than shoving a defective new feature down our throats.
I can just now confirm that a subsequent update has seemingly corrected/eliminated this problem for now. 6.10.0.2 seems to be OK. It is not locking me out yet.
@Steedvlx600 wrote: But, I still hold to the claim that configuration options - including the option to disable it is more reasonable than shoving a defective new feature down our throats.
I agree it would have been better to have some options (including disabling it).
Though I think saying that they are "shoving a defective new feature down our throats" isn't really accurate. This is a feature that the community requested.
I agree it would have been better to have some options (including disabling it).
Though I think saying that they are "shoving a defective new feature down our throats" isn't really accurate. This is a feature that the community requested.
I'll stipulate to the fact that it might be useful to some... when it is ready for distribution - it isn't in the present form.
Having been the victim of three destructive NG firmware updates just recently (2 orbi systems [forced updates without authorization] at separate locations as well as this ReadyNAS fiasco) I am ready to conclude that NG is using hapless end-users as captive beta testers. I truly apologize for the ire. But, this really needs to stop. And, this community is the only place to voice these sentiments where we even have a small chance that NG will see the message.
