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

Edited April 17Apr 17 by meaning
format

Great, this is exactly what i was looking for!

Just a couple things to report from right after installing:

1. I have the unraid light theme, it's hard to read the SPIN ALL UP and SPIN ALL DOWN buttons text

2. The page shows a Collector error message at the very top - did I miss something during installation?

12 hours ago, Sephibro said:

Great, this is exactly what i was looking for!

Just a couple things to report from right after installing:

1. I have the unraid light theme, it's hard to read the SPIN ALL UP and SPIN ALL DOWN buttons text

2. The page shows a Collector error message at the very top - did I miss something during installation?

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

Another issue: the Main Usage Sources and Array Spin-Up Timeline panels seem to be higher than the parent - it is noticeable also in the screenshot you attached to your first post

1 hour ago, Sephibro said:

Another issue: the Main Usage Sources and Array Spin-Up Timeline panels seem to be higher than the parent - it is noticeable also in the screenshot you attached to your first post

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 ;)

Perfect!

Thanks again for your effort

I would have one request: right now the Daily History panel actually shows daily statistics. If possible, I would like to have history information, something like a table that shows spin-up time | spin-up duration | service that caused the spin-up | file(s) accessed at the time of spin-up

3 hours ago, Sephibro said:

I would have one request: right now the Daily History panel actually shows daily statistics. If possible, I would like to have history information, something like a table that shows spin-up time | spin-up duration | service that caused the spin-up | file(s) accessed at the time of spin-up

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

Content wise that's perfect.

(minor) For compatibility: in light theme, both the table and the text are the same white color.

Thank you!

20 hours ago, Sephibro said:

inor) For compatibility: in light theme, both the table and the text are the same white color.

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

I have a couple of these:

/mnt/user/appdata/app123 → /config

pool-only share · Share appdata is pool-only on ssd, but the app still goes through /mnt/user.

This is not a problem anymore (for me at least, I always use /mnt/user) with exclusive access/shares (6.12+).

Edited April 20Apr 20 by Niklas

9 hours ago, Niklas said:

I have a couple of these:

/mnt/user/appdata/app123 → /config

pool-only share · Share appdata is pool-only on ssd, but the app still goes through /mnt/user.

This is not a problem anymore (for me at least, I always use /mnt/user) with exclusive access/shares (6.12+).

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 have one issue to report:

• A week ago, my server got stuck and I had to hard reset it

• When it turned back on, Disk Talkers looked like this
  

• I uninstalled and re-installed Disk Talkers, and it fixed the problem

• Today I did a normal reboot from the Unraid GUI and when it turned on, I had again the same issue as shown in the picture above

Edited April 26Apr 26 by Sephibro

14 minutes ago, Sephibro said:

I have one issue to report:

• A week ago, my server got stuck and I had to hard reset it

• When it turned back on, Disk Talkers looked like this

• I uninstalled and re-installed Disk Talkers, and it fixed the problem

• Today I did a normal reboot from the Unraid GUI and when it turned on, I had again the same issue as shown in the picture above

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 ;)

It's a bit cpu intensive, yes?

22 hours ago, Niklas said:

It's a bit cpu intensive, yes?

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.

Hello,

after a few minutes I get the error:

fanotify unavailable: [Errno 2] No such file or directory

so I often have only "other activity" in the statistic and cannot identify my problem.

Mike

29 minutes ago, mmm77 said:

Hello,

after a few minutes I get the error:

fanotify unavailable: [Errno 2] No such file or directory

so I often have only "other activity" in the statistic and cannot identify my problem.

Mike

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 ! :)

HI and thanks,

error has gone, but does not help to identify my apps.

Mike

21 hours ago, mmm77 said:

HI and thanks,

error has gone, but does not help to identify my apps.

Mike

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.

Hi, took a while

unraid: 7.3.1

all apps use /mnt/user/...

also some screenshots what I can see..

Mike

state.json syslog.txt

Just noticed this plugin. Some comments:

On 4/16/2026 at 8:13 AM, meaning said:

Sometimes it is a container using /mnt/user/... instead of a direct cache or pool path

This is fine (and even recommended) if the user share is exclusive to a pool. No need to map containers directly to cache or pool.

Probably the most common cause of array disks not spinning down is Docker/VM related shares - appdata, domains, system - with files on the array. Better if these shares are all on cache or other pool since these files are always open. Nothing can move open files so you have to disable Docker and VM Manager in Settings before these shares can be moved.

@mmm77

Are you sure this isn't the cause?

5 minutes ago, trurl said:

Docker/VM related shares - appdata, domains, system - with files on the array

@mmm77 thanks a lot for the state.json — that was really helpful.

Good news first: from your dump, the live attribution is actually working — your active pools do map to the right containers (iobroker, plex, emby, radarr, FileFlows…). So the collector itself is doing its job.

I think I found what's breaking the history view on your setup. Because each of your shares is its own ZFS dataset (/mnt/disk4/medien, /mnt/ssd/appdata…), the plugin was recording disk activity against the dataset instead of the underlying array disk, so your spin-up history ended up almost entirely "Unattributed". Your disk list was also getting flooded by Docker overlay and rclone mounts showing up as fake "pools".

I've pushed 2026.06.10a that should address both: activity is now attributed to the real disk/pool (while still watching the datasets so nothing is missed), and the overlay/rclone clutter is filtered out.

Full disclosure though — I don't have a ZFS-per-dataset server to test on myself, so I've only been able to verify this against your dump and on a non-ZFS box. I'd really appreciate it if you could update, hard-refresh the page, and let it run for a bit, then tell me whether new spin-ups start getting named and whether the disk list looks cleaner. Existing "Unattributed" history rows won't be backfilled — it's the new samples that matter. If it's still off, send me a fresh state.json and I'll keep digging.

@turl thanks for chiming in — you're absolutely right that appdata/domains/system on the array is the classic spin-down cause in general. In this particular case it looks more like a plugin-side attribution bug with ZFS dataset layouts than a misconfiguration on Mike's end, but your point stands for the broader "why won't my disks spin down" question.

Hi, yes now it seems to work, still some unattributed activity.

So I now tryed to move all .plexignore to cache...... that´s why (deleted) ...screenshot was afterwards

Mike

Edited June 12Jun 12 by mmm77