So, I got up this morning and checked the server and I saw two red notifications. Seems that during the monthly scheduled parity check two files failed the check. One of them is a config file for an emulator buried deep in the filesystem, super easy to replace by just installing a new copy of that file. The second one has me slightly worried, it was the apps.json file for nextcloud. Now, last month it worked fine without any errors and so I naturally expected the same this time. Is it possible two of my drives are starting to fail? Is this something that can happen if the files are being written to at the time of the parity check and that caused it? Nextcloud seems to be working just fine and all the apps load and work perfectly. Would you guys consider preemptively replacing these drives? Run a second parity check on those drives? Is there any non-HDD-failure reason why the parity might have gotten a bit mixed up? Everything seems to be working just fine and there are no additional smart errors on the drive either. I am also running a month-long rclone transfer and have been hitting the array a little harder than usual recently, especially while I am sleeping. Again, nothing irreplaceable or important seems to be broken, and I have proper weekly offsite backups of the stuff that isn't super easy to replace. Those rclone transfers are actually backing everything else up right now.

 

This is the first time I have seen a parity check fail so I am honestly not sure what, if anything, I should do about it. Maybe swap out the SATA cables?

1 minute ago, cammelspit said:

Seems that during the monthly scheduled parity check two files failed the check.

Parity check doesn't check files, do you mean the file integrity plugin?

Just now, johnnie.black said:

Parity check doesn't check files, do you mean the file integrity plugin?

Do I? Maybe I do! I know a parity ran last night because that's the time I have is scheduled so I just assumed that was it.

 

After just checking, you are right about that, I am 100% talking about the file integrity plugin.

SHA256 hash key mismatch, /mnt/disk2/NextCloud/appdata_oc4lmul4d44l/appstore/apps.json is corrupted

should I just chalk it up to a hiccup while checking that file and maybe just keep an eye on it? Also, sorry, apparently I am still getting used to how this thing works. 😊

Possibly the file changed after the checksum was created an everything is fine.

2 minutes ago, johnnie.black said:

Possibly the file changed after the checksum was created an everything is fine.

So, the file integrity plugin doesn't calculate the hash on write? Interesting... Well, since those two files seem no worse for wear and they seem to be working just fine, I can assume it just had a bad hair day. I should probably not have both file integrity and parity run on the same day though. I was using the file integrity plugin before mainly because I was running unraid without parity at the time, I know it's a bad idea but I didn't have enough drives and was using it to keep an eye out for damaged files. Now, especially with a proper full server offsite backup I probably don't even need it like I did. Though, I do like keeping known good hashes of all my files regardless if the plugin does it or not.

IIRC there's an option to monitor changed files and should automatically re-create the hash, but I believe that it some times could fail to update, not sure though if it's still a thing, since I haven't used it for some time.