FreeNas, Transmission and Corrupted Files – Part 2

This is continuation of FreeNas, Transmission and Corrupted Files – Part 1

When corruption started to hit it was bad… few of seeded torrent were crying about error, and each time I did Verify local files they end up cleaning them to 0%. It was very annoying, because after verification it want to redownload same file over and over again.

I started thinking… Could it be because of someone abusing tracker? I read multiply time about poisoning tracker and sending corrupted segments, but the more I read about that possibility the less it looked to be even possible, because of all those checksum inside bittorrent clients and microTP (uTP). It was more and more strange… I even reach out to mod of that tracker, but that didn’t yell any more information – but I did notice same IP sending same file so I reported that IPs as possible culprit – just in case because It would be faster and simpler for them to check if those few IPs are getting strange upload stats for less popular torrents (very rare Linux distributions)

I updated transmission by hand because I wanted to be sure its not a software issue – that did not helped.

I wanted to exclude possibility of external process modifying those files – I used AuditD…. and it was horror… It was horror because this is not suite for processes that run as deamons, its designed the way you could audit living/automated login into shell and then interrogate aka audit users/accounts.

Gladly someone said ‘I WANT TO USE IT THAT WAY’ and made a wrapper setaudit and it was a godsend. As Transmission is running inside Jail setaudit overcome any issue I had with auditd.

# setaudit command to lunch updated transmission inside first jail
./setaudit -a transmission -m fw jexec 1 /usr/pbi/transmission-amd64/bin/transmission-daemon -g /var/db/transmission -x /var/run/transmission/daemon.pid

Running auditd gave me confirmation that the transmission indeed is overwriting files that I already had (basically nuke them).

It was time to check for hardware failure – but the strange thing was that always the same files got corrupted. But we live in strange times … anything is possible if you believe hard enough.

And after many-many hours and many-many tests later nothing came up from them I was still in middle of nowhere…

Then It hit me like a track… I tweak the jail because I was trying to overcome the issue with network and bypass limits of that container that In the end were not container fault, but I did not reverse those tweaks because they didn’t harm anyone, right?

Maybe it was cosmic radiation, maybe it was a lucky guess or conflict with upgraded version but after removing `allow.raw_sockets=true`and rebooting I never had those corruptions issue ever again.

Leave a Reply

Your email address will not be published. Required fields are marked *

*