DontWorryScro

Confirmed fixed. Thanks for jumping on that so fast!

@FlamongOle @seneo Looks like Masterwishx's update for CA Mover Tuning has fixed the issue. I updated and tested it and it no longer breaks Disk Location. Thanks for the quick fix, @Masterwishx !

They found the bug and will have it fixed in the next version.

Here you go. Thanks! ca.mover.tuning-debug-20251030-1329.zip

Hi, I am experiencing a repeatable and serious issue using CA Mover Tuning (version 2025.10.22, by masterwishx) with Unraid, where essential system plugin files get moved out of their correct location and the affected plugin stops working. System summary: Unraid version: 7.2.0 (initially noticed before the update on 7.1.4) CA Mover Tuning version: 2025.10.22 Affected plugin: Disk Location Affected SSD cache pools: ADATA SU800 1TB (docker_appdata) and SAMSUNG EVO 850 500GB (Plex_appdata) Related share: appdata (cache: prefer) No intentional “pages” share exists in my setup What happens: Every time mover runs (manual or scheduled), CA Mover Tuning moves files from /usr/local/emhttp/plugins/disklocation/pages/ (and other plugin files) to my cache/appdata pool, creating a new “pages” folder on SSD (e.g., /mnt/docker_appdata/pages and/or /mnt/plex_appdata/pages). After this, Disk Location disappears from the Tools menu and shows a blank page when launched from the Plugins list. Its cron jobs fail due to missing PHP scripts. Testing steps I performed: Reinstalled Disk Location and removed the unwanted “pages” share to restore normal operation. Enabled full mover logging. Ran mover manually with standard settings, which immediately moved dozens of plugin files (Disk Location’s “pages” directory and others) out to the cache pool, breaking the plugin again. The mover logs clearly show CA Mover Tuning treating these plugin files as share data: Moving "./plugins/disklocation/./pages/array_devices.php" to /mnt/plex_appdata/ Moving "./plugins/disklocation/./pages/benchmark.php" to /mnt/plex_appdata/ Moving "./plugins/disklocation/./pages/cronjob.php" to /mnt/plex_appdata/ ... (and more for every file in the plugin) The Disk Location plugin is only broken when CA Mover Tuning is enabled. This does not happen with the standard mover alone. As one more test, I enabled “Test Mode (dry run): Yes” in CA Mover Tuning and ran mover again. In this mode, Disk Location was left untouched and continued to work as expected, confirming it is the move operation itself causing the issue. Desired outcome: I need CA Mover Tuning to completely ignore system, OS, and plugin files, especially anything inside /usr/local/emhttp/plugins. This folder should never be treated as share or user data. If there’s some way my settings could affect this, I’d be happy for advice, but I haven’t included any plugin folders in any shares. I can provide: Full logs of the problem System diagnostics or additional info upon request I hope this helps track down the bug. Please let me know if there’s anything else I can check or try. Thank you!

Follow-up update: I wanted to provide a clear update on my troubleshooting since my last post, as I’ve nailed down the culprit and strongly suspect CA Mover Tuning as the direct cause. Steps taken: After noticing the Disk Location plugin went missing from the Tools tab again this morning (blank page, files appearing in a rogue “pages” share on my cache SSD), I manually removed/reinstalled the plugin and deleted the unwanted share. I then enabled full mover logging and manually triggered a mover run to watch the process in detail. Findings: During the mover run, I observed in the log that CA Mover Tuning was actively moving Disk Location plugin files, including the contents of plugins/disklocation/pages/ from where they belong in /usr/local/emhttp/plugins/disklocation to my cache/appdata pool (/mnt/plex_appdata/). The relevant lines looked like: Moving "./plugins/disklocation/./pages/array_devices.php" to /mnt/plex_appdata/This happened for every file in the plugin’s “pages” directory, causing Disk Location to break (since its runtime code is being treated as movable data). Conclusion: This confirms that CA Mover Tuning is misidentifying plugin system files as files eligible for handling in user shares. As a result, every time mover runs (manual or scheduled) with the plugin enabled, it creates orphaned plugin code on the cache/appdata pool and destroys the plugin’s ability to run. Next Actions: For now, I’ve removed the “pages” share and reinstalled Disk Location to restore functionality. I recommend disabling CA Mover Tuning entirely until this edge case bug is fixed—otherwise, it will keep recurring. Happy to provide full logs to help replicate or diagnose if needed. Let me know if you need me to send the full mover log or test any additional scenarios! I've also posted to the Mover Tuning support thread here

Unfort. it looks like my PHP log Error reporting level is set to Default and apparently theres zero log info. I do use CA Mover Tuning by masterwishx I used to user a different mover tuning plugin but it started acting up and so it was advised to remove and/or switch to another author's version. I cant remember the full details, though. However not sure if my edit on my original post was seen but i fixed this by just Removing the plugin and reinstalling it. Then forcing a SMART scan inside Disk Location. Went ahead and removed the pages share as it was just redundant Disk Location files.

the exact thing that happened to seneo happened to me. a pages share, disk location missing from tools page, and selecting it manually from the plugins list gives me a blank page. but the plugin shows as up to date in my plugins page. do i need to force an update somehow? if i uninstall and reinstall the plugin will i lose all my info? EDIT: I fixed it. To play it safe I backed up disk location with cp -r /boot/config/plugins/disklocation /boot/config/plugins/disklocation.backup and just removed the plug in and reinstalled it. It then asked me to Force a SMART and so I went to the System tab inside Disk Location and clicked the Force Smart button. Took about 20 seconds and I am now back in business.

I am running Unraid 7.1.2, and I did just setup Huntarr a couple days ago. That's the only thing I can think of that has changed. My server has frozen a couple times overnight to the point I need to do an unclear shutdown by holding down the physical power button to recover. I don't really see anything super obvious though I see a lot of things that seem problematic in logs ive reviewed from the log server. I'd sure love some help from someone who has the ability to pour of my Diagnostics and tell me if anything stands out. I'd really like to stop hard resetting my machine every morning. Thanks diagnostics-20250517-1022.zip

Do we know why a new docker image was created on boot? is it going to do this every time i reboot now? Is there some setting somewhere that I have overlooked that nuked my last docker image?

I'm running Unraid 7.0.0 Recently had an issue with it seems my Docker.img was corrupted and had to do a deletion of the image and a reinstall of all my containers. I had forgotten to turn off some mover logging which filled up my sys log making my logging get stuck so I added some info to my go file to expand the log capacity a little bit. # Enlarge the LOG partition (because Dynamix System Stats needs at least 186Mb, default LOG is 128Mb) mount -o remount,size=384m /var/log Turned off the more verbose logging for Mover and rebooted. When it came back up everything started up seemingly fine except I no longer had any Docker containers. diagnostics attached. TIA Edit: I removed the additional parameters from the Go file just in case but it seems to have had zero effect. I double checked that the docker setting pointed to the correct location for the image and my appdata share looks to have all the container folders present. snuts-diagnostics-20250129-0921.zip

Jan 21 13:44:51 Snuts emhttpd: shcmd (301): /usr/local/sbin/mount_image '/mnt/nvme_cache/system/docker/docker.img' /var/lib/docker 60 Jan 21 13:44:51 Snuts kernel: loop3: detected capacity change from 0 to 125829120 Jan 21 13:44:51 Snuts kernel: BTRFS: device fsid 0e6e0292-448f-4925-96e5-da45dc1abebf devid 1 transid 4862398 /dev/loop3 scanned by mount (82182) Jan 21 13:44:51 Snuts kernel: BTRFS info (device loop3): first mount of filesystem 0e6e0292-448f-4925-96e5-da45dc1abebf Jan 21 13:44:51 Snuts kernel: BTRFS info (device loop3): using crc32c (crc32c-intel) checksum algorithm Jan 21 13:44:51 Snuts kernel: BTRFS info (device loop3): using free space tree Jan 21 13:44:51 Snuts kernel: BTRFS error (device loop3): bad tree block start, mirror 1 want 72966422528 have 0 Jan 21 13:44:51 Snuts kernel: BTRFS error (device loop3): bad tree block start, mirror 2 want 72966422528 have 0 Jan 21 13:44:51 Snuts kernel: BTRFS warning (device loop3): couldn't read tree root Jan 21 13:44:51 Snuts root: mount: /var/lib/docker: can't read superblock on /dev/loop3. Jan 21 13:44:51 Snuts root: dmesg(1) may have more information after failed mount system call. Jan 21 13:44:51 Snuts kernel: BTRFS error (device loop3): open_ctree failed Jan 21 13:44:51 Snuts root: mount error Jan 21 13:44:51 Snuts emhttpd: shcmd (301): exit status: 1 snuts-diagnostics-20250121-1341.zip I was trying to tinker with Mover Tuning to get it back to behaving how it should. It seemed to get a little wonky after I updated to 7.0.0. the other day. But after rebooting I saw errors and a message on the Docker tab that "Docker Service failed to start" I am attaching Diagnostics. Do I need to delete and rebuild my Docker image? Is it a pain? I was using custom networks for some containers but they were created so long ago I forget which containers had them or what they even were. I think i am about to be a very sad camper.

I had a brand new drive throwing crc errors for a couple days. (Was waiting on some replacement cables from Amazon to shut it down and replace to see if that fixes it) but a few hours ago the problem drive went full disabled and kicked off a parity check. Is this a cable issue? I get this sort of often. Is this really the failure rate of sas cables? I feel I'm buying multiple packs of replacement cables every year to keep my Unraid spinners happy. Or is that not what this is? Any insight into whats wrong with drive 19 would be appreciated. Thanks. Diagnostics and SMART log for the drive attached. snuts-diagnostics-20241103-1129.zip snuts-smart-20241103-1110.zip

syslog-192.168.100.29.log

sorry about the typo on the title. Wish I could edit it to fix to "unavailable"