-
[Support] Linuxserver.io - Transmission
@tshorts You are welcome. Glad that my suggestion got you moving in the right direction. Sometimes it's just unbelievably helpful to know that other people have made an update without issue... or that everyone is borked LOL
-
[Support] Linuxserver.io - Transmission
I'm having no problems at all with transmission:latest on the current Unraid version and didn't have any trouble with upgrading. It looks to me like you have Docker permission problems. The easiest way to address this is by using the Fix Common Problems plugin and allowing it to fix permissions. I believe best practices is to shut down your Dockers, then run the tool, then start them again. I've been running Unraid and transmission for several years but wouldn't consider myself an expert. Mostly I'm writing so you know other folks made the upgrade just fine and haven't had any problems. Good luck!
-
[Support] Linuxserver.io - Transmission
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...
-
[Support] Linuxserver.io - Transmission
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.
-
[Support] Linuxserver.io - Transmission
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.
-
[Support] Linuxserver.io - Transmission
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.
-
[Support] Linuxserver.io - Transmission
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?
-
[Support] Linuxserver.io - 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.
-
[Support] Linuxserver.io - Transmission
Example whitelist 127.0.0.1,192.168.*.* i.e. separate with comma, always use four dot notation, * for wildcard
-
[Support] Linuxserver.io - Transmission
Post your whitelist. It wants a specific syntax. Take a look at the docs.
-
[Support] Linuxserver.io - Transmission
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.
-
[Support] Linuxserver.io - Transmission
Have you looked into the transmission version that is specifically modified to support VPN? It has good documentation and should be easier to configure.
-
[Support] Linuxserver.io - Transmission
It wants this syntax 192.168.0.*
-
[Support] Linuxserver.io - Transmission
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.
-
[Support] Linuxserver.io - Transmission
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.
rramstad
Members
-
Joined
-
Last visited