binhex

that is the correct path, just created container from latest:- looks good to me.

Fuck me! What a torrent of abuse! You do realise @ich777 and other key developers are doing this for FREE, in their OWN time right?!? We don't paid and certainly shouldn't have to put up with shit like this!,you think you can do better, fork it and go see how easy it is, Sheesh please don't come to any of my support threads with an attitude like that. Sent from my SM-T970 using Tapatalk

this is expected, if you want to run a minecraft server less than version 1.17 then you need to specify JAVA_VERSION 8.

before you walk out the door, how about a quick look at your logs, please do this:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md

thanks for this!, hard for me to test as i dont run java minecraft, so its nice to hear it does work ok.

In preparation for Minecraft 1.18 I have bumped up the version of Java from 16 to 17 in the latest image. My understanding is that the current release 1.17 should work fine with Java 17, if you find this is not the case then please let me know

In preparation for Minecraft 1.18 I have bumped up the version of Java from 16 to 17 in the latest image. My understanding is that the current release 1.17 should work fine with Java 17, if you find this is not the case then please let me know

In preparation for Minecraft 1.18 I have bumped up the version of Java from 16 to 17 in the latest image. My understanding is that the current release 1.17 should work fine with Java 17, if you find this is not the case then please let me know Sent from my CLT-L09 using Tapatalk

Yes the issue was with pia DNS which has sadly stopped working, so removing pia DNS from the list will get you going again. Sent from my CLT-L09 using Tapatalk

this is interesting, the warning you are seeing is out of date leading me to think ive either not rebiult the image with my latest changes or you are not up to date and havent pulled down the latest image. whichever it was to ensure the latest image is built i have triggered a build, please pull down and re-test.

thanks for posting this, i had completely forgotten about this issue, too many damn support threads :-), ok i will take a look and see whats going on, i had one guy test this and he said it worked so im a bit perplexed as to why its broken.

https://forums.unraid.net/topic/44109-support-binhex-delugevpn/?do=findComment&comment=1005634

most probably a vpn issue yes, if you haven't pulled down a new docker image then its highly unlikely that its a coding issue with the container.

whilst i do have a FAQ for doing this it was never the original design to allow routing of containers through this image, having said that i am more than happy to take a look at your code changes, i see what you are suggesting and it sounds plausible enough, please PM or link here.

ip leakage could only occur if the application is running straight away at container start (privoxy and microsocks) which is not the case, as all checks have to be performed before the application can start, so no ip leakage can occur. see here for pre run check BEFORE application starts:- https://github.com/binhex/arch-privoxyvpn/blob/4a7f7ae8f4eac00762fa881a05b52f262d2e75e5/run/nobody/watchdog.sh#L14 link to script sourced in above line:- https://github.com/binhex/arch-int-vpn/blob/master/run/nobody/preruncheck.sh ping is useful for validation and debugging of connectivity.

left click icon, select edit, set DEBUG to true

you really need to have DEBUG turned on (set to true) when the issue happens and then post the /config/supervisord.log file for me to analyse exactly what the cause is.

you really need to have DEBUG turned on (set to true) when the issue happens and then post the supervisord.log file for me to analyse exactly what the cause is.

ok lets start with the most common issue, lan network, from your log:- LAN_NETWORK defined as '192.168.1.0/24' can you check this, Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

correct, the reason is that the processes running inside of the container are not aware of any host port assignments, so you can change the port to anything and the process (in this case privoxy) isnt aware of that change, this is all managed by docker and is transparent to container processes.

simply left click and select 'edit' for the container, go down to NAME_SERVERS and set the value to the following:- 84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1 apply the change.

nope, its never been 8119 for the container port, to be clear here you can choose whatever port you want on the host side (as long as its not in use) and that will work just fine, so you can set it to 8119 on the HOST side no problems.

yes, you should not change the container port, you should only ever change the host port, the container port is hard set to 8118 and cannot be changed.

this is expected when RCLONE_DIRECTION=both , as a local to remote copy will happen first, overwriting changes made to the remote file, then a remote to local sync will happen, its all about what you want to achieve here, if you want to only sync changes from remote to local then set the RCLONE_DIRECTION accordingly, same goes for local to remote.

precisely, a copy will never delete files. if you set RCLONE_DIRECTION=both) an RCLONE_OPERATION=sync then a sync will happen (deleting everything on the remote that is not present on the local - syncs from local to remote first, it will then sync the other direction with nothing to do (all files will already be in a synchronized state).