Synology DSM 7.0

[Perkolator]

Synology released a new major DSM version 7.0 on 2021-06-29. The dead-mans-switch script is not yet tested with that version. I'm waiting a bit to upgrade my personal NAS device to that major version/branch.

[SauerDeschain]

Hey! Are there any updates for this script or should it be good to run as is?

Thank you for your work.

[Perkolator]

Hello SauerDeschain, thanks for the interest for my script! :)

I can't believe it's already almost 2 years since I posted that announcement. Time flies really fast. I still haven't updated my DSM to version 7. However, I already put this task to a higher priority few weeks ago, I just need to do few other things first, and then prepare to upgrade DSM. So I'm going to test my script, and fix it if needed, with the newer DSM version somewhat soon (most probably before June, no promise though, in case I get problems with the upgrade).

If you're already running DSM 7, there's really nothing stopping you to test the script for yourself, the script can't do any harm, it tries to catch all kinds of errors and notify the user. So, if you want, at your own risk (I have to say this), you could run (manually) the script from DSM Task Scheduler with the following options: --days 3 --log 2 --email. This will log & email you a full log of any encrypted shares it detects & possibly unmounts if conditions apply. For further testing, you can run the script with the following options to "force" unmounting ALL mounted encrypted shares immediately: --days 0 --log 2 --email. Once again you should receive a full log of all encrypted shares the script detected & unmounted (check also from your DSM shares settings that this actually happened).

[Perkolator]

SauerDeschain: I'm sorry for the delay. I ordered new HDD's for my NAS back in May but the shipment went missing and now I've been waiting for replacements from the seller, which for some reason is taking time. I'll try to update to DSM7 and test the script as fast as I can.

[Perkolator]

Finally have updated my NAS to DSM7.2 and quickly testing the script, I can see that it does not work: ERROR: The '--enum' option of 'synoshare' program has been changed!. I need to fix the script. Just giving an update on this. I'm on it! :) (Hmm, not many users of my script I see, otherwise someone would have reported it.. or perhaps they fixed it themselves.)

[Perkolator]

Update: I spent almost the whole week battling with the SMB service of the DSM 7. No matter what settings I use, it seems to perform worse than in DSM 6 in certain situation (when browsing folders with subfolders that have lots of big files, this when browsing in "list view" with a "size" column with "count number of items" enabled in linux file manager (Nemo)). This was a problem with the DSM 6 too, but not this bad. Horrible freezes when browsing certain share folders (sometimes the view seems to be cached but not always). A bit disappointed about this with DSM 7. Maybe the separation of the SMB feature to its own package has affected the performance?

Anyways, today I started to check the script functionality with DSM 7. I can see already that unfortunately I need to re-think/design the process of checking "inactivity" & unmounting shares. It seems that DSM 7 "lumps together" all SMB connections from the same user (check the "Connections" in "Resource Monitor"). This seems to have an effect of "re-connecting" all share connections (creating new "user ... accessed shared folder [xyz]" log entries) when unmounting even a single encrypted mounted share. In other words, if a single encrypted mounted share is unmounted, all other shares have instantly newer "access" dates, which delays (with the amount of days the user have set) the possible (if conditions apply) unmounting of other shares.

Kind of accidentally noticed this when checking the "synoshare" command functionality and reading log messages from Log Center.. good that I noticed this already at this stage (would definitely have noticed this later when doing "real-life" tests, not just from running the script from terminal via SSH).

Fortunately the "synoshare" command allows unmounting multiple shares at the same time (if it would not allow it, this script would be basically dead now). But unfortunately this whole thing has (at least) few drawbacks: 1) controlling the possible unmount failures; if one share fails to unmount, all of the shares in the "synoshare" command after the failed share are not unmounted, 2) if only e.g. 2 out of 5 encrypted mounted shares are unmounted at the same time (different access timestamps for the rest of the shares), then the other shares access timestamps are "renewed" and unmounting of those would be delayed (with the amount of days the user have set). The first one is somewhat easy to solve but the 2nd one gets a bit convoluted to solve; would need at least to keep a separate own database of access times, figuring out when what timestamp is more accurate (own database or syno database), etc... dunno if I'm going to fix this one.

So, working with this now. Need some time to fix and test everything(?).

[Perkolator]

Little update.

About the 2nd problem in the previous message; I tried to come up with a reasonable solution to it, but it gets too complicated. Unfortunately wasted too much time for this. Fortunately it's a "problem" that only has a slight drawback (slight delay of when the rest of the shares are unmounted) on certain situation (connections to share(s) still "active", e.g. computer left running).

The code is 95% ready, many enhancements, need to write some documentation (changelog, readme), need to run "real life scenario" tests.

Expecting to release the new version next weekend.

Sorry for the delay.

[Perkolator]

Ok, finally the new version is available. I'm very sorry for the very very, very long wait. I had a catastrophic failure with the new HDD's just when I was finalizing & testing the new version some time ago and it took time to get all back up like it was.. and tell you the truth, was so angry (mildly put) with what happened that I had to take some weeks off even thinking about anything related to Synology.