Pixelshading

Updated the Plugin and now its working again Thank you @bonienl

Using the command from the Terminal is working: root@Phoenix:~# /usr/local/emhttp/plugins/dynamix.file.integrity/scripts/bunker -R -b3 /mnt/disk4 Finished - cleared 2220 files, skipped 0 files. Duration: 00:00:21 root@Phoenix:~# /usr/local/emhttp/plugins/dynamix.file.integrity/scripts/bunker -a -b3 /mnt/disk4 Finished - added 2220 files. Duration: 00:02:27. Average speed: 184 MB/s

The setfattr -x user.blake3 command does indeed work well only my cache drives are formatted with BTRFS the main array drives are formatted as XFS however running the normal build command from the plugin via the GUI doesnt work still 0 files hashed Here is a output from a LSI 9211 Flash utility exe: root@Phoenix:/mnt/user/NAS-Drive/Transfer/Firmware/LSI 9211/9211# getfattr -d sas2flash.exe # file: sas2flash.exe user.blake3="22332d1a7d12035f9a5691e65f901be421a768ab94bc7482a15250ff03ccc2ba" user.filedate="1457710188" user.filesize="166912" user.scandate="1677715201" root@Phoenix:/mnt/user/NAS-Drive/Transfer/Firmware/LSI 9211/9211# setfattr -x user.blake3 sas2flash.exe root@Phoenix:/mnt/user/NAS-Drive/Transfer/Firmware/LSI 9211/9211# getfattr -d sas2flash.exe # file: sas2flash.exe user.filedate="1457710188" user.filesize="166912" user.scandate="1677715201"

Well, still no luck for me. Tried the same Settings as you @bonienl but still nothing happend: First selected all disks Now to be safe tried the remove command but here as well nothing happened: Then used the build option: as you can see nothing happened. Now i checked to command line: No hash has been added. Also the next file was hashed before the plugin broke for me and yeah the Blake 3 hash attribute was added, however this attribute should have been remove from the previous remove command and as you can see it wasn't

Thanks bonienl No worrys take ya time, just knowing it will get looked into later gives me a peace of mind.

Any News on the File Integrity Plugin? The Problem still exists for me that new Files dont get hashed And downgrading is also not working getting the same error as FCA Administrator

Got the same issue and im also on unRAID 6.11.5, 0 Files have been added. i tried everything uninstalling and reinstalling. Set the plugin to automaticly hash new files and manually started the process but nothing is working new files wont get a hash added to them

Hey there, It seems like i have the same problem. This is also a new unRAID build but i already move about 12 TB of data to it (its just a backup server) But in my case im using the onboard SATA Controller Currently using 4 x 8 TB Seagate IronWolf Drives and 2 x 4 TB Seagate IronWolf Drives First Parity Check with Corretion: Feb 19 16:18:30 Tower kernel: md: recovery thread: P corrected, sector=2743151176 Feb 19 16:18:30 Tower kernel: md: recovery thread: P corrected, sector=2743151184 Feb 19 16:18:30 Tower kernel: md: recovery thread: P corrected, sector=2743151192 Feb 19 16:18:30 Tower kernel: md: recovery thread: P corrected, sector=2743151200 Feb 19 16:18:30 Tower kernel: md: recovery thread: P corrected, sector=2743151208 Feb 19 17:06:26 Tower kernel: md: recovery thread: P corrected, sector=3907018616 Feb 19 21:07:56 Tower kernel: md: recovery thread: P corrected, sector=8589960632 Feb 19 21:07:58 Tower kernel: md: recovery thread: P corrected, sector=8590443896 Second Check without Corretion this going at this point (currently its at 23,6% done with the second check): Feb 20 17:31:52 Tower kernel: md: recovery thread: P incorrect, sector=2743151176 Feb 20 17:31:52 Tower kernel: md: recovery thread: P incorrect, sector=2743151184 Feb 20 17:31:52 Tower kernel: md: recovery thread: P incorrect, sector=2743151192 Feb 20 17:31:52 Tower kernel: md: recovery thread: P incorrect, sector=2743151200 Feb 20 17:31:52 Tower kernel: md: recovery thread: P incorrect, sector=2743151208 As you can see the sectors are identical. The interesting Part is that i also build a second system with slightly different hardware (this one uses 4 x 8 TB Seagate IronWolf Drives and an intel CPU instead of an AMD) and the same error occurred on those discs aswell in the same exact sector. First Parity Check with Corretion: Feb 20 00:44:53 Phoenix kernel: md: recovery thread: P corrected, sector=2743151176 Feb 20 00:44:53 Phoenix kernel: md: recovery thread: P corrected, sector=2743151184 Feb 20 00:44:53 Phoenix kernel: md: recovery thread: P corrected, sector=2743151192 Feb 20 00:44:53 Phoenix kernel: md: recovery thread: P corrected, sector=2743151200 Feb 20 00:44:53 Phoenix kernel: md: recovery thread: P corrected, sector=2743151208 However when i first build the second system with the 4 x 8 TB Seagate Drives i was using the Mainboard, CPU and RAM from the other system. Maybe thats a hint? Right now im also running a second parity check on the second system about 32,1 % done so far so good. *Edit* Oh and all discs are fine no smart errors

Hello there, It would also be nice to see what file the mover is currently working on, what files have been transfered and what files are in the query to be moved. Also it would be nice to see in the WebUI which files will be moved with the next "mover run"