seneo

After some days running both plugins the problem hasn't occured again. Pretty safe to say that the issue is fixed.

I'm on the same page as you. I've removed Mover tunning and the issue hasn't appeared again. After an intiial reboot that restore Disklocation, the plugin stopped working before the next day, mover was scheduled for the night, so I highly suspect that's the issue is with mover tunning since it hasn't happens sinc I removed it a few days agoi.

I do use this plugin also. I've removed it, rebooted my server to reinstall disklocation and I will check in a couple of days if the issue appears again.

@FlamongOle it seems to have happened again : The file have been modified according to the "last modified" ant there is a new folder (named script). Even in the parent folder : The disklocation.page last modified time correspond to the scheduled auto-update for my server. The other time seems to match the time I was writing my previous post (and so checking my server). But I didn't update/install/remove the plugin, I don't understand what could have modified those files. Edit: I did restart my server earlier today and the plugin seeems to work again (didn't check before reboot, so it may be have been working again after the auto-update this night). I can see it in the tool tab, and all my data/disk are shown as previously, instead of the blank page I got before.

I've just check unraid logs (didn't thinks to do before). I see many errors related to disklocation since the creation of the file Edit : those line only started to appear today, before I noticed the issue. I see those update on the logs : Oct 18 01:30:09 intersect Plugin Auto Update: Auto Updating disklocation-master.plg Oct 20 01:30:10 intersect Plugin Auto Update: Auto Updating disklocation-master.plg Those are the first occurences of the error, with a bit of history just before : Content of locate.php (not sure If you wanted the 3 first line of comments or code) : I don't see any other weird things with my server for now. No other error/unusual line in the logs, no other issue with my shares/files. This really seems limited to those files/share. I'll try to reinstall the plugin later. I don't use it very often so even if it's not working right now it's not a big issue. I was more curious of what could be the source of this issue. Edit : I'm not shure I wan't do delete the plugin normally (through the plugin tab). I'm scared that if it's some directory issue, as file/folder where created on my cache drive the uninstall will try do delete all files on the drive not just this plugin's ones. Edit: The rest of the plugin file are on my cache drive too, just not in a folder so no shares created. Edit : in /boot/config/plugings/disklocation thete is no benchmarkfolder. And this is /boot/confdig/plugins/disklocation-master

The last update (2025.10.19) seems to have broken the plugin for me. There is a new 'pages' share on my array with disklocation php files. THe plugin isn't listed on the tool tab anymore and myserver/Tools/disklocation shows a blank page. Does anyone else has the same issue ? I've made a bug report on github (https://github.com/olehj/disklocation/issues/482)

I didn't think that TPM was used either, but I'd rather ask before doing something too quick, I just rebooted and pressed Y and everything seems to work correctly. Thanks for your time.

I've just upgraded my CPU (ryzen 5 1800 to ryzen 9 5900) , and upon boot I now have the following message "We detect a new processor, which will change the dada/structure of the storage space for firmware TPM. If you did not apply this function, please press Y to continue, otherwise please follow instructions below: Press Y to reset fTPM, if you have BitLocker or encryption enabled, the system will not boot without a recovery key. Press N to keep previous fTPM record and continue system boot, fTPM will not enable in new processor. You can swap back to the old processor to recover TPM related keys and data." I tried to pressed N and the machine boot correctly (and the array/shares/docker where ok), but the message keep appearing after a reboot. I do have an encrypted array but I'm pretty sure that this message do not apply to my case, but I'm not experienced enough with those things to press Y without more information/advice. Does anyone had this kind of issue, and is it safe fore me to press Y? Thanks to all.

I have a similar issue, the config file doesn't seems to have changed, but the save path of each torrent as been change to /config/qBittorrent/downloads and qbitorrent is now moving all the files to the inside of the container (into my cache drive). Reverting to the previous image (4.3.9-2-01) seems to fix the issue.

Machine re-booted, array started and no more warnings for now. Thank you both for your help and your quick answers. I'll mark the topic as solved in a couple hours just to be sure (the warning wasn't always immedialty after starting the array).

Done. Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... sb_fdblocks 75199576, counted 76180631 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 1 - agno = 0 - agno = 2 - agno = 3 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (109:3726193) is ahead of log (1:2). Format log to cycle 112. done Does it means it should be back to normal now and I can re-start the array? At least for this issue.

The outpout without the -n is as follow ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. I'm not sur what 'Mount the filesystem to replay the log, and unmount it before re-running xfs_repair.' means in this context. Does it means I should start/stop the array before re-running xfs_repair in maintenance mode?

Ok so when I use the `check` button of the `Check Filesystem Status`section of disk1 I can see the following log: Phase 1 - find and verify superblock... - block cache size set to 736264 entries Phase 2 - using internal log - zero log... zero_log: head block 3726195 tail block 3726191 ALERT: The filesystem has valuable metadata changes in a log which is being ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... sb_fdblocks 75199576, counted 76180631 - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Fri Dec 18 20:18:39 2020 Phase Start End Duration Phase 1: 12/18 20:15:59 12/18 20:15:59 Phase 2: 12/18 20:15:59 12/18 20:16:05 6 seconds Phase 3: 12/18 20:16:05 12/18 20:17:42 1 minute, 37 seconds Phase 4: 12/18 20:17:42 12/18 20:17:42 Phase 5: Skipped Phase 6: 12/18 20:17:42 12/18 20:18:39 57 seconds Phase 7: 12/18 20:18:39 12/18 20:18:39 Total run time: 2 minutes, 40 seconds Should I retry without the -n option as mentionned in 'phase 2'? I'm scared to do more harm than good without the 'no modification' option.

I'm trying to troubleshoot recent issues that I have recently with my unraid server (unraid version 6.8.3 2020-03-05). I have many issues regarding docker, container crashing/stopping, full docker system crashing etc... but right now I'm focusing on some warnings that pop when I start the array: kernel: XFS (dm-0): Metadata corruption detected at xfs_dinode_verify+0xa5/0x52e [xfs], inode 0x18c72912a dinode I'm not able to identify the disk in question, I assume that dm-0 correspond to md0 but looking at the logs I don't see this mount point. The only disks I don't see mounted in the logs are the parity and the flash drive but they are not using XFS. The warnings seems to appear only after starting the array after booting, not after stoping/starting the array. Does anybody have any idea? intersect-syslog-20201218-1836.zip