binhex

@xMaverickx did you run the command as suggested in the log? :- [warn] Unable to load iptable_mangle module, you will not be able to connect to the applications Web UI or Privoxy outside of your LAN [info] unRAID/Ubuntu users: Please attempt to load the module by executing the following on your host: '/sbin/modprobe iptable_mangle' [info] Synology users: Please attempt to load the module by executing the following on your host: 'insmod /lib/modules/iptable_mangle.ko'

interesting stuff guys!, so i got some questions for people running this setup:- 1. can you still access the applications web ui (assuming the container you have joined to the vpn has a web ui) over the lan? 2. what happens if the vpn container goes down?, im assuming all traffic stops for the container sharing the network right?, has anybody tested this for leaks? 3. does the application still operate correctly if the vpn tunnel is bounced, or do you then need to restart the application container?

not that im aware of.

What did you use to edit the file? I suspect line endings have been changed Sent from my CLT-L09 using Tapatalk

you mean not being able to access the gui OUTSIDE of your lan right?, if you are talking about accessing the gui INSIDE your lan then iptable_mangle has nothing to do with this.

github issue raised, i have a test tagged version up right now with what i think is the fix, feel free to test it out, see here:- https://github.com/binhex/arch-rtorrentvpn/issues/139#issuecomment-577255180 edit - my fix looks good, building new 'latest' tagged image right now, please check for updates in about 30 mins.

hmm ok i stand corrected there, i dont think it used to do this, and i personally dont use mover so wasnt aware of the change. Even with this possibility its still going to be an issue if urbackup is generating a large single file, which it can do when creating a disk based backup of a machine, as it wont be possible to split the file in two and write some of it to cache and some of it to the array when the cache drive is full - which looking at your initial post seems to be the case. i think this is your only reasonable course of action for now, maybe reconsider this again when you bump up the size of your cache drive. FWIW i do not use cache drive for caching, most people don't, its used to store docker images, vm vdisks, and metadata, writing to the array, especially when 'CA Auto Turbo Write Mode' (check CA for details) is installed, is fast enough for most use cases IMHO.

no, this is not how it works, if you set a share to use cache then any files written to the share will be written to the cache drive instead, if the cache drive fills up then no further copies will be permitted, it (unraid or the app) will NOT automatically switch to writing to the array when the cache is full. In the situation where the cache drive is full you have two options, manually copy the files from the cache drive to the array to free up space, or wait for the 'mover' to move the files from the cache drive to the array for you, also freeing up space. In short, if your cache drive is too small to contain your urbackup files for a 24 hour period (mover normally runs nightly) then you either need to buy a larger cache drive or not use the cache and write directly to the array, the choice is yours.

Hmm sounds reasonable, in that case I guess the issue is either related to the volume mounted filesystem, perhaps it didn't support hard links, or its a bug in Radarr. Sent from my CLT-L09 using Tapatalk

ok cool, so each movie you have added to radarr will copy/move/hard link to /media/Movies/<movie name>/ is that also true yeah?.

hmm i just had a read through that blog, its pretty in depth stuff, i think the short of it is you cannot hard link across different filesystems, not sure if that is relevant to what you are trying to achieve, looking at your notes i think what you are saying is that the media share and the completed folder are in the same volume mapping (and thus in the same filesystem), right? so:- /media and /media/completed/ is this correct?

hard links will mirror the file (not link), thus doubling the disk space used.

that is a message from the tracker, most probably the tracker is refusing your client, either because its not a supported torrent client, and/or the ip address you are coming from is not permitted - vpn ranges are sometimes banned due to abuse. if its the torrent client thats not permitted (probably NOT the case when downloading linux iso's as per your screenshot), then i would recommend rolling back to deluge 1.x, this will no doubt still be supported by most private trackers. if its the vpn range thats been banned then try connecting to another endpoint, in your log snippet i can see you are connecting to 'ca-toronto', try another location.

nope, please follow the procedure below:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md

that is a dns lookup problem, you look to be blocking dns queries, check your host firewall/lan firewall, you need to permit port 53 outbound.