NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Tech support
After installing a recent OS 6 upgrade (from 6.5.1 to 6.6.0) to my Readynas312, the backup feature fails to operate. I have reached out to the community forum for help but that has not been fruitful...
I much appreciate your efforts and attention to resolving my issue. Since adding an actual account name, my backups seem to be working again which I am very pleased about. I do question, however, that the root of the problem lies with changes in Windows because: 1) This issue first became apparent to me a couple of months ago when I went from OS 6.5.1 to 6.5.2. 2) When I reverted to 6.5.1 again, I was able to do backups without adding any login information. 3) If the problem was on the Windows side, it seems that I would have had to add login information irrespective of the version of Ready NAS OS I used (6.5.1 or 6. 6.5.2 or 6.6.0). To me it seems that the problem is in whatever changes (or ommissions) were made in coding in version 6.5.2 which have been carried forward. Admittedly, I have no great expertise in this area, so I may be very wrong; I am just applying some logical reasoning.
One other thing comes to mind. You may want to make this information more widely known because the setup information and guides must now be updated. As I remember, the setup information suggests that if you turn off the need for a logon password in Windows, you do not have to add the login information now beiing requested. I am certain that many people are being frustrated by this change.
In any case, the matter is now moot and I am a happy person. Thank you again.
Thanks for providing the logs and access to your NAS.
Your backup job is a SMB backup job -- you asked the Backup job to connect to "/users/mike/2go" which is a folder that doesn't exist from where you're trying to pull data from. Additionally, there may also be some case sensitivity issues. Your actual path is "/Users/Mike/" and there is no 2go folder inside there. Your "2 go" folder is actually inside the "Desktop" folder. So the real path is "/Users/Mike/Desktop/2 go/"
The other issue that you're experiencing is that we're trying to mount your computer as a "guest" which seems to be denying access. When I mount everything manually using any user without a password, it seems to work fine, but when the backup job tries, it has some blocks. I'll work with the developers to find a reason for this.... however, you can see below that I was able to get your test job working successfully. I made no backend modifications to address this. Please confirm for me by putting more pictures in your "2 go" folder and then starting the job and confirm they get sent over. You can also review the backup job change I made for further insight.
Backup Job Name: test
Backup Job Type: Incremental
Protocol: cifs
Backup Source: [remote:cifs]///your-computer/Users/Mike/Desktop/2 go
Backup Destination: [Pictures]/
Backup Start Time: Wed Nov 9 2016 12:56:00
Backup Finish Time: Wed Nov 9 2016 12:58:01
Backup Status: Success
Copy File LZ1A3175BW.jpg
Copy File LZ1A3178r.jpg
Copy File LZ1A3179r.jpg
Copy File LZ1A3217.JPG
Copy File zermatt.jpg
I appreciate all of yur efforts to address this problem. I added more photos to te file as you suggested and tried the backup by starting it manually. I made no changes to what you did. The backup did not work, files were not transferred. I am not quite sure how you were able to do the transfer, but believe that you are getting closer to resolving this problem.
The root cause of this is a change in Windows that requires guest logins to supply a username, but the username must not exist on the Windows system. So, basically we need to supply a bogus username. The SMB mount utility doesn't do that, and thus recent Windows versions reject the guest login. You can work around the problem by having the backup job log in to the share with an actual account. Alternatively, if you'd like to continue using a guest login, you should be able to fix it by installing one of these packages: ARM or x86_64. Install through Apps -> Upload.
I much appreciate your efforts and attention to resolving my issue. Since adding an actual account name, my backups seem to be working again which I am very pleased about. I do question, however, that the root of the problem lies with changes in Windows because: 1) This issue first became apparent to me a couple of months ago when I went from OS 6.5.1 to 6.5.2. 2) When I reverted to 6.5.1 again, I was able to do backups without adding any login information. 3) If the problem was on the Windows side, it seems that I would have had to add login information irrespective of the version of Ready NAS OS I used (6.5.1 or 6. 6.5.2 or 6.6.0). To me it seems that the problem is in whatever changes (or ommissions) were made in coding in version 6.5.2 which have been carried forward. Admittedly, I have no great expertise in this area, so I may be very wrong; I am just applying some logical reasoning.
One other thing comes to mind. You may want to make this information more widely known because the setup information and guides must now be updated. As I remember, the setup information suggests that if you turn off the need for a logon password in Windows, you do not have to add the login information now beiing requested. I am certain that many people are being frustrated by this change.
In any case, the matter is now moot and I am a happy person. Thank you again.
Yes, absolutely it's a combination of factors. Guest authentication against Windows 7 works from both 6.5.1 and 6.6.0. So certainly there is a change in behavior with recent Windows versions in play here. Also, there was a bug fix added to the Linux kernel (here) to comply more fully with Microsoft's SMB spec (here) when doing guest authentication. This change dropped between 6.5.1 and 6.5.2, and broke guest authentication against Windows 10. So either Windows 10 is violating the MS SMB spec, or there was a misunderstanding of the spec by the Linux kernel developers. It's not obvious to me at this point which is the case, but we're still pursuing it.
6.6.1 will work around the issue by adding an automatic retry of guest authentication attempts with a bogus username added.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
