rramstad

I'd recommend taking the server offline and using something like a bootable USB stick to run Memtest or similar overnight. That's a really good way to figure out if you have a memory problem or not. No, you misunderstand parity. If data that is incorrect is written to the array, the array doesn't know it's incorrect. Parity will report it as matching what is expected -- it's just not what the torrent sent. Parity can only help recover errors i.e. when something was written as X and becomes Y. It can't detect any problems if X was written and really it was supposed to be A in the first place. Reseat your RAM sticks for sure before doing anything else. SATA cables are super cheap so replace them all. I've also seen weird stuff when a power supply is dying OR when the PS was on the edge anyway and the hard drives get old, they draw a bit more power, and can cause problems. Honestly I've seen it all, bad motherboard in this situation, bad ethernet...

Everything goes through RAM both ways -- nothing actually ever goes directly from the disk to the CPU, it's always going through RAM. Corrupted segment means something is wrong with the file as it sits on the disk. Parity check passing means that it's written incorrectly on the disk as far as the torrent data is concerned. I'm guessing a bad cable, or bad RAM. I've seen a bad cable give similar issues.

Are you doing a forced re-check of the 99.9% torrent before restarting it? Honestly, this sounds like failing hardware to me. To put it in perspective, I have three instances of Transmission running on my system, roughly 6,000 torrents between them, and I've never had what you describe happen, ever.

Are you trying to connect from within the Unraid web UI? Docker, find the container, right click, Web UI. Try removing the whitelist for now to see if that helps. If it isn't working, post the URL that is displayed in the browser tab.

From my end, the key is that you can connect to Transmission on the LAN but you cannot connect to it through the VPN. This means -- assuming you have the settings correct -- that the whitelist isn't the problem. Are you sure that the VPN access appears as if it is from 10.8.0.3 when it is on your network? That strikes me as slightly unusual. Are you sure that the VPN is properly forwarding accesses to the correct local IP for Transmission?

Well, given what you've said, my best guess is that your port forwarding isn't set up properly with the VPN. Either that or the service that is connecting inbound is not connecting to the correct internal IP. I can almost guarantee that this isn't a Transmission problem, that it has something to do with Wireguard and/or the details of the way the VPN is set up.

Example whitelist 127.0.0.1,192.168.*.* i.e. separate with comma, always use four dot notation, * for wildcard

Post your whitelist. It wants a specific syntax. Take a look at the docs.

OK, wasn't clear what you were trying to do. Best guess is you have the syntax wrong for the whitelist, or you have something going on with your firewall. Does your VPN properly route inbound traffic to other services? That's going to be a good way to figure out if this is a Transmission configuration problem, or if you have a broader problem.

Have you looked into the transmission version that is specifically modified to support VPN? It has good documentation and should be easier to configure.

It wants this syntax 192.168.0.*

WHITELIST is the list of IP addresses that can access the Web UI. You want to set this to your LAN, plus possibly 127.0.0.1 PEERPORT is the port that is advertised to the external folks who are attempting to connect to your Transmission. It's there to allow for funky setups where you might want to advertise port X on your exterior interface and map that internally to a different port when you are port forwarding. Also useful if using some sort of VPN. If you have no idea what to set this to, set it to the port that you are using for inbound Transmission traffic I did not need HOST_WHITELIST which is similar to the WHITELIST above but uses host names, so I clicked REMOVE next to that variable. Having them blank -- here or in the settings.json -- will not work.

For the curious who might have read my last two posts and wondered if there are any updates... I ended up changing two of the three docker images from Bridge mode to use a fixed new static IP on my network, and allowed them to run on the native docker ports but with unique peerport settings. I adjusted my port forwarding and the dockers work correctly, allowing inbound client traffic. My best guess is that the new docker images got confused when they were created, and in bridge mode no longer understand what the base port is that the image wants to listen on. The result is that inbound connections to the copied dockers fail. It's possible that if I had blown away all the transmission dockers, taking notes on configuration details, and reinstalled transmission, and then possibly cloning the default configuration, and then adjusting each clone separately, that I could have gotten things working but frankly I wanted a low effort solution. I am not all that conversant with docker but that's my best guess -- I installed the first docker, made adjustments to it, got it the way I wanted, and then made two copies, and could never get the copies to work right until I switched to using them with a static IP. Hope this helps someone.

Posting with one other strange thing I noticed. On the console of the one that works: root@fede8952ebd5:/# netstat -ntlp | grep LISTEN tcp 0 0 0.0.0.0:9091 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:52331 0.0.0.0:* LISTEN - tcp 0 0 :::52331 :::* LISTEN - The one that is broken, same command: root@6d8cbcaaa6aa:/# netstat -ntlp | grep LISTEN tcp 0 0 0.0.0.0:9091 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:52329 0.0.0.0:* LISTEN - tcp 0 0 :::52329 :::* LISTEN - This seems truly odd. Within the docker itself, it should still be listening to the same port 52331, right? The bridge should take care of mapping the external 52329 to the internal 52331. (Just like this second example has a web UI available at 9092 which works, and the bridge is mapping the external request of 9092 to the internal 9091, which is what it's listening to.) Again, freely and openly admit that I've never tried running multiple instances of the same docker, but my expectation would have been for these two instances to be listening to the same ports, and the bridge would have been taking care of the mappings.

I'm trying to run multiple instances of this docker on Unraid. In general I'm having reasonable success but the initial instance is the only one working properly. The issue is that the second and third instance are showing as not being accessible from the outside, but after double and triple checking port forwarding, it seems to be a problem with the docker itself somehow. Here's what I mean. On a console, I see this output netstat -ntlp | grep LISTEN (snip) tcp 0 0 0.0.0.0:52333 0.0.0.0:* LISTEN 9025/docker-proxy tcp 0 0 0.0.0.0:52329 0.0.0.0:* LISTEN 3551/docker-proxy tcp 0 0 0.0.0.0:52331 0.0.0.0:* LISTEN 6311/docker-proxy (snip) tcp 0 0 0.0.0.0:9093 0.0.0.0:* LISTEN 9076/docker-proxy tcp 0 0 0.0.0.0:9092 0.0.0.0:* LISTEN 3598/docker-proxy tcp 0 0 0.0.0.0:9091 0.0.0.0:* LISTEN 6348/docker-proxy (snip -- including IPv6 entries for these) The three dockers have 9091, 9092, 9093 for the web UI and rpc. They have 52331, 52329 and 52333 for BT traffic. On my LAN, I can access the web UI for each of the three -- and make transmission-remote calls using 9091, 9092 and 9093. The first one has client traffic accessible from outside the LAN just fine i.e. it indicates when I look at the settings that port is open, and I can use external testing tools to confirm the port is open, plus when I visit tracker web sites they show that I am reachable. The other two are not accessible from outside the LAN i.e. inbound traffic doesn't work. Now, here's the kicker -- I can see above that the dockers should be getting the BT traffic, i.e. on the Unraid system, those parts are showing as being open, so on a whim, I plugged in http://10.50.0.250:52331 into a browser on my LAN, and I get a response -- it's a series of responses saying it's not a valid response. That's the one that is accessible from the outside. So, that's the expected response. If I plug in one of the ones that doesn't work http://10.50.0.250:52329 I get a "refused to connect" error -- so the docker seems to be refusing the connection, or somehow the port isn't being properly forwarded. I am at a loss. This test seems to indicate that whatever is going on is local i.e. the port isn't being properly forwarded from docker. Here's the stuff from starting the one that works: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='transmission' --net='bridge' -e TZ="America/Los_Angeles" -e HOST_OS="Unraid" -e HOST_HOSTNAME="unraid" -e HOST_CONTAINERNAME="transmission" -e 'TRANSMISSION_WEB_HOME'='/flood-for-transmission/' -e 'PEERPORT'='52331' -e 'WHITELIST'='10.55.0.*,127.0.0.1' -e 'PUID'='99' -e 'PGID'='100' -e 'UMASK'='022' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='http://[IP]:[PORT:9091]' -l net.unraid.docker.icon='https://raw.githubusercontent.com/linuxserver/docker-templates/master/linuxserver.io/img/transmission-logo.png' -p '9091:9091/tcp' -p '52331:52331/tcp' -p '52331:52331/udp' -v '/mnt/user/tunes_work/BTDownloads':'/downloads':'rw' -v '/mnt/user/tunes_work/BTWatch/':'/watch':'rw' -v '/mnt/user/easystore':'/easystore':'ro' -v '/mnt/user/home':'/mnt/home':'ro' -v '/mnt/user/appdata/transmission':'/config':'rw' 'lscr.io/linuxserver/transmission' and it shows these mappings for the bridge 172.17.0.3:52331/TCP10.55.0.250:52331 172.17.0.3:52331/UDP10.55.0.250:52331 172.17.0.3:9091/TCP10.55.0.250:9091 Here's the stuff from starting one of the ones that doesn't work: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='transmission_Dime' --net='bridge' -e TZ="America/Los_Angeles" -e HOST_OS="Unraid" -e HOST_HOSTNAME="unraid" -e HOST_CONTAINERNAME="transmission_Dime" -e 'TRANSMISSION_WEB_HOME'='/flood-for-transmission/' -e 'PEERPORT'='52329' -e 'WHITELIST'='10.55.0.*,127.0.0.1' -e 'PUID'='99' -e 'PGID'='100' -e 'UMASK'='022' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='http://[IP]:[PORT:9091]' -l net.unraid.docker.icon='https://raw.githubusercontent.com/linuxserver/docker-templates/master/linuxserver.io/img/transmission-logo.png' -p '9092:9091/tcp' -p '52329:52331/tcp' -p '52329:52331/udp' -v '/mnt/user/tunes_work/BTDownloads':'/downloads':'rw' -v '/mnt/user/tunes_work/BTWatch/':'/watch':'rw' -v '/mnt/user/easystore':'/easystore':'ro' -v '/mnt/user/home':'/mnt/home':'ro' -v '/mnt/user/appdata/transmission_Dime':'/config':'rw' 'lscr.io/linuxserver/transmission' and these mappings 172.17.0.4:52331/TCP10.55.0.250:52329 172.17.0.4:52331/UDP10.55.0.250:52329 172.17.0.4:9091/TCP10.55.0.250:9092 I am running today's version of this docker. I updated everything when I started having problems. Any thoughts? I'm at a loss. Admittedly I've never tried to do this before, run multiple copies of the same docker.