Here is the link to the old version for those of you who want to roll back while I'm working out the new bugs. http://raw.githubusercontent.com/strike84/unraid-disk.space.management/refs/heads/main/DiskSpaceManagement-2025-11-08.plg

You'll need to set up your paths again if you decide to roll back. A new dev version will be posted very soon. And since I'm unable to reproduce your issues (except for @rgreen83 's issue) I need you to test it for me to confirm if it's working or not.

8 hours ago, strike said:

@unabletoconnect @poto2 Which version did you get the error? I posted a link to a dev version, is it that one?

"broken pipe" errors with both "new" versions

Rolled back to 2025-11-08 = no error

I've pushed an update to the dev version now: https://raw.githubusercontent.com/strike84/unraid-disk.space.management/refs/heads/main/DiskSpaceManagement-dev.plg

If you rolled back to the 2025-11-08 version, please back up your settings.cfg file in /boot/config/plugins/DiskSpaceManagement/ so that if you need to roll back to the old version again, you can copy that file back so you don't need to set up your settings again.

@unabletoconnect @poto2 Please test the new dev version when you're able to, and tell me if the issues are fixed (should be).

@rgreen83 Your issue should be fixed as well. I've tested it on both the grey and azure themes. I've also added a "stop script" button on the log tab.

@Crimzon and anyone else with the "smashed screen" display issue. Please confirm if it's fixed now.

No further "broken pipe" errors with latest dev version. Thanks for the quick turnaround! 👍

Still having issues with the new version, the broken pipe error is gone however it seems to be stuck on the first file, and is reporting the file is 0GB. I've checked the file and it is multiple GB, and no drives are reporting activity while the script is running.

Rolling back to 2025-11-08 restores functionality with file sizes reported, and disk activity.

6 hours ago, unabletoconnect said:

Still having issues with the new version, the broken pipe error is gone however it seems to be stuck on the first file, and is reporting the file is 0GB. I've checked the file and it is multiple GB, and no drives are reporting activity while the script is running.

Rolling back to 2025-11-08 restores functionality with file sizes reported, and disk activity.

Thanks for reporting. I'll post an updated dev version later today.

@unabletoconnect I've looked at this, and it could be that the file was in use/locked by another process, and when that happens, the script returns the size as 0. It tries to move the file, but fails. Since the file wasn't moved, the disk space hasn't changed. The script finds the same "best" file again, causing an infinite loop. I'll have to do some more testing tomorrow before I post a new dev version. Thanks for helping me test, btw it's much appreciated!

Sorry for the delay, I was OOP.

Still having the issues with the latest release. My screen is on a laptop with a 1920x1200 landscape display.

It appears that the control fields are not properly sized, or not initialized properly. You can see the slider for the log text field and the text is being wrapped in the very narrow display field.

I provided a full page capture of the log, about, and settings pages, for your reference. Notice that most of your new controls on the setting page look fine except for the shared dry run control.

16 minutes ago, Crimzon said:

Sorry for the delay, I was OOP.

Still having the issues with the latest release. My screen is on a laptop with a 1920x1200 landscape display.

It appears that the control fields are not properly sized, or not initialized properly. You can see the slider for the log text field and the text is being wrapped in the very narrow display field.

I provided a full page capture of the log, about, and settings pages, for your reference. Notice that most of your new controls on the setting page look fine except for the shared dry run control.

Thanks for the screenshots. I notice you are on the version from 2025.12.31-3. Can you try the latest dev version I posted a few posts back? My plan was to continue to work on the dev version tonight, but my VM started having weird issues that I have to fix first. But most likely there will be a new dev version out in the weekend, just have to fix my VM first. I would really like to know if your display issues still are presented in the current dev version though.

1 hour ago, strike said:

Thanks for the screenshots. I notice you are on the version from 2025.12.31-3. Can you try the latest dev version I posted a few posts back? My plan was to continue to work on the dev version tonight, but my VM started having weird issues that I have to fix first. But most likely there will be a new dev version out in the weekend, just have to fix my VM first. I would really like to know if your display issues still are presented in the current dev version though.

Your dev release didn't fix the problem but it did affect it.

I still cannot enable/disable the Trial mode and the text scroll boxes are still pretty narrow, but they are wider than they were previously. This is behavior is consistent on the log, changelog, and about panels.

5 minutes ago, Crimzon said:

Your dev release didn't fix the problem but it did affect it.

I still cannot enable/disable the Trial mode and the text scroll boxes are still pretty narrow, but they are wider than they were previously. This is behavior is consistent on the log, changelog, and about panels.

Thanks. I was working under the assumption that you were on a narrow screen like a phone, so I set a min width for the boxes, which seems to have worked. But it seems that somehow your screen/laptop is triggering the "mobile" view. I don't have that many screens to test with, but now that I know that you're on a laptop, I can see if I can reproduce it on my laptop, since I'm unable to reproduce it on my TV and phone. I totally forgot that I even have a laptop (I never use it, I like my 85" tv better..)

I'll be back with a new dev version probably tomorrow. I just fixed @unabletoconnect 's issue at least. So we're getting close to a bug-free release pretty soon, I hope. :)

New dev version, which I hope will solve the remaining bugs: https://raw.githubusercontent.com/strike84/unraid-disk.space.management/refs/heads/main/DiskSpaceManagement-dev.plg Please give it a try :)

@Crimzon I was unable to reproduce the issue on my laptop as well, but I believe it's because I'm on Unraid version 7.2.3 and you're on 7.1.4. And my plugins UI is designed for 7.2+ But I made some adjustments in the latest dev version that I hope will solve the issue. If not, it may be worth upgrading to the latest stable Unraid release. It's pretty stable now, so I would consider upgrading anyway.

@unabletoconnect I also added a "fix" for the infinite loop; it now skips this folder and logs it. If you're seeing the same folder skipped in the logs, run after run, it may be because sometimes rsync leaves behind empty folders on the source disk after the move is done. I've added a fix for this as well, so it cleans up the folders if left behind. But you need to delete these folders yourself if it's already happened to you in an earlier run. After that is done, the folder will not show up in the logs anymore.

Edit: I also pushed the update to the main version so that you can update the normal way.

Edited January 10Jan 10 by strike

Everything has been working great for me the past couple days with the latest dev version. I would only request one tiny change/addition, could we get a way to turn the cron schedule on or off, or a note what to put in the field, if we just want to run manually?

1 hour ago, rgreen83 said:

Everything has been working great for me the past couple days with the latest dev version. I would only request one tiny change/addition, could we get a way to turn the cron schedule on or off, or a note what to put in the field, if we just want to run manually?

Thanks for the feedback. You can enter "disabled" without quotes in the cron schedule, and it's already a note about it in the help & info section :)

On 1/13/2026 at 4:15 AM, strike said:

Thanks for the feedback. You can enter "disabled" without quotes in the cron schedule, and it's already a note about it in the help & info section :)

oh wow i totally missed that. its a little less than ideal that you have to lose your cron schedule to turn scheduled runs off perhaps temporarily but thats a very minor thing. the plugin continues to run well. I've been trying to survive with an extremely full array due to the high prices of hard drives recently and your script has made that much easier!

7 minutes ago, rgreen83 said:

oh wow i totally missed that. its a little less than ideal that you have to lose your cron schedule to turn scheduled runs off perhaps temporarily but thats a very minor thing. the plugin continues to run well. I've been trying to survive with an extremely full array due to the high prices of hard drives recently and your script has made that much easier!

Good catch. I'll change that in the next update. Maybe a drop down to enable yes/no and if yes the text field appears, and don't delete it if set to no again.

I'm glad you find it useful. I have 17 almost full drives myself, so it makes it much easier for me to manage as well. I was getting pretty fed up with moving things manually every day. I could of course make unraid split everything as needed, but I don't want that as I have to satisfy my (mild) OCD. Haha..

BTW if you're still on the dev version you can uninstall that and install from CA again, otherwise you won't see the update when it's ready.

I just noticed there is a smallest first option but no largest first, while the other options have each counterpart. I think I would actually like to use largest first if you could add that at some point please.

Also I am noticing something that might be an issue. So if I have a disk with 500gb free and I have set the plugin to free up to 1tb, it will see that the disk needs some files moved, but then it seems like it runs into a lot of files that it has to skip for whatever reason and then it just continues on and leaves that disk under the free space goal. I assume it is deciding on the files it wants to move, sees it can't, and never goes back to choose other files. That of course should take care of itself long term but it seems to return to the same files every run so the problem actually is building up and getting worse with each run as it can move less and less files each run.

This plugin continues to be awesome! I haven't found a support link anywhere, could you add one or at least share one here?

edit So I may have while typing up this comment just found why that is happening specifically for me as well which might also be something correctable. I have "smallest first" set on my torrent downloads folder, and im seeing that most of the folders that it is trying to move and skipping are placeholders for downloads in queue. I do not have pre-allocate enabled so there is no actual file but the folder is there and a 0kb empty .nfo.

Also just noticed another set of files doing the same thing except this one is actually very large over the share, but the disk that it wants to move the file from has only a very tiny 3kb sfv file. It seems that even though the whole huge file over the share has completed downloaded, it being shared keeps any of the files from being movable by this plugin. That is likely fine, but it does make me wish for a "largest first" option even more and to ensure that it doesn't skip the rest of the disk when it's planned files are inaccessible.

Edited February 22Feb 22 by rgreen83

7 minutes ago, rgreen83 said:

I just noticed there is a smallest first option but no largest first, while the other options have each counterpart. I think I would actually like to use largest first if you could add that at some point please.

Yeah, I've been thinking of adding that for some time. Just haven't got around to it. Initially, this plugin was created to just keep drives from becoming full and keep it just above that line. The goal was never to move a large amount of data, but the plugin has later evolved, so it makes sense to add. While it was not designed for that purpose initially, it can be used to empty drives or rebalance the array and move the files to other drives.

Always feel free to post feature requests or other ways the plugin can be improved on. It keeps me motivated to actually work on it. The reason why I haven't added it yet was that there was really no request for it, and there have been no more bug reports, so I've prioritized other things instead. But yeah, keep an eye out for the next update, and it will be added. :)

35 minutes ago, rgreen83 said:

Also I am noticing something that might be an issue. So if I have a disk with 500gb free and I have set the plugin to free up to 1tb, it will see that the disk needs some files moved, but then it seems like it runs into a lot of files that it has to skip for whatever reason and then it just continues on and leaves that disk under the free space goal. I assume it is deciding on the files it wants to move, sees it can't, and never goes back to choose other files. That of course should take care of itself long term but it seems to return to the same files every run so the problem actually is building up and getting worse with each run as it can move less and less files each run.

That's interesting. I haven't really tested it on moving large amount of data, as I mentioned it was not initially designed for that. But are you sure that the folders that are skipped actually have files in them? A side effect of using the remove source files command the script uses is that it sometimes leaves empty folders behind. And in earlier versions, there was no cleanup done to mitigate that. So you might have folders that are already moved, but have empty folders in the source disk. If the script is unable to determine the size of the folder/files (like when it's empty) it assumes it's either locked/in use or empty and will skip it.

I'll take a look at it, but please check the folders that are skipped if they actually have files in them. If not, delete them manually, and they will stop appearing in the log. I've seen the issue myself a few times, but it has always been empty folders left behind from earlier moves.

But it also sounds like it could be a bug if you have confirmed that it leaves the disk under the free space threshold. Sounds like it's maybe related to the empty folder issue somehow, and it messes up the calculations. IIRC I think I saw the same thing the few times this has happened in my runs, but I use it on a threshold of 60 GB and only move the smallest folders first, so I didn't think much about it when it was a few GB off. On big moves, this will of course add up. But for now, until it's fixed, I think the workaround is to make sure to delete empty folders if they appear in the log, as this is probably the cause of the wrong calculations, somehow.

51 minutes ago, rgreen83 said:

This plugin continues to be awesome! I haven't found a support link anywhere, could you add one or at least share one here?

I'm really happy you like it. This is the right place to ask for support. Or did you mean like a "buy me a beer" link? I'll think about it :)

Edited February 20Feb 20 by strike

@rgreen83 I was able to reproduce the issue, and I've fixed it. And it was related to the empty folder issue. Whenever it encounters an empty folder, it skips it, but instead of moving on to the next item in that path, it skips to the next managed path, leaving the disk under the free space threshold.

I'll push an update in the next few hours, including the fix and the largest first sorting option. I just have to test that there are no regressions first.

wow thank you for the quick update! and yes i meant like a buy you a beer link! I know there are other options like unBalanced plugin but iirc that is a manual option and not ongoing regular space floor maintenance? I just prefer this plugin honestly.

As for the disk skipping issue, i have checked and there are some tiny files in those specific paths i mentioned. I have all of my automated processes set to cleanup empty folders so those shouldn't really be around. I took a log screenshot that shows the behavior im seeing that seems incorrect, if you notice there is no "Disk 4 is above threshold" message before it moves on to Disk 5 despite Disk 4 being nearly 250GB below the threshold.

@strike Trying to understand a little better how the script works. So the free space of the disk as a whole is used to determine if files need moved, that seems pretty straight forward. Next lets assume the sorting order is largest first, does it select a folder with the largest FILE within and move that whole folder, or does it select the largest FOLDER e.g. the folder with the largest collection of any size files? Then next regardless how it selects the folder, it seems the script moves that whole folder start to finish? That part has surprised me, I assumed it was moving the largest files one at a time not entire folders start to finish, and I honestly wish it was file by file instead of doing the whole folder - could that be configurable? Please correct my misunderstandings.

22 hours ago, rgreen83 said:

@strike Trying to understand a little better how the script works. So the free space of the disk as a whole is used to determine if files need moved, that seems pretty straight forward. Next lets assume the sorting order is largest first, does it select a folder with the largest FILE within and move that whole folder, or does it select the largest FOLDER e.g. the folder with the largest collection of any size files? Then next regardless how it selects the folder, it seems the script moves that whole folder start to finish? That part has surprised me, I assumed it was moving the largest files one at a time not entire folders start to finish, and I honestly wish it was file by file instead of doing the whole folder - could that be configurable? Please correct my misunderstandings.

It selects the largest FOLDER, and you're correct, it moves the whole folder. The script was originally meant to only move media files, like movies and tv shows. And my logic then was that the whole folder should be moved. Who would want only parts of a movie folder/season of a show moved..(?). :) That might leave files related to the movie/show on different disks. And the whole point of the script was to free up space on almost full disks, but still keep files that were supposed to be together (based on split-level) in the same folder.

I still feel like that's the correct way to do it, move the entire folder.

Could you describe your use case for me? I could probably figure something out to support what you want. But your files could then (potentially) end up on different disks. Are you ok with that? E.g it moves the biggest file in a folder (file A) to a new disk, that source disk is over the threshold when moved and stops, BUT a new disk is now the next in line to be selected based on free space, and the next biggest file in the source folder (file B) will get moved to that disk, leaving you with file A in disk2 and file B on disk3. Continuing down that path could leave you with all the files in that folder spread across your entire array.

This is something I feel that most people would not want.

Use case is simply drives get full and I am trying to let this tool move stuff to more recently added drives to spread the "load" out across more empty drives. Many of the media sets/folders I have run 1-2TB (ripped bluray) in size but generally individual files would be 10GB or less. I run unraid because I like whole files per disk instead of striped so they can be easily recovered/moved/etc without rebuilding a raid array, but I have no need for the whole media set to be on a single drive since media should be interacted with via shares/logical structure not via direct disk. I think performance is likely better if files are actually stored on multiple drives wouldn't it? I think that is what I had in mind for a largest first sorting order, take the largest folders and spread them out more evenly. I'm not sure why it would be important to keep all files for a show on a single disk, but of course I understand many have different priorities and I'm just not familiar with that use case. Image attached of my current drive status for example.

I just noticed when I have a drive with say 500GB free the plugin (set to 1TB free goal) would go to work on the largest folder which might be 1TB and it will just toil away on that for 2 days trying to move the entire 1TB folder to a new disk so when it is complete that source drive now has 1.5TB free. That's fine to have extra free space, just wanted to make sure that what I was seeing is expected. My server is highly utilized for many things and my disks never idle so I care a lot more about performance than power savings. All of my shared run high water allocation and automatically split any level directory. Most of my array storage is for ripping bluray, then I use tools to mux those to mkv to watch via plex, for TV shows I usually up reencoding to AV1 because the production quality just doesn't justify the huge storage, so there is a lot going on.

Primarily I just wanted to make sure I was understanding how the script is supposed to work and that it matches what I was seeing. I am not expecting you to change its functionality to fit only my use case, it seems I might be the minority anyway, but I wanted to share how I use my server and your tool since you asked. In any case, again thank you for the tool, it is greatly helpful already!

Edited March 25Mar 25 by rgreen83

@rgreen83 I understand.

20 hours ago, rgreen83 said:

I think performance is likely better if files are actually stored on multiple drives wouldn't it?

No, the performance is still the same, limited to the single disk performance.

20 hours ago, rgreen83 said:

I think that is what I had in mind for a largest first sorting order, take the largest folders and spread them out more evenly.

Ok. I'm not sure why you would want that tho. But that's just me not understanding why this would be important.

20 hours ago, rgreen83 said:

I'm not sure why it would be important to keep all files for a show on a single disk, but of course I understand many have different priorities and I'm just not familiar with that use case.

Why this is important for many is that it will limit how many disks spin up. If you have a show on one disk, it will only spin up one disk, which will save a lot of power in the long run. That, and many (like me) have mild OCD we have to satisfy to keep things organized "the right way."

20 hours ago, rgreen83 said:

I just noticed when I have a drive with say 500GB free the plugin (set to 1TB free goal) would go to work on the largest folder which might be 1TB and it will just toil away on that for 2 days trying to move the entire 1TB folder to a new disk so when it is complete that source drive now has 1.5TB free. That's fine to have extra free space, just wanted to make sure that what I was seeing is expected.

Yeah, when moving the largest first, this is expected. I would recommend using the smallest first. This will always keep the disks just above the threshold, so it won't overshoot by 500GB like in your example. If your disk is at 500GB, and your threshold is 1TB, it will move at least 500GB. And moving 500GB (or any size) will take the same amount of time regardless of sorting order. Only the smallest first option is guaranteed to hit the threshold goal the closest, every time. All of the other ones have the risk of overshooting and thus taking a longer time to move.

But I'll take a look at your use case when I have the time, to see if I can make something happen. :) It was an interesting one. I'm not promising anything tho. And looking at your screenshot, I see you have a different definition of "full" than what I have.. :P

Hey,

updated to 7.3.0-Beta1, and swapped over to internal boot.

I now get a AJAX error when attempting to save settings. Would i be right in that this might be caused by the config file now been located in a new location?

I've been able to make the config changes by manually editing the .cfg, so no rush with investigation - more of a FYI.