strike

Don't take my word for it, but I think it just means that you haven't linked your key to your account yet. You can link your key(s) to your unraid account so that if you ever need to retrieve them, you can just download them. E.g, If your local/backup key gets lost. But then again, the wording and the big read banner suggest it's mandatory for some operations now? Edit: Sorry, I didn't see your previous post with the errors.

Will do. I had something similar going with a script pulling from trakt.tv top lists. But to be honest, I got a lot of crap, as mine didn't have all the filtering options you have. And I haven't really been motivated to work on/fix my script. But now I don't have to, as I suspect yours will be working much better. :) I just have to write a simple script to delete all my crappy movies with a score under 6.5 now, I won't be doing that work manually, that's for sure... :P

Awesome, much appreciated!

That sounds like exactly what I want, yes :)

I'm looking at the filter options. Is it possible to reject a genre if it's only that genre, but grab it if it contains one or more other genres? E.g., I hate horror movies as they tend to be crap, but I can like them if they're part of another genre, like the Alien series, which is a horror/sci-fi movie. But, straight out horror movies, I want to reject.

This looks interesting, following. Thanks for bringing it to us :)

Thanks. So your vpn tunnel is not connecting, and there are a few things here, you have this repeating in your log: 2026-05-14 15:38:46,957 DEBG 'start-script' stdout output: 2026-05-14 15:38:46 SIGHUP[soft,ping-restart] received, process restartingSee Q17 here: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md You also have this in your log: [warn] Password contains characters which could cause authentication issues, please consider changing this if possibleMake sure the password is only a-z (upper or lower case),0-9, and not more than 99 characters long.

Working fine here. Please do this: https://github.com/binhex/documentation/blob/master/docker/faq/help.md

It gets stored in the docker.img file. I would delete the container and select to delete the image (the container image, not docker.img) as well, then reinstall with the correct volumes. If you already did this, then you're good.

No problem :)

Here you go: https://forums.unraid.net/topic/147455-support-unifi-controller-unifi-unraid-reborn/page/36/#findComment-1610887 You need to install Debian first, of course.

Works great for me. But then again, I'm only using it for my access points and my switch, so I can't comment on other functionality. It was easy to install, just followed @PeteAsking directions earlier in the thread.

So I assume this means that all of these fixes are included in the 7.3 beta 2 rc-1?

@bmartino1 @PeteAsking Thanks, appreciate your inputs. Honestly, I only use it for my access points at home, so I rarely need to access it unless it's for an update. I prefer docker, but I guess I could spin up a VM too. If it's like the network application where you don't need to have it running all the time, I guess a VM would do fine. Just turn it on when I need to update and leave it off when I don't need it. If my wifi works, I'm happy, all other network-related things are done on my pfsense box.

So, is there any consensus yet on the best way to deploy the unifi os server? VM or the docker container maintained by @bmartino1 ? I'm looking to take the plunge soon, but I haven't decided what to go for.

Aaah, yes, now I understand what you're saying. And yes, I do know about this rsync issue. I wish they would change that, but I guess it will remain that way, a wish.. But also, most people starting out with a server don't have this problem, as they will fill up the server naturally. But you also have those that already have lots of data they want to move to their server, and using rsync will see this issue.

Sorry, I don't think I understand your reply. Split level does not care about how many disks you have. It simply set a rule that, e.g if the folder depth is two for that share, it should continue to write files to those that are depth 3 or higher, folder no matter what, but if the folder depth is two or less, it could write those files to other drives. So if you're saying that unraid keeps writing files to other disks that you want to stay in the same folder on the same disk, then your split level settings are wrong, and that's why it keeps writing to other drives. E.g my folder structure is /media/TV Shows/Show name/Season/s01e01.mkv My split level is set to "Automatically split only the top two directory levels as required". This means that it can split files at level two, which is /media/Tv Shows/. So each TV show can go to whichever disk (based on the allocation method), but if files come in that are level 3 or higher (media/Tv Shows/Show name), it will write them to the disk that already has this show.

That's how split-level works. Even if the user has planned the file structure well, split-level can and will try to move files to disks that are full, if the split level says the files should go to that disk. E.g: I want my tv shows to stay on the same disk. So all seasons and all episodes stay on the same disk. If that disk is nearly full, my split-level will still try to move new files to shows that exists on that disk and will fail because of no space left on the disk. So this plugin's job is to move folders from full disks to other disks, always keeping some free space left on almost full disks, so that if new episodes of a show are coming on that disk, it always has space for it. Now, that was the original purpose of the plugin. But it can also be used for other use cases, like to rebalance the array as the unbalance plugin does, it just does it a different way. Or it can be used to empty drives to other drives. No this plugin does not check or change your split-level settings. It will just move folders based on your settings in the plugin. But you're right, if I have this path set in the plugin /media/tv shows/ and I have selected to move the largest folder first, then yes, it will try to move the largest folder in the tv shows folder to a new drive. And with TV shows that could be hundreds of gigabytes. And if you have no drives with that much space left, it will fail to move it. But you don't have to move the largest folder, you can choose some of the other options e.g smallest. This plugin does not magically give you more total space. If all your disks are almost full, then you have a problem you can only solve by buying more drives.. Regarding the largest folder first moving option, I've added a check that checks if the target disk has the required space left, so it doesn't fail if it's too big. I was supposed to add that in a previous version anyway, but I forgot about it. It will then log a warning and tell you that it won't fit on the target disk, and tell you to change your folder sorting order or simply add more drives. It will then move on to the next configured folder in the plugin. With this plugin, you will not run out of space, yes, but it doesn't check or change your split-level settings. It does, and this is exactly what split-level is for. Just make sure you set the right split level based on your folder structure and where you want to split. My solution before this plugin was to move folders manually to other drives. I had to do this every day, and now this plugin does it for me. :)

@rgreen83 I thought about your suggestion and decided not to implement it. The reason is that it will, as mentioned, result in files going to different drives. Most people using this plugin would want the folders they're moving to stay on one drive and not be scattered (potentially) over the entire array. Even if I put a big red warning that this setting will do that, there's always someone who will use the setting by accident and not realize it. And fixing that "mistake" is going to take a lot of work to get the files back to where they're supposed to be. I felt like I owed you an explanation at least, as to why you won't be seeing this implemented.

This is fixed now, please pull down the new version. :)

Thanks for reporting. I haven't really had the time to update to the beta yet, so I can't confirm. But if the .cfg file is indeed in a different location, that would probably cause the error, yeah. Did you move it yourself, or does the internal boot option have a different directory structure? The .cfg file is saved in /boot/config/plugins/DiskSpaceManagement/ by default.

@rgreen83 I understand. No, the performance is still the same, limited to the single disk performance. Ok. I'm not sure why you would want that tho. But that's just me not understanding why this would be important. 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." 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

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.

Unraid staff have to answer this. But I know they're vetting the plugins before releasing them on the app store. If they do it manually or have some checks in place, I do not know. What happens when someone is releasing an update is a good question, I don't know if checks are in place or not. Did you merge your latest updates from the beta to the main plg btw?

Did you fill out the submission form and made a template for the plugin? If you have, you just have to wait. It can take some time. It took about 3-4 weeks when I submitted mine. And plugins gets extra scrutiny because they have access to the OS itself. Your plugin continues to work well 😊