[[Solved] Preclear error with backup GPT]

2 hours ago, JorgeB said:

Preclearing is going to wipe everything, so it doesn't matter.

Thanks for confirming.

[[Solved] Preclear error with backup GPT]

I went to preclear a new 14TB drive and got this message:

 

 

After some searching, it seems like preclear might be able to fix it but wanted to ask before I proceed. Thanks

 

Edit: I also tried the -A attribute and same result. Same error on two brand new 14TB drives.

[[Support] binhex - DelugeVPN]

On 3/10/2021 at 11:31 PM, Jason Harris said:

Hopefully you weren't asking me, and mis-quoted.    Sounds like you were already in another deep convo.

Not really...I was rallying off your firewall’d comment! Perhaps you just meant the VPN containers themselves, but I was looking for some guidance on the best configuration given my use case?

[[Support] binhex - DelugeVPN]

11 hours ago, Jason Harris said:

Yea, probably not.  Which is fine.  But, as the popular saying goes, "once you go firewalld, you never go back".   Sort of like NetworkManager vs network, or systemd vs sysv.

 

At the end of the day, if it gets the job done, that's all that matters!

As a former privoxy user, are you saying my best path forward is the following:

 

use case: *arr dockers, kodi using Privoxy and possibly enabling Emby for remote viewing

 

Bind all *arr dockers to DelugeVPN, bind NZBget to DelugeVPN, still run Kodi thru DelugeVPN privoxy, and I’m not sure on the last one so wondering if it influences my decision at all since I need Kodi and Emby to talk to each other as well.

[[support] Bungy's docker repository]

9 hours ago, Profezor said:

I was leaning that way. Thanks for the push.

Haha, I’m in the same position and also looking for a push! In my case, I want to be sure this is the best method for Emby (remote viewing) and Kodi with a VPN (currently using privoxy via DelugeVPN). Between wiregaurd, Jackett etc, I feel like there’s more than a couple ways to skin this cat!

[[support] Bungy's docker repository]

5 hours ago, Profezor said:

I know this is probably a simple question but it has me stuck.

 

Running 6.9

Running NZBGet fine.

Trying to get NZBGETVPN to work. When I get GUI . I get and error  - page can't be reached.

 

I have set port to. -6789

I had added my user/pass to VPN account

What am I missing?

I say Space Invader's Deluge vi so I added the .crt file and the vpn server config file to the OpenVPN folder as well just in case. My provider does not have a .rem file.

 

Since I have worked with NZBget for years it would be nice to get this vpn version working.

 

Thanks in advance.

 

Doesn’t really answer your question as to why you can’t get NZBgetVPN working but with some recent changes, it might be worth looking into binding non-VPN comtainers to a VPN container. In this case, Deluge or Jackett seem be the most popular. This would allow you to use the non-VPN version of NzBget with a VPN.

[[Support] binhex - DelugeVPN]

1 hour ago, Squnkraid said:

 

The following containers are routed through DelugeVPN (set this all up following Spaceinvader One's video's)

- Sonarr, - Radarr, - Jackett, - NZBHydra

 

Their ports are listed under VPN_INPUT_PORTS. I changed the server IP's to 'localhost' in settings and they can all communicate with each other and are accessible. No problem there.

 

SABnzbd is outside the VPN connection. It uses port 8282. I have that port listed in DelugeVPN under VPN_OUTPUT_PORTS. But when I try to connect to it within Sonarr etc. it doesn't work. I have local server IP filled in, but also checked 'localhost' and 'container IP', it all comes back with an error. So not sure what I'm doing wrong here. I checked the Q&A section and all is setup like it should, I think. I'm probably overlooking something, but I don't know what.

I had a similar issue testing a Privoxy connection and was relying on the test connection button in Sonarr (Radarr and Lidarr have same). The test always failed so I rolled back the DelugeVPN docker and the test still failed. I was like wtf, then I cleared my queue of downloads and tried to manually initiate a download to see if the *arr dockers would pass to NZBget and sure enough they did but the test connection still fails! I guess the moral of the story is don’t rely on on the connection test and try a download first before thinking it doesn’t work.

[[Support] binhex - DelugeVPN]

On 3/5/2021 at 10:12 AM, binhex said:

did you look at the recommended post at the top of this page?

Yes, but short of installing Jackett (which I tried but none of my indexers are listed), when I bypass internal addresses then my NZBgetVPN doesn’t work with *arr apps (or at least I thought it didn’t because of false negative on Sonarr connection test).

 

It’s probably worth having SpaceInvader post a tutorial for us morons that can’t get things working correctly without rolling back DelugeVPN. There’s so many options on how to connect now that even if I’m willing to change my configuration (which I am), I have no idea which is best for my use case (ie *arr apps, NzBget and Deluge with VPN, Kodi with VPN currently using Privoxy and possibly remote access viewing for Emby which I haven’t really tried but did look into Wireguard and was lost). 🤷🏼‍♂️
 

Edit: didn’t realize I wasn’t running binhex Sonarr docker. Migrating over to it solved my (test) connection issue.

[[Support] binhex - DelugeVPN]

Privoxy user here and rolling back DelugeVPN worked for me. The weird part is I still get an error from Sonarr that it can’t connect but it’s working fine?!
 

also, for 6.9 users, what happened to the shortcut to a docker log on the docker tab?

[[Support] binhex - DelugeVPN]

19 minutes ago, Jorgen said:

Sorry mate, I re-read you initial post and I think I misunderstood your setup.

I thought you were binding the *arr apps to the delugeVPN network, but you are actually just using the proxy, right?

In that case I pointed you in the wrong direction and can't really help as I don't know how NzbGetVPN works.

No worries. Yeah I’m just using Privoxy thru DelugeVPN. In theory, NZBgetVPN should behave just like DelugeVPN except that binnex doesn’t manage a version of it...

[[Support] binhex - DelugeVPN]

3 hours ago, Jorgen said:

There's a fix coming for this, see https://github.com/binhex/arch-delugevpn/issues/258

Ok, so I pulled the latest docker image for DelugeVPN and manually added “VPN_OUTPUT_PORTS” env variable. I set value to port of NZBgetVPN (6789) but still can’t connect to it inside of the *arr containers?

 

[[Support] binhex - DelugeVPN]

2 hours ago, Jorgen said:

There's a fix coming for this, see https://github.com/binhex/arch-delugevpn/issues/258

Although, if you want to run NzbGet through a VPN tunnel, an alternative is to use the normal binhex NzbGet container and bind it's network to the DelugeVPN container. See Q24 here: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Yeah, binding nzbget to DelugeVPN was going to be the next thing I tried.

 

@Rollingsound514: I also suggest replacing tower with your IP address. The only other thing that’s different with Jackett is there doesn’t appear to be a setting for ignoring your local IP addresses. I had the same issue as you gave with Jackett with Radarr/Sonarr/Lidarr until I added my local IP range to the ignore list in the proxy settings of these dockers.  Ultimately, I think we’re in the same boat and should bind these dockers to DelugeVPN.

[[support] Bungy's docker repository]

3 hours ago, Bungy said:

I see - So your sonarr/lidarr/etc are using the http_proxy and no_proxy environmental variables to get VPN access into them.

 

Have you tried setting your no_proxy env variable to 192.168.1.71 and then in sonarr set your nzbget server to be 192.168.1.71:6789?

 

Alternatively, if you have local DNS, you can set your no_proxy to something like:

no_proxy: *.local,192.168.1.71

 

I'm using internal DNS to get a ".kube" domain address and then telling it not to use the proxy for all *.kube lookups.

Sorry, this is a little over my head. Are you saying there’s a no_proxy env variable in NZBgetVPN?

 

Attached is how I have Radarr (and Sonarr/Lidarr) setup to use Privoxy thru DelugeVPN. To get it working with the latest version of Deluge, I had to include my server address in the ignored addresses list. Then I was able to connect to both my indexers and the Deluge download client from within each docker. However, with these settings I lost the connection to NZBgetVPN from within the dockers using Privoxy.

 

 

[[support] Bungy's docker repository]

4 hours ago, Bungy said:

Can you confirm your LAN network is in fact 192.168.1.0/24? What's the IP address on the machine you're currently using?

 

You can try to set the LAN_NETWORK to 0.0.0.0/0 and confirm that the traffic isn't being blocked. That'll verify that the issue is with your setting of that environmental variable. Then you'll need to figure out your docker network address + subnet and include that in the LAN_NETWORK variable. Here is what mine looks like but I have multiple networks and run my containers on a kubernetes cluster, so yours will likely need to differ as well:

192.168.1.0/24,192.168.0.0/24,10.253.0.0/24,10.32.0.0/12

 

The issue is not related to the ADDITIONAL_PORTS variable. Those were actually removed from binhex's containers and are no longer documented in his github Readmes.

My server address is 192.168.1.71 so I was using 192.168.1.0/24 as my LAN_IP setting in both DelugeVPN and NZBgetVPN. With the DelugeVPN update, you’re right that ADDITIONAL_PORTS env variable is not my issue but it is in fact being used by Binhex for DelugeVPN when binding other dockers to Deluge network. I added this variable AND set dockers (ie Sonarr, Radarr, Lidarr etc) to ignore my internal ip addresses under proxy settings for each since I’m using privoxy. The latter is what enabled these dockers to connect to Deluge as a download client but now I’ve lost NZBget functionality (meaning the dockers can’t connect to it as a download client but I can access the webui of NZBgetVPN  with VPN enabled).

[[Support] binhex - DelugeVPN]

10 minutes ago, RollinDolan said:

Thanks for the tip on the server IP.

 

As for the first issue (Jackett) - shouldn't I NOT do that, if I'm trying to use Jackett as recommended. (As opposed to routing Sonarr and Radarr each through privoxy individually.)

No worries. I'll just wait for someone to come along and ask the exact same question so we can both find a solution.

Sorry, thought you were using Privoxy. If you’re using Jackett then net binding to Deluge is probably your best option.

[[Support] binhex - DelugeVPN]

Anyone here using NZBgetVPN along with DelugeVPN? I’m using privoxy for Radarr/Sonarr/Lidarr etc thru DelugeVPN and I’m able to connect to my indexers and DelugeVPN through each docker (after putting my server address in the ignore list) but now NZBgetVPN isn’t able to connect since the update to DelugeVPN. I assume this issue is related to the one referenced prior about dockers “outside the VPN” communicating with dockers inside it but then again, I’m using privoxy so not sure it’s the same issue? Can anyone confirm? Bungy (docker creator for NZBgetVPN) is asking about my network LAN_IP setting but this hasn’t changed (ie UnRAID server is 192.168.1.71 and LAN_IP setting is 192.168.1.0/24).

[[Support] binhex - DelugeVPN]

14 minutes ago, RollinDolan said:

Sorry, can you explain this?

 

Deluge does not have "ignored addresses" in its proxy settings. Do you mean I should change the "ignored addresses" in the proxy settings for Radarr and Sonarr? Because as stated, Sonarr and Radarr aren't having any issues connecting to Deluge.

 

The issue is that Jackett cannot connect to any indexers ("Found no results while trying to browse this tracker"), which I think means Jackett cannot talk to Privoxy? 

 

I just want things to function as they originally did

 

EDIT - is there also no way to set the IP address to the name of my unraid server? It would be much easier to maintain if I could enter "tower" rather than an IP address which isn't guaranteed to remain static.

You set the ignored address in the proxy settings of the dockers using the proxy (eg Sonarr, Radarr etc). DelugeVPN doesn’t need any change.

 

As far as your server IP, just give it a static IP from your address range. I reserve the address in my router and set UnRAID to always assign the same address under network settings.

[[support] Bungy's docker repository]

17 hours ago, Bungy said:

 

Make sure your LAN_NETWORK environmental variable is set properly to allow access from your sonarr/radarr/lidarr ip address. I have mine set to handle local network traffic as well as docker network traffic. You can set it to 0.0.0.0/0 to allow all inwards traffic, but that's not recommended.

I have it set to 192.168.1.0/24 (see attached). I’m not sure if you’re in touch with binhex but perhaps you could modify the nzbgetvpn container for this “Additional_Ports” env variable to work like delugevpn?

 

[[support] Bungy's docker repository]

Since binhex updated DelugeVPN for tightened iptables, I can no longer get Sonarr/Radarr/Lidarr to connect to NZBgetVPN download client. DelugeVPN is working with an additional variable (Additional_Ports) with the value of the ports for each docker but I’m assuming this will have no impact on NZBgetVPN?!

[[Support] binhex - Jackett]

New to Jackett due to the tightening of iptables issue. Am I correct in assuming that if my indexer isn’t listed then this docker is of no use or could I still use it to route download clients thru? Using nzbplanet for nzb’s and rarbg for torrents.

 

On a side note, I was using Privoxy to route Sonarr, Radarr and Lidarr thru DelugeVPN. Adding the “Additional_Ports” variable for these dockers to DelugeVPN and ignoring my server’s IP address has restored the download client connection to DelugeVPN but not NZBgetVPN. Assuming I can’t make the same changes to NZBgetVPN because a docker update would be required to recognize the Additional Ports variable? Is there a fix to get NZBgetVPN working similar to DelugeVPN or should I bite the bullet and bind these containers to DelugeVPN?

[[Support] binhex - Preclear]

2 minutes ago, Frank1940 said:

Try this:

 

Doh! I'm helping a friend remotely and didn't realize there was a menu in the VNC window since i wasn't doing it myself.

 

Thanks for your guide as well. Maybe worth adding a section on preclearing multiple drives would be beneficial?  Either way, thanks for the response.

[[Support] binhex - Preclear]

Could someone please provide a little more detail on running mulitple preclears with this docker?  I read this:

 

Q5. Can i preclear multiple disks at the same time?.

A5. Yes this is possible, you simply create an additional 'tab' in the 'Xfce terminal' and then run the script again against the additional named drive.

 

But I'm unfamiliar with how to create an additional tab in the XFCE terminal.  Is another docker/plugin required?  Thanks.

[Wake on LAN problem on Gigabyte board]

6 hours ago, Vr2Io said:

It you excute "wol g" before shutdown and no ethernet link established after, then you may can't solve that. From my experiences, no BIOS setting would help.

 

A simple method was add a cheap NIC to solve.

I didn’t put the -g command in go script but when I checked ethtool on eth0 it was there. I have another UnRAID sever on my network that wol works so I believe it is server (hardware) specific. Thanks

[Wake on LAN problem on Gigabyte board]

6 hours ago, Vr2Io said:

Just enable "PME Event Wake Up" ..... What method and tools you send wake-up packet ?

 

Thanks for your response. These are my exact settings and the issue is when the server shuts down the lan is completely powered off (no light). I also tried enabling lan boot rom in the advanced settings to no avail.

[Wake on LAN problem on Gigabyte board]

I’m trying to setup WOL on a Gigabyte GA-EP45-UD3P (rev 1.0 bios ver F10) to work. No matter what bios settings I use (lan boot rom enabled, PME event wakeup enabled, Power on by Ring enabled, S3 sleep type etc) I can’t get the lan to stay awake (orange light) when server is shutdown. Also checked UnRAID and WOL g is set on eth0.  Would be great if someone knew the bios settings of these Gigabyte boards to help. Lots of conflicting info doing a search but as I said, I’ve tried all combinations and can’t seem to get pas this first step of keeping the lan “on” so the server can receive a WOL packet.