lewcass

After I reverted to 7.1.3, I had no further issues, so decided to let well enough alone for the time being. That was until 10/24/25, when the issue showed up again. I was unable to get connection to GitHub for a plugin update check. I disabled bonding and the connectivity worked again. Today, I updated to 7.2.0, and re-enabled bonding with the previous settings, and plugin update check is working again using the earlier bonding configuration.

I have experienced a similar issue with 7.1.4. Also resolved by going back to 7.1.3. No connection to GitHub. Entire LAN slowed to a crawl whenever GitHub connection attempted. Also running bonded NICs, including one Intel. Detail below. The Realtek NIC driver has been updated. Sorry I captured no logs. Been too busy troubleshooting other tech! [10ec:8168] 22:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15) [8086:10d3] 24:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

No. It's hardly an ideal workaround. I've been a happy UNRAID user for around 15 years and was the person who first came up with the idea to include network monitoring in the original sleep script, but it's really not the answer for malfunctioning disk monitoring. Especially since the current Dynamix S3 Sleep runs the time lag countdown before the network monitoring check. That could be changed, but isn't a solution to the root issue with the disk monitoring. While I've been a big fan of UNRAID and the community and developers that support all the useful features that have been added, this is where the support model fails. i.e., when a useful plugin developer is no longer present to maintain their work. Since this disk monitoring issue came up, I've struggled to deal with it, and only recently found the time to check here, to confirm I was the not the only one affected. What I've had to do in the meantime is manually disable and later re-enable the Sleep settings from the Dynamix GUI. This isn't really any better than permanently disabling the script and using the Dynamix GUI to manually put the server to sleep when not using it.

This week I updated to 6.10.3 and Windows 11 Pro 64 also updated to KB5016629 (OS Build 22000.856) and KB5015732 Cumulative Update Preview for .NET Framework 3.5 and 4.8 for Windows 11. Now I no longer have write access to public shares on UnRAID. Before either update this was never an issue. This is a big problem for me. How do I get write access back to public shares?

Ditto. On 6.6.2 with 2.2.0j.

I found an issue with the new UNRAID 6.6.0 Dynamix Black Theme. White text on the Server Layout plugin Data screen does not display properly against the screen areas with white or light backgrounds on this theme.

I typically use this plugin to backup key data to hard disks for offsite storage. It works very well for the most part, but the challenge comes in recognizing whether adequate space remains on the backup disks as the data on the server grows. So I've been tying to figure out how to use the plugin's AVAIL variable in my scripts to both log and notify the webgui as to the amount of space available when the disk is mounted and how much remains after the backup is completed. My scripting skills/knowledge are pretty minimal and so far I haven't been successful. Advice would be very much appreciated!

Since no one else has been reporting the issue, could (likely) be completely unrelated to the update. (See logical fallacy: post hoc ergo propter hoc) When I have had similar issues with S3 sleep not recovering properly it has been related to overclocking, specifically the bus-clock. If you aren't overclocking then it also might be hardware related; e.g., power supply no longer delivering adequate standby power, or failing RAM or motherboard. You might want to do some hardware testing. Edit: To clarify, the S3 sleep overclocking related issues I was referring to were with PCs other than my UnRAID servers. I wouldn't overclock a server with data on it I wanted to preserve. Also, more to the point, what I would do first is completely remove unRAID from the equation by booting with another linux distro on a separate flash drive and testing sleep from there. If problem still exists, certainly points to hardware or BIOS settings.

DUH! I'd completely forgotten about that with the passage of time since I first set up the plugin after UnRAID 6.0 came out. Unfortunately the setting location isn't particularly obvious or intuitive. The good news is that it looks like that is solving my issue! So thanks! My theory about the non-array drives was wrong. Even with them removed, after a wake-up the plugin was still continuing to treat the cache disk as active. It was only working correctly before the first S3 sleep was initiated. Setting the plugin to ignore the cache disk seems to be solving the issue. Hope you are successful getting your issue resolved.

Previous version is not compatible with unRaid 6.4.x If you enable the debug log, you may be able to find out why the current version is not working for you. I have mine set to log to Flash. You can view the log in the logs directory of you flash drive. \\TOWER\flash\logs\s3_sleep.log I don't see any setting to ignore cache drive. If it is possible I would like to know how.

Set the Tunable (poll_attributes) to 180 (~3 min). Shutdown. Reinstalled the hot-spare disks in the cage. Rebooted. Left server do it's thing (idling). Drives spun down. Sleep plugin script did it's thing. Server went to sleep. However, woke server with WOL, played media for an hour using only one disk. Left server idle. Disk that was in use spun down. Then same issue as before. Tue Feb 13 17:43:10 EST 2018: Disk activity on going: sdd Tue Feb 13 17:43:10 EST 2018: Disk activity detected. Reset timers. Tue Feb 13 17:44:10 EST 2018: Disk activity on going: sdd Tue Feb 13 17:44:10 EST 2018: Disk activity detected. Reset timers. Tue Feb 13 17:45:10 EST 2018: Disk activity on going: sdd Tue Feb 13 17:45:10 EST 2018: Disk activity detected. Reset timers. Tue Feb 13 17:46:10 EST 2018: Disk activity on going: sdd Tue Feb 13 17:46:10 EST 2018: Disk activity detected. Reset timers. Tue Feb 13 17:47:10 EST 2018: Disk activity on going: sdg Tue Feb 13 17:47:10 EST 2018: Disk activity detected. Reset timers. Tue Feb 13 17:48:10 EST 2018: Disk activity on going: sdg Tue Feb 13 17:48:10 EST 2018: Disk activity detected. Reset timers. Tue Feb 13 17:49:10 EST 2018: Disk activity on going: sdg Tue Feb 13 17:49:10 EST 2018: Disk activity detected. Reset timers. Tue Feb 13 17:50:10 EST 2018: Disk activity on going: sdg Tue Feb 13 17:50:10 EST 2018: Disk activity detected. Reset timers. Tue Feb 13 17:51:10 EST 2018: Disk activity on going: sdg Tue Feb 13 17:51:10 EST 2018: Disk activity detected. Reset timers. ... Tue Feb 13 19:49:16 EST 2018: Disk activity on going: sdg Tue Feb 13 19:49:16 EST 2018: Disk activity detected. Reset timers. Tue Feb 13 19:50:16 EST 2018: Disk activity on going: sdg Tue Feb 13 19:50:16 EST 2018: Disk activity detected. Reset timers. Tue Feb 13 19:51:16 EST 2018: Disk activity on going: sdg Tue Feb 13 19:51:16 EST 2018: Disk activity detected. Reset timers. As soon as the active array disk spun down the sleep plugin once again began logging the cache disk (sdg) as active and is continuing to do so over two hours later as I write this. All this time the cache disk is shown as inactive in Dynamix GUI. So changing the disk poll attribute has not addressed the issue. Tomorrow I will remove the hot spares again and test longer to see if the sleep plugin will work consistently without non-array drives present.

OK I'll give it a shot. I'm dubious though because the plugin was consistently logging that the cache was active for hours at a time (like all night and then some), when nothing should have been happening. So difficult to understand why polling every thirty minutes would not have been sufficient to update the status correctly.

Would the setting of that parameter explain why the Dynamix GUI has been showing the the cache as inactive at the same time the sleep plugin was logging it as Disk activity ongoing?

All disks/drives are connected to onboard SATA.

Yes, but it was consistently showing it spun up for hours while the Dynamix GUI was continually showing it as inactive. Please consider my previous post and whether having two additional disks connected but not in the array may be causing the plugin to lose track of the status of the final (cache) disk. Thanks.