Hello there!
Long time user, Unraid's been fine most of the time but I've got my notable share of issues here and there. Still, I could solve them trying things, managing problem solving and reading threads here or in Reddit.
Now I've stumbled upon something that's been persistent and does not want me to manage it, though!

For several days now, one of my HDDs is always being read and written by something, by I can't for the life of me identify what it is.
It's not only some kb/s here and there, most of the time it is at 20~50MB/s, but sometimes it goes up to 150 or 220 for a few minutes, and back then back to the previous.
Parity disk seems to being read and written as well, constantly, and of course if I try to stop the array or shutdown the system, it takes several minutes, I'm talking perfectly in the range of 15 to 25 or more. Rebooting seems to be doing an unclean shutdown too.

I've upgraded the array with 1 more HDD and added as well one more NVMe and 2 SATA SSDs, so now I have a new config regarding some shares and how I manage appdata, etc. But this has not happened right after I've done this, it was working just perfectly for several days, until it started behaving like this when I continued with some cleanup and configurations (I explain what may have caused it a bit below).

I've tried uninstalling my most recent dockers and plugins (folder view+, and netdata, in an attempt to see what process is doing it, with no luck), disabling docker entirely, letting it do a complete parity check, starting the array in maintenance mode to restart without anything using the hard disk, and whatever I could think of, but I come empty handed everytime, the dreaded unstoppable read and write persists.

At first I thought the disk was damaged, as a parity check with the array mounted was only at about 68-70MB/s... because something was still reading and writing, of course. But a parity check in maintenance mode let it go to maximum speed no problem.

But of course, anything that needs to use that HDD now goes on forever. If it even starts. As it is being used by something else infinitely.



My suspect is ZFS Master and the scripts for backing snapshots with Sanoid. As I changed my config recently, I had to move where files and shares were located; when everything was done, I let the system be to see if there were any problems (nothing apparently), and several days after I run the scripts to create the new replication of the datasets.
Problem 1 is that these replications took forever; I get that one of them (music dataset) is almost 2TB, but still it was doing it for more than 8 or 10 hours, maybe more, and it wasn't finished yet. That is insane.
Problem 2 is that ZFS Master doesn't let me delete most of the old datasets in the HDD dedicated to backups. So the HDD is at 75% and I cant free most of the space, while its usage keeps growing.
And that's the HDD that's being assaulted day and night, you guessed right.

Maybe the proble lies in that I stopped the script mid operation, and somehow it is still trying to make the backup somehow, or that ZFS/Sanoid is gone crazy and it's trying to complete it but can't because it's stopped, and is constantly reading and writting without knowing what to do?
Pure speculation, but I can't think of anything else at this point.

Is there any way of visualizing what apps or processes are causing this? What Unraid is doing "under the shadows"? What exactly is being written and read? Just something that tells me exactly "this are the background processes occurring right now, and this one is reading/writing in this HDD/share".
I've tried System Log, Processes, Active Streams, File Activity, Glances, Netdata... but either nothing showed up, or everything was shown in a way that did not solved it whatsoever :(


I'm at a loss, my only idea left is to erase ZFS Master, delete Sanoid, try to erase the deranged datasets then, and hope that a reinstall of ZFS Master/Sanoid sanitizes the system. But then my SSDs shares wouldn't be protected, and it scares me. Is that my only option?

Any help would be welcome. I've attached my system diagnosis en case it could be of any use.
Many, many thanks in advance!

unraid-diagnostics-20260617-2208.zip

You can try using iotop to see which process are causing the io activity.

Thanks JorgeB, I'll try to install iotop and see how it works.
But lo-and-behold, I think I found the culprit just before going to bed yesterday: it seems there was an unsolicited scrubbing process going on my HDD, and it was taking forever. Stopping it seemed to do the trick, I'll see if it continues to behave by the time being.

Now I just need to figure out how to delete old datasets occupying precious space that for some reason ZFS isn't letting me to destroy, and why one or twice a week a duplicate of the "media" share but named "Media", with capital M, appears suddenly.

If the issue with the HDD doesn't revert back in a couple days, I'll come back and mark this one as solved.

19 minutes ago, MagickPistacho said:

I'll try to install iotop

It already comes with Unraid, at least from 7.3.0, don't remeber when it was added.

1 hour ago, MagickPistacho said:

why one or twice a week a duplicate of the "media" share but named "Media", with capital M, appears suddenly.

You must have specified a path to /mnt/user/Media (or possibly /mnt/disk#/Media or /mnt/poolname/Media) somewhere, probably a container host path.

3 hours ago, JorgeB said:

It already comes with Unraid, at least from 7.3.0, don't remeber when it was added.

Oh, neat!
There's so much going on at the same time, tough, and much of it does not have a clear indicator of what started it or what exactly is it doing, but it's great to be able to see jellyfin, navidrome and other docker or apps processes stated and sorted. Thanks!

1 hour ago, trurl said:

You must have specified a path to /mnt/user/Media (or possibly /mnt/disk#/Media or /mnt/poolname/Media) somewhere, probably a container host path.

That's what I thought too, yeah.
I found one a long time ago, changed it but did not solve the issue, must be somewhere else. I've been looking in every docker and app for this, with no luck.
I'll try to look more carefully, and see if there's some clue in the diagnostics files. Thanks for your reply too!

Is anything being stored in Media when it gets created?

Another possibility is you have a mapping to /mnt/user (or /mnt/disk# or /mnt/poolname) and you have the application storing something in Media using that mapping.

2 hours ago, trurl said:

Is anything being stored in Media when it gets created?

Nope, it's empty as a void, just existing.
But I think some files started to transfer there instead of media by mover a while back, when I didn't notice it was created.

2 hours ago, trurl said:

Another possibility is you have a mapping to /mnt/user (or /mnt/disk# or /mnt/poolname) and you have the application storing something in Media using that mapping.

Hmmmm, how could I check that? Not sure I get it all, or what should be the correct mapping.

Do any of your containers have a host mapping at the top level of user shares or a disk or pool?

2 hours ago, trurl said:

a mapping to /mnt/user (or /mnt/disk# or /mnt/poolname)

Any folder created at the top level is automatically a user share named for the folder. If an application creates a folder at the top level it is creating a user share.

Scripts and plugins could also have a path with the capitalized Media in it, so container host mappings aren't the only possibility.

Thanks again for your answers, trurl.

If I'm understanding this correctly, while there are several dockers with paths mapped that way, yes:



but only Jellyfin seems to be configured as a host, as in the network level:



Should I change it to something like /data/whateverthefolder, or are they fine as it is?

Nonetheless, any docker path with mnt/user or mnt/poolname for the media share are "media", lower case, none of them "Media".
There was one, a long time ago (I it was a path in Rmlint or Navidrome), I changed it thinking that would solve the situation, buuuut it changed nothing.

I've searched on scripts as well, and nothing, and same with plugins. I'll take a further look in those, in case I've missed something.

13 minutes ago, MagickPistacho said:

only Jellyfin seems to be configured as a host

That has nothing to do with path mappings.

14 minutes ago, MagickPistacho said:

Should I change it to something like /data/whateverthefolder

Change what? Typically you don't change container paths, since those are the paths the application expects to use. The host paths are how those container paths correspond to Unraid storage.

23 hours ago, trurl said:

That has nothing to do with path mappings.

Good to know then.
How do I know if a container has a host mapping at the top level then? Does that mean, basically, "if any container has a mapping to the root/name of a share"?

23 hours ago, trurl said:

Change what? Typically you don't change container paths, since those are the paths the application expects to use. The host paths are how those container paths correspond to Unraid storage.

Perfect! That was my understanding and always left them as they come, but I was getting doubts with this after all we were talking about.

On 6/20/2026 at 11:06 AM, MagickPistacho said:

How do I know if a container has a host mapping at the top level then? Does that mean, basically, "if any container has a mapping to the root/name of a share"?

If any container has a mapping to /mnt/user (or /mnt/disk# or /mnt/poolname), and it creates a folder there, that folder is automatically a user share named for the folder.

User shares are the combined top level folders of array disks and pools.

If you create a user share in the webUI, Unraid creates top level folder(s) named for the share on array and/or pools as needed in conformance with settings made for the share.

Conversely, if you create a top level folder on array or pools, it is automatically a user share named for the folder. This will also happen if you create a folder in /mnt/user, the top level of user shares.

If you have a user share named "media", it is at /mnt/user/media. If something references a path at /mnt/user/Media, it is a different user share named "Media". Container mappings are a common way to accidentally create a user share, but anything that creates a folder in /mnt/user (or /mnt/disk# or /mnt/poolname) is creating a user share.

Right, so if the mapping is something like, let's say for example: "/mnt/user/media/blablabla", it wouldn't create anything at the top level, as it is at a "lower level" than /user - /disk# -/poolname, correct?

Anyway, I think I've found the culprit and it may well be the first suspect: ZFS Master and/or Sanoid. Until now each week (usually sunday and/or monday) that Media share would be created, but did not happen this time, finally.
I think it had to do with an old snapshot that was pointing to something in Media instead of media, and now that I've cleaned most of the old snapshots because I've rearranged pools, it seems it no longer does it.

I'll mark this as solved in a couple of days, see if everything is working fine and it does not start again.
Thanks a lot for your time, JorgeB and trurl!