meaning

Hm, ok, it looks like on your system Disk Talkers is running again, but still cannot attach the activity to a named app/container/process. Could you please share the output of this command after one of those disks has spun up and still shows unattributed activity? cat /tmp/disk.talkers/state.json Also useful: - your Unraid version - whether the apps use /mnt/user/... or /mnt/diskX/... paths - any syslog lines around the spin-up time That should show me where the attribution is being lost.

Hey mmm77, Thanks for the report. This should be fixed in Disk Talkers 2026.06.03a. The error means that one of the Unraid mount paths Disk Talkers was watching briefly disappeared or changed while the collector was running. Disk Talkers was handling that too aggressively and could disable fanotify permanently until restart, which then made historical attribution fall back to “Other activity”. This is not, by itself, proof of a failing disk. But if you keep seeing similar mount-related warnings after updating, it would be worth checking your Unraid syslog, disk/pool mount state, and SMART reports for any recurring disk, controller, or filesystem issues. Existing historical “Other activity” entries will not be retroactively fixed, but new samples after updating should keep fanotify active and preserve attribution much better. Let me know if it's allright now ! :)

Yes, you were right. I profiled it and Disk Talkers was doing too much work every 5 seconds, mainly repeated fuser scans and history recalculation. This is fixed in 2026.05.03a; on my test server it dropped from about 15.6% of one CPU to about 1.25%, while keeping the 5s UI refresh.

Thanks for the report. This was caused by Disk Talkers starting after reboot with a reduced service PATH, so it could not find Unraid’s mdcmd binary. This should be fixed in 2026.04.26a: update/reinstall the plugin and it should recover after reboot without needing an uninstall/reinstall. let me know if the problem is fixed at your next reboot ;)

Thanks, you were right: on Unraid 6.12+ exclusive pool-only shares can make /mnt/user/<share> resolve directly to the pool and bypass shfs/FUSE. Disk Talkers 2026.04.21a now treats those mounts as safe, while non-exclusive pool-only /mnt/user mounts remain low-severity informational warnings.

I’ve pushed a light-theme compatibility fix. :)

can you update and let me know if this would be ok ?

Fixed in 2026.04.17c. The historical summary panels were using a layout combination that could visually overflow the parent card. I’ve corrected the panel sizing/containment and published the update. Please update the plugin and hard-refresh the page and let me know ;)

Hey there, can you update the plugin and see how it looks now ?

Disk Talkers adds a dedicated Unraid page to show what is actively keeping array disks and pools spun up. The goal is simple: make it easier to understand which apps, containers, VMs, or host-side activity are touching your storage, and help reduce unnecessary array spin-ups. What it shows - Per-disk live status spun up / spun down) - Current read/write throughput - Live disk users, including: - Docker containers - VMs - host services - user-share access through shfs - Array-wide summary of apps currently keeping HDDs spun up - Historical usage views across: - Daily - Weekly - Monthly - Yearly - Historical attribution estimates showing which apps were most involved in keeping disks active - Estimated HDD energy usage and electricity cost based on configurable watt ranges and tariffs - Mount audit to highlight containers using /mnt/user or array-backed paths where a direct pool/cache path may help avoid unnecessary spin-ups Why this exists On many Unraid systems, disks stay spun up and it is not always obvious why. Sometimes the cause is direct array access. Sometimes it is a container using /mnt/user/... instead of a direct cache or pool path. Sometimes it is a service or background scan that keeps touching files often enough to prevent spindown. Disk Talkers is meant to make that visible. ## Main features - Dedicated Unraid WebUI page - Live refresh - Disk-by-disk visibility - Historical usage overview - Mount-path audit for Docker containers - Estimated power and cost visibility - Quick actions and configuration inside the plugin UI Install Until Community Applications listing is live, the plugin can already be tested with the direct plugin URL. WebUI method 1. Open your Unraid WebUI 2. Go to Plugins 3. Click Install Plugin 4. Paste this URL: https://raw.githubusercontent.com/silkyclouds/unraid-disk-talkers/main/disk.talkers.plg CLI method installplg https://raw.githubusercontent.com/silkyclouds/unraid-disk-talkers/main/disk.talkers.plg GitHub Source and releases: https://github.com/silkyclouds/unraid-disk-talkers Notes - Attribution is best-effort. Very short-lived activity may still appear as residual or unattributed activity in history views. - Energy and electricity cost values are estimates based on HDD uptime history plus user-configured watt and tariff settings. - This plugin is intended to help identify real-world storage behavior, not to claim perfect block-level forensic attribution. Feedback Bug reports, screenshots, edge cases, and UI/UX feedback are very welcome, especially for: - shfs / user-share attribution - incorrect container attribution - historical attribution gaps - cases where cache/pool mounts should be preferred over array-backed paths - installs and upgrades across different Unraid versions

Hey, I’m running into the same headaches with S3 sleep on Unraid, so I figured I’d share my setup and ask for advice. Main server with a big array + HBA → ~95 W idle Base system alone (CPU/RAM/fans, no HBA/array) → ~25 W idle So ~70 W are literally wasted 24/7 just to keep the array/HBA alive Electricity here is ~0.38 €/kWh → that’s expensive over a year So, I've built a low-power N100 box at ~12 W idle to host all Dockers/VMs and be the “master” Idea: keep the array sleeping and only wake it with WOL + autofs/NFS when files are needed The problem: one wake ended up with a disabled/emulated disk and a full rebuild. That scared the hell out of me, and honestly I don’t trust S3 sleep anymore with this setup. So I’m thinking: instead of sleep, maybe just fully shutdown the array server when idle and WOL it when needed. Downside: boot time ~1–2 minutes, which is annoying. But this box does nothing except serve the array (no Dockers, no VMs). But the idea of waiting 2 minutes before I can start a movie or listen to a music album ain't nice... Question: is there a way to make Unraid boot in a really “lightweight” mode just for the array? Like, disable every unnecessary service/plugin so the boot + array mount is as fast as possible? Has anyone here tuned Unraid this way? Or, is anyone here actually happy and safely using S3 using a great pre-sleep script ?

Done. Thanks !

OK you were right, the server started, all disks are detected, all plugins are running ! but the array wont start as I already had a usb key failure a few months ago and transferred it to the "new" one that failed as well. So I guess I made too much key transfers in less than a year : what now ?

ok well, I am copying the "CONFIG" (upper case) folder I got back from my previous key back to the newly flashed one. I'll try a reboot in a few seconds. fingers...and toes...