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.
Using OS 6.5.1, the process for enabling snapshot protection for user home shares is extremely non-intuitive (assuming I've finally got it right.)
This is a fresh installation on brand new drives... The device was upgraded to 6.5.1 before I pulled the old drives and put the new ones in. (It might matter that my RN516 is attached to ADS.)
First you have to go to Accounts -> "Default user", and turn on protection for "home folder." No, it's not turned on yet. Now you have to go to shares, and hit the gear icon on the far right of the "home folders" share, select 'settings' and choose the "Snapshot Schedule" page. From here, you set up the schedule (which is apparently shared by all user folders.)
Wait, it's STILL not working! Hit that gear icon again, back into settings, and this time go to "snapshot access." It doesn't matter that "snapshot access" every other place in the UI refers to making snapshots available as seperate shares. Here, it's also used to actually turn on the snapshots for each user. So, search for your user, and turn on the "protection" checkbox. (You don't need to enable snapshot access, we just needed the page to turn the silly thing on.)
And now.. it STILL doesn't work. Out of curiousity, I also turned on "allow snapshot access" for the user, and it pointed to a folder that DOESN'T EXIST on the NAS. It claims my snapshots will be in "/home/MYDOMAIN/garyd9/snapshot" when the user folder is actually "/home/mydomain/garyd9" (notice the case difference in the domain.)
I wonder if THAT is the problem. It wouldn't surprise me, as I've had many other problems with ReadyNAS devices on ADS and the NAS getting confused between MYDOMAIN and mydomain all the time.
Trying to troubleshoot this, I also dropped into ssh and found no snapper job listed for the home share with "snapper list-configs", and "btrfs subv list /data | grep garyd9" only shows my normal home share and my user timemachine subvolume. Nothing more.
bump? If someone from netgear can offer a suggestion on at least how to kick-start the user directly snapshots, I'd appreciate it.
I really don't want to have to open another support ticket and re-explain everything posted here (and deal with 2 layers of "did you reboot", "have you tried to factory reset", and "open ports in your firewall to give random people remote access to your internal LAN for the several days until we get around to actually remoting in."
Will do over the weekend and complain about it let you know Mondayish.
BTW, @mdgm-ntgr, I just got one of those (annoying) popups asking for website feedback while in the middle of typing this forum reply. Can someone please contact *whoever* is responsible for the website and let them know that there are certain website activities where those popups are Very Bad?
It appears to have made a snapshot last night. I marked the suggestion as a solution.
However, there was one slight oddity with 6.5.2 (related to snapshots) that I'm hoping you can pass along:
(Running in Active Directory mode...)
After I upgraded to 6.5.2 from 6.5.1, I navigated to the "shares" page, and hit the "gear" icon related to "Home Folders", and selected "Settings." From the popup, I selected the "Snapshot Access" header, to see that all domain users (including non-interactive users such as domain service level accounts) had "Protection" enabled. I UNSELECTED the protection box for each of those users and clicked "OK." So far, so good.
Then I got alert emails, one for each user I deselected, from the NAS, telling me that the password for the user was changed. I knew these to be false simply because the NAS doesn't have rights to change those passwords, but the false alert email was ... (heh)... alerting. 😉 (and obviously a bug.)
Re: home/user share snapshots fails, and ftp masquerading issues
I have a similar problem.
I had issues with snapshot creation in home folders with some of the accounts and i upgraded from 6.5.1 to 6.5.2 waiting for a fix.
The issues remain the same.
I have disabled for an unknown reason the snapshots in the home folders for my oldest users (admin user, my own account and two family members). I can't tell from what os version i have the issue because i don't check very often if that works because i assume the system works as expected if you don't touch anything. I tried to disable snapshots for all, then move the files, delete the folder, re-login for recreate the folder, move the files again, enable snapshots.. It didn't work for that users, still works for the rest.
I could try to delete users, recreate and lose some time with the folder permissions (may be work, maybe not) , but what about the admin user? I think it can't be deleted and recreated without some side effect..
By the way, my ftp only allows secure connections from external addresses, if you try an unsecure connection, passive connection doesn't work: I can login into the server but connection is refused when pasv mode is enabled and msld command is sent. In the LAN unsecure and secured connections works as expected. The ftp server has masquerading enabled and ftps enabled but not forced.
If i disable ftps and masquerading, standard ftp works on external connections, and passive mode works. With ftps enabled and masquerading disabled, unsecured connections work, but secured connection not because passive mode fails (Server returned unroutable private IP address in PASV reply, but with unsecured connection it works, i can't understand).
I don't understand because ftp with masquerading fails but ftps with masquerading works, and ftp without masquerading works but ftps without masquerading doesn't work.
I want to have standard ftp and, optionally, ftps from external addresses. It worked fine as expected with a non forced and masqueraded ftps setup (to resolve external ip), but from 6.5.1 (at least) it doesn't.
Depending of the ftp client, i have timeouts with ssl handshake, but this is a very common issue with Proftpd..
I don't understand because ftp with masquerading fails but ftps with masquerading works, and ftp without masquerading works but ftps without masquerading doesn't work.
