FlamongOle

Is this still maintained, and will we see an Unraid 7.2 compatible version of it? The layout is a bit messy right now :P Love the plugin, it's useful!

@motoxnate To debug this further, you can always uninstall the plugin and see if it helps. Your config will remain. Also make sure you're not using "turbo write", because that will spin all the drives during write.

That cronjob (*/5) just looks at the syslog for devices when Unraid has read the SMART data, then Disk Location uses that info to read the SMART data as well within 5 minutes as the drives are already spinning. Otherwise it does never read SMART from devices in STANDBY mode.

It's at the very bottom of the page, if someone wonders. Poor location of that setting I think.

Nevermind, found it!

Where is my dark mode for the forum? The new theme is painful to watch and makes me blind, this is not OLED friendly at all.

Thanks! You can probably feed them the debug file on their forum as well:

Thanks for looking this up, it must also be a specific setting that causes this with Mover Tuning as I do use that plugin myself without issue. I see you already posted at CA Mover Tuning forum thread, hopefully we will get an answer and a fix soon. From my perspective it's absurdly strange, and don't even know why Mover Tuning would do this. Again, thanks a lot!

It's empty, that's good. The log is created in the memory even by default, so no need to change it. This problem MIGHT be related to, but I have no evidence and dunno how or why, and haven't been able to replicate it, I use that plugin myself, but maybe different settings... - it might even be unrelated:

I would also ask you to check if you see something in the PHP logs under Tools -> PHP Settings, anything related to Disk Location I would want. If you get the same results posted earlier here, then this is expected because of what did happen, and not why it happened.

You will not loose your configs be removing/reinstalling the plugin. Not by it's own default anyways. However, do you use the plugin "CA Mover Tuning"? I might suspect it to be a cause, but have not been able to reproduce the problem myself. But there is some bug reports about something similar with that plugin. Disk Location does not move files outside /tmp and /etc/cron by specific filenames, And those would not impact those issues at all. So, I can't imagine my plugin doing this, it makes no sense.

Works fine here, how's the layout configured? Any error message displayed?

Looks like this is related to the Mover Tuning plugin ye.. @StylishQuoter @seneo Read this, seems to be the/a cause: I use that plugin myself without issues (I think), but maybe just lucky with the file names or something. But I see absolutely no reason or possibility that this is caused by Disk Location.

Restarting the server will reinstall all plugins (that's what happens in the background during boot). Then I can close those issue as it's not related to the plugin. What did cause it, is still a mystery. Good luck. Hope it remains like this, otherwise You should really go through your server.

@seneo I have tried to replicate your issue as much as I can, using older benchmark migrating code etc. in various scenarios with and without benchmark folder, with and without contents. There's absolutely nothing that can cause this which is related to the plugin. The plugin does absolutely nothing in the /mnt folder, never did. At this point, there's nothing more I can do.

The errors are due to the files likely not existing in the correct locations, so those are of no use and expected results from your system. Both install and uninstall part of the script has been unchanged since Overhaul '25 release. All path's are very specific there as well, it will simply not be possible to install or delete files from different locations. Anyway, to delete manually but to preserve configs: #delete "pages" folder in your cache, please make sure this is the correct path, e.g. (this will not affect anything regarding the plugin whatsoever): #rm -rf /mnt/cache/pages #delete temporary storage: rm -rf /tmp/disklocation #delete web part of Disk Location: rm -rf /usr/local/emhttp/plugins/disklocation #delete Disk Location auto-crontab rm -rf /boot/config/plugins/disklocation-master #delete other Disk Location scripts in crontabs: rm /etc/cron.*/disklocation.sh #delete plugin related file: rm /usr/local/bin/smartlocate #delete plugin installer: rm /boot/config/plugins/disklocation/disklocation.*.zip rm /boot/config/plugins/disklocation-master.plg #update crontab to disregard Disk Location cron: /usr/local/sbin/update_cron

You can select how to read SMART data per disk or globally via Unraid settings, Disk Location should use those. Under Settings -> Disk Settings you can set them globally, like "HP cciss", this is also possible per device.

Update 2025.10.23 Commit #483 - IMPROVEMENT: Added an extra check to verify JSON check during benchmark migration, in case this is related to #482. Changed some code in benchmark page to prevent rest from not loading if a variable is empty. Changed some minor text in system page to not scare people :P This adds just another level of preventing what happened to @seneo , but I don't understand why it would do that in the first place. Please read earlier post and give me the info in case you find any. Otherwise, try what I said in earlier posts.

I would for sure check your system for any kind of corruption too, there's nothing I have changed or added that should make this happen. The only major thing that in theory could cause this, is the new benchmark migration of the JSON files, but all locations are hard-coded with defined constants and would not leave outside the plugins area. It does check for the specific location before even trying to run the code (which would fail if it somehow would pass it): define("UNRAID_CONFIG_PATH", "/boot/config"); ... define("DISKLOCATION_PATH", "/plugins/disklocation"); ... is_dir(UNRAID_CONFIG_PATH . "" . DISKLOCATION_PATH . "/benchmark")That path is specific to "/boot/config/plugins/disklocation/benchmark" That's the only real file level change since a long time, and this can't be the cause.

This is the strangest thing I've seen. There's no reason or really a possibility that this plugin would end up on any Unraid or other places than on the boot device you run Unraid from (typically USB drive). Do you have any errors listed in PHP Settings logs related to this plugin? I would also like to know the contents of one of the files in cache/pages, give me the top 3 lines of "locate.php" - I will make some further checks to prevent this regardless. Should be safe to delete that folder afterwards though. I would in your case, delete the plugin the normal way (if possible). Then go to where it has been installed, your cache and delete it from there and then remove the pages share. Then when it's wiped, install it again from community apps. Your settings should be intact on the USB drive, you can always check in terminal: ls -l /boot/config/plugins/disklocation/ But how this happened is very strange and honestly makes no sense.

But in all seriousness, this warning message should probably just be deleted by now as the System page has changed quite a bit since it was first created :P I would not refer to it, if it wouldn't be safe. It will spin up drives in standby, but that's more or less the most harmful thing that is done. Warning message will be deleted next release, and text adjusted.

It will put your server on fire, be careful

THANK YOU! I started to blow my head off on this one, everything worked, except getting internet through. Now everything just works! You deserve a cookie!

Alright, thanks anyway.

Can you give me the output from the PHP logs again? Maybe there's some old configs or something which is conflicting somehow, might help others, or for you to restore later.