You need to make sure that both network access and file access permit access. If you are managing access at the share level (and not for individual files and subfolders), you can just set file access to allow everyone access (using network access alone to manage access).
You might try checking the "grant rename and delete privileges to non-owner" checkbox on the file access page of the share settings - ignoring the comment there about AFP and NFS.
If you make any changes to file access, you need to use the RESET control on the left to apply those changes to existing files and folders in the share.
Sorry Stephen for the late response. We had a small Covid-19 outbreak and where relocated to the home office which got some priority.
We have only one Share which holds the security surveillance camera movies
Only SMB is activated
I currently set the configuration as followed:
Network Access (SMB Tab) grants Read/Write to everyone
File Access grants Read/Write to everyone
Folder Owner / Folder Group is guest
Grant Rename and Delete is checked
Reset is performed
The user still get a "access denied" when they are creating a new empty folder.
-----
Update:
I build a new share and started to move the files now... the new share semaed to be working. I have also updated now another ReadyNAS device to the latest firmware and got there as well the same issues ... rebuilding the share also solved the issue there. So something must have changed in the Firmware which caused these kind of issues ...
The rsync issue is one that others have also reported. Most who need that are reverting to 6.10.3.
Yep it's what I did and everything is working fine again.
Does anyone know if Netgear actually wants to fix it?
Indeed they had a couple of weeks now to relase a 6.10.5 or at least 6.10.4.1 with a proper fix for such an important and dangerous issue, especially when users believe the backups run normaly...
6.10.4 Hotfix 1 has been pushed out (unsure what it fixes as google does not reveal anything)
also for backups you really should be using Pull for backups not push (if your main nas can write to your backup nas So can ransomware), i guess you can use snapshots to undo the delete
also for backups you really should be using Pull for backups not push (if your main nas can write to your backup nas So can ransomware)
That is one consideration, but there are others.
Push backups are atomic - the system makes a snapshot, and then backs up the snapshot. So if the share is updated during backup process, there is still consistency/integrity on the backup.
On the other hand, if your backup NAS is on a power schedule, then you need to use Pull. The backup ReadyNAS won't shut down until the backups are finished if you use Pull - but they will shut down on schedule if you use push.
Not sure if you are addressing someone's problem or if this is linked to your ransomware thought. FWIW, I do have snapshots enabled on both my main NAS and my backup NAS.
The bug in push backups results in a backup that appears to work, but doesn't. So there is nothing to undo on the backup system.
If ransomware simply deletes files, then you can roll back if you have a snapshot. But usually ransomware encrypts the files. At some point the NAS hits the 90% full threshold, and it will start deleting snapshots to reclaim space. Unfortunately, that's exactly the wrong thing to do in a ransomware attack, as it will end up deleting your real data.
One way to avoid this outcome is to maintain at least 60% free space on the NAS.
You can also maintain an air-gapped backup of some kind, which would reduce data loss. I have multiple backup NAS, and they back up on different days. They are on a power schedule, so I do have time to disconnect them from the network if ransomware strikes.
There are cloud backup services that also can be used to mitigate this (and also provide disaster recovery in case of fire, theft, etc). Backup and restore often aren't that fast, so IMO it's best to use these in conjunction with local backups.
Yah - 6.10.4 was a complete FAIL, and so was 6.10.4 Hotfix 1. Must have been updated by a noob. At least they properly planned for more Hotfixes increments, just didn't deliver on that. Must be some huge shake up at Netgear - very sad. They should voluntarily donate back to Infrant what they bought from them so they continue to deliver a great product instead of giving up on it. Thankfully, (4 NAS boxes later since purchasing my first Infrant 600TL which still works flawlessly after a full capacitor replacement) - I don't own another Netgear product and don't plan to buy one anytime soon. They're like Logitech, create or purchase something cool and new then they stop supporting leaving us hardware holders with a cold door stop. I'm done with both of these brands!
I'm also very thankful for people like @StephenB and several others on this site who have been very good at helping us through many of our complex issues! Thank you for your dedication and expertise! I will continue to use my ReadyNAS boxes until their clocks stop ticking.
~Cheers
RIP ReadyNAS!
Model: RN628X|ReadyNAS 628X - Ultimate Performance Business Data Storage - 8-Bay
Yah - 6.10.4 was a complete FAIL, and so was 6.10.4 Hotfix 1. Must have been updated by a noob.
Actually, I've found Netgear's regression testing to be clearly lacking in general, not just with the latest updates. They appear to rely far to much on unpaid beta testing instead of having a proper in-house test process. My guess is that they also lack an independent test process -- that the programmer simply tests his/her own code. Proper software testing entails not only testing anything new, but regression testing to insure nothing was unintentionally broken. And the only way to properly accomplish that is via a documented test procedure, updated as required so each new feature is tested in all updates that follow. Ideally, it's also not performed by the programmer, who is biased to think he couldn't have possibly made an error.
It does not, and it has introduced a new problem logging on for some users, so avoid it for now. In one of the threads on that other issue, it looks like Netgear has identified a fix, so I'd expect either a new version or a hotfix for 6.10.5 soon. But I rather doubt they'll have the rsync fix in that one, either, since the login issues is going to be high priority.
