Hey guys. I just got an error message saying there were some files with hash mismatches. I have included the screenshots for what I could find.

 

I have also posted diagnostics. The server hasn't rebooted for a solid week (the last time it rebooted it was for an UnRAID version update) so it may be a bit long.

 

What I could gather is that Transmission was doing something with the downloaded files... Maybe the checksum failed because it calculated in the middle of a download, panicked that the hash changed and errored out? Just a guess.

 

Is this a false alarm? Can I just chalk this up to an incorrect hash calculation or can there be bit-rot?

derrickserver-diagnostics-20161103-2314.zip

The affected files should be listed in your syslog. When I had a similar message I compared the affected files with those on my backup server and found there was no difference between the actual files (using the

diff

command) but the hashes differed. I couldn't work out an easy way to force a rehash on the affected files so I simply overwrote them with the backups.

The affected files should be listed in your syslog. When I had a similar message I compared the affected files with those on my backup server and found there was no difference between the actual files (using the

diff

command) but the hashes differed. I couldn't work out an easy way to force a rehash on the affected files so I simply overwrote them with the backups.

 

Thanks! I checked the syslog. Apparently, the hash mismatch occurred on October 31st, when three things happened at once.

 

a) The appdata backup started to run

b) The hash checking mechanism started to run

c) The parity check ran, halting either the appdata backup or the hash check (I don't know which)

 

And it resulted in the hash check failing later on. I did check the schedules to not collide with each other, but due to slow hashing times (I use a underpowered CPU), a situation like this was inevitable. I've increased the scheduling time, but this may happen again.