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"

Over the past couple days 2 times I've had my shares become inaccessible and attempting to access the web gui got me a time out issue. Tried to SSH into the server to no avail. Never connects. Doesn't even give me a prompt to log in. Just blank screen and an eventual connection refused message. Connecting a monitor and keyboard directly to the server and when I try to login with root it just gives me a message about timing out after 60 seconds and prompts me to login again. So I throw in the towel and quick press the power button on the server which is _supposed_ to clean shutdown. But on reboot I am notified it was an unclean shutdown and I am now on my second parity check in as many days. (Ive actually cancelled this second one until I can sort out what is going on) I am attaching diagnostics and the very last part of the logs from the syslog server before it stopped being active. Any help would be appreciated. Last syslog output before new lines created on the reboot today: Oct 7 13:01:17 Snuts unassigned.devices: Warning: shell_exec(/bin/lsblk -b -n -o NAME,SIZE,TYPE | /bin/awk '$3 == 'disk' {print $1 ',' $2}' 2</dev/null) took longer than 0s! Oct 7 13:01:17 Snuts unassigned.devices: Warning: shell_exec(/bin/lsblk -b -n -o NAME,SIZE,TYPE | /bin/awk '$3 == 'disk' {print $1 ',' $2}' 2</dev/null) took longer than 0s! Oct 7 13:01:17 Snuts unassigned.devices: Warning: shell_exec(/bin/lsblk -b -n -o NAME,SIZE,TYPE | /bin/awk '$3 == 'disk' {print $1 ',' $2}' 2</dev/null) took longer than 0s! Oct 7 13:01:17 Snuts unassigned.devices: Warning: shell_exec(/bin/lsblk -b -n -o NAME,SIZE,TYPE | /bin/awk '$3 == 'disk' {print $1 ',' $2}' 2</dev/null) took longer than 0s! Oct 7 13:01:17 Snuts unassigned.devices: Warning: shell_exec(/bin/lsblk -b -n -o NAME,SIZE,TYPE | /bin/awk '$3 == 'disk' {print $1 ',' $2}' 2</dev/null) took longer than 0s! Last syslog output before new lines created on the reboot from the other day: Oct 4 05:03:34 Snuts php-fpm[14815]: [WARNING] [pool www] child 2116 exited on signal 9 (SIGKILL) after 408.089840 seconds from start Oct 4 05:04:42 Snuts php-fpm[14815]: [WARNING] [pool www] child 2194 exited on signal 9 (SIGKILL) after 428.109426 seconds from start Oct 4 05:05:20 Snuts php-fpm[14815]: [WARNING] [pool www] child 2383 exited on signal 9 (SIGKILL) after 419.205064 seconds from start snuts-diagnostics-20241007-1604.zip

just added a new disk to replace a smaller one. all is well. assigned the disk tray location, added my comment and purchase date. saved ok. but once i went to set the color manually (because it seems disk location apparently has some issue with recognizing sas drives) my disk location plugin took a giant dump. ive lost all data for my entire array, devices tab shows nothing, information tab shows nothing, configuration tab has blown out my entire array with zero data, tray allocations is completely reset... so.. how can i get back to where i was an hour ago? is there a plugin restore function? Edit: I discovered a restore function in the System tab. It was from a pretty old backup but after some drive updates/reassigns i seem to be back in business.

Does using this program preserve directory structure and file names? i accidentally formatted a disk while in place in my array and am currently using testdisk in unraid to rescue data but no metadata is preserved.

Today after signing into one of my reverse proxied domains through authelia my iphone told me my password was insecure and to change it as it had been found in some database breech. Ive come to realize either I forget how to change the password or I never knew. How do?

Oh it'd sure be amazing to do that turn on -> backup -> turn back to off move. Is there a guide on that anywhere? Also what container update in regards to the root vs luckybackup directory? The container is running on my source machine. I dont have a LuckyBackup docker container running on my destination machine where the id_rsa is kept. I must be brain farting on this somewhere along the line. Here is a screencap of my docker container config

im not as adept as others. Can you tell me how to take the id_rsa from the root dir that was explained in the guide and copy/move it to where ever this is? And how to adjust the path in luckybackup to find the new location I rewatched the video and any instance of typing root in cli i replaced with luckybackup but all things being equal, in the end, i just saw this when i navigated to the newly created luckybackup directory for the key. Looks to be empty inside. what i do wrong? I was able to rightclick in the empty space to give me the option to show hidden files which did in fact reveal to me the id_rsa files i had created. but selecting them and attempting the backup popped some weird password request window in the VNC.

I followed the video guide posted at the top of this thread and it had the docker container running on the source machine. Is a backup machine meant to be pulling from the source machine instead of the source machine pushing to the destination machine? Does it matter? Also why synchronize instead of backup?

this is really becoming too much a pain to me to be worth it. i regret finally jumping from 6.11.5 which ran flawless for me and I will most likely be going back.

Any developments? I had gone straight to deleting that plugin to test and sure enough the errors kept popping for me. So for me it has to be something else.

unraid runs normally in safe mode? does it disable all your plugins? anything else? docker containers still operate ok?