binhex

As the industry continues to switch from spinning hard drive to SSD as capacity increases, how do you foresee unraid will evolve to meet the different challenges that solid state hard drives bring? Just to be clear I'm talking in relation to array drives, cache is a known solved problem running SSD. Sent from my EML-L29 using Tapatalk

Ok you must not be running the latest image, please do a force update Sent from my EML-L29 using Tapatalk

I will need a new log then as the issue will be different (working for me) Edit just to confirm you have pulled down the latest image.right? Sent from my EML-L29 using Tapatalk

Yes it now REALLY is fixed [emoji16] got caught by clean up where ICU got removed as an orphan package, which I didn't see in testing. Sent from my EML-L29 using Tapatalk

:-), i am a team of one believe it or not. p.s. image is building right now with the fix, so you should be able to pull down shortly.

I'm going to take a look tonight, looks like an easy fix Sent from my EML-L29 using Tapatalk

This could be the cause i have done no testing around pause/resume of a container, i have no idea what order the processes will resume in, and it is potentially possible that the deluge process may resume before iptables rules are re-written. The problem is i dont really see an easy way to do any checks for this to prevent it from occurring, so it maybe either really difficult or just plain impossible, i will have to have a think about it. i can do some digging into this and try and replicate the issue, but obviously for now this would be my top culprit and therefore i would not recommend pausing and resuming of this particular container, instead perform a docker stop and start to ensure proper startup order is performed.

Do you use sonarr/radarr etc? If so have you configured these to use a proxy? Sent from my EML-L29 using Tapatalk

Not that I'm aware of, no and I can't see how it could happen but I'm going to put in more checks just incase. Edit I guess what I'm trying to say is at this point I have to believe the user's post that they had an IP lesk, but I cannot see how the leak could of happened but I'm willing to put additional checks in.

hmm ok so a bit more of a stare at the code, im going to put in an additional blocking check, this will verify the default chain policy of 'block' is set for all chains before going on to perform a check for the vpn tunnel running, and finally only then allowing the app to start. its a belts and braces approach, the current order of startup means iptables must be configured first before the tunnel is established, and the app wont start until the tunnel is established so i am still confused as to how this has happened. i will be working on this asap and hope to have something ready to release tonight. i have done extensive packet analysis when the iptables are in place and im confident they are solid, so this is the only thing i can currently come up with as an additional check, the only real way of knowing for sure would be if you had captured all packets going in and out of your host, which im pretty sure you haven't right?.

that should not be possible, there is a blocking script in place that prevents deluge from running until a valid ip is shown against the tunnel adapter, unless this happens deluge cannot start. if you have the supervisord.log file for the period then please attach it here. or pm me it.

Documentation link in op, see VPN faq its answered in there. Sent from my EML-L29 using Tapatalk

As soon as it's updated on arch repo it will be automatically built. Sent from my EML-L29 using Tapatalk

lol, err yeah 🙂

yes its wrong, 192.168.1.0/24 is not your lan network, change this to 192.168.86.0/24 and then restart delugevpn, then test jackett