binhex

i see the issue, i had switched over upstream package name to add in arm suport but forgotten to update my python trigger script, this is now fixed and a new image has been manually pushed out, please update at your convienience. Note:- As notes this is a major bump from v1 to v2 so there MAY be breaking changes here!.

I do remember, sorry for the delay in getting back to you i have been floating around on a very large boat for 2 weeks :-), I shall take a lookover the changes and suggestions and get back to you.

Just as a side note here, please do not use built in update functionality for any docker applications, it will likely result in a broken container,wait for the dev to update the image.

Hi, sorry for the delay, i have been sitting on a very large boat for 2 weeks :-). OK ive taken a look at the issue and its simply that the syncthing dev's have made a breakiing change to the cli options, so you now need to specify double hyphens for the cli options, changed my start script and its built and gone through my smoke test and passed, so the new release is now there.

I try and not build from non releases to keep the support maintenance down to a minimum, for now i would recommend switching to the previous release of plex to keep you working until there is a new release from Overseer to address this (i would assume this will happen quite quickly!). If there is still no release in a week's time then i will re-evalute this and possibly slip in a temporary build from branch. If you want instruction on how to roll back o a previous version then please see Q5:- https://github.com/binhex/documentation/blob/master/docker/faq/unraid.md

Ok and the health of the container is showing as unhealthy still?

can you try pulling the latest image just built.

if the container is showing as unhealthy then the application process in the container has died and/or the container cannot connect to the internet. To get more of a clue as to which it is left click the container and select 'console' then type healthcheck.sh it should then report what is going on.

ok this is what i think has happened: your urbackup clients were happily connecting to urbackup server locally over the lan - happy days something/someone ticked the option to set the urbackup clients to connect over the internet, the default 'server url clients connect to' was left as a blank url 'urbackup://' (invalid url). your urbackup clients get pushed the change from the server to connect over the internet instead of the lan and the client accepts the change, including the badly defined url. voila! your urbackup clients now have broken connectivity, they are attempting to connect over the internet to a urbackup server url of 'urbackup://' and failing to connect, and changing the option back on the server now does nothing, because the clients are not listening for the server over the lan (incorrectly configured). So how do you get out of this?, easiest way is to right click the systray icon for the urbackup client, select settings/internet tab and untick the option enable backup via internet: note: ensure you do NOT have the option set on your urbackup server 'clients try to connect via internet/active client' otherwise you will be going in circles as the server will auto reconfigure the client again and break connection.

You seem to have your clients set to connect over the internet (from your screenshot), untick that option if all clients are on the same LAN.

A quick gift - I have setup a GitHub re-occuring action to generate the list of PIA port forward enabled endpoints, the output is to a public Gist in markdown format, feel free to reference if you want to switch endpoint and you can't be arsed to go searching through your supervisord.log: https://gist.github.com/binhex/0d8bc1974bad90f8a61d2d4219ef862c Note: The URL is NOT expected to change, if it does i will edit the post here.

A quick gift - I have setup a GitHub re-occuring action to generate the list of PIA port forward enabled endpoints, the output is to a public Gist in markdown format, feel free to reference if you want to switch endpoint and you can't be arsed to go searching through your supervisord.log: https://gist.github.com/binhex/0d8bc1974bad90f8a61d2d4219ef862c Note: The URL is NOT expected to change, if it does i will edit the post here.

A quick gift - I have setup a GitHub re-occuring action to generate the list of PIA port forward enabled endpoints, the output is to a public Gist in markdown format, feel free to reference if you want to switch endpoint and you can't be arsed to go searching through your supervisord.log: https://gist.github.com/binhex/0d8bc1974bad90f8a61d2d4219ef862c Note: The URL is NOT expected to change, if it does i will edit the post here.

The image included the latest beta trial key, that trial expired on the 1st Aug and as of right now there is no new trial key, so you either need to wait and hope a new trial key comes out or purchase the software to get a permanent key, see here for discussion https://forum.makemkv.com/forum/viewtopic.php?f=1&t=38742 Edit - It looks like purchasing of a new key is also not going through right now, so if you were relying on the trial keys then your only hope is to wait and pray that Mike (main admin) returns and generates a new trial key.

is there a specific reason you need your urbackup clients to connect to the server over the internet?, mine all connect within the LAN:

My existing vpn containers can do what gluetun is currently doing, the advantage with gluetun is that it is a lot more configurable, it has a TON of options and built in support for most popular vpn providers, including airvpn. It also has a nice built in web server that can be ued to get the assigned incoming port and then share it with other containers, this is how i am setting the incomng port for qbittorrent. The disadvantage to gluetun is there are TON of options which can be overwealming for newbie's, it also does not include any application, so the end user would need to figure out how to route containers through gluetun, once figured out though it is a really slick solution. For me personally i have now setup 3 separate gluetun containers, 1 for qbittorrent exclusive use, 1 for nicotine+ and 1 for gneeral non port forward related containers (e.g. sonarr, hexchat, etc), so far its been rock solid, the only drawback is PIA is only supported via openvpn and i am with PIA.

verify you have set things up correctly, please see Q24 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md if this does not fix it then I will need to see a log to help further, please see the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md#unraid-users

im going to need to see the full log, attach /config/supervisord.log - fwiw i run sonarr myself and am on latest with no issue.

Then your issue is definitely not healthcheck related, if the container goes unhealthy then it previously rebooted the container, now it should do nothing when unhealthy (unless instructed to do so), and as its currently listed as healthy it seems very unlikely to be healthcheck. Do you run CA backup by any chance?, that can (if configured) cause the container to be paused or even restarted during the backup process, so look at that. Also check your syslog, you maybe running low on RAM, in which case out of memory killer (seen in the syslog as OOM Killer) will kill any processes using high RAM that are in a idle state, Plex is probably such a process and could be killed, solution is more RAM or less processes running.

hmm ok, one last check, if you open the rclone config file using windows noptepad, what does it say the line endings are? (bottom right) will say something like LF or CRLF.

So going back to your original problem, what exactly do you mean by this?, no download?

You are listing the rules using iptables -L try printing the rules instead iptables -S you will then see that the last two rules are actually tied to specific adapters, in this case loopback and the tunnel adapter.

ok one last thing to verify, can you left click the container, select 'console' and then copy and paste the following and execute: cat /config/rclone/config/rclone.conf does the output of the command above return the contents of the expected config file?.

yep, ta. so this is the bit of info i was after, so it appears that you are putting the config in the right place, to confirm the rclone config should be located at: (you did name the config file rclone.conf, right?) /mnt/user/appdata/binhex-rclone/rclone/config/rclone.conf

that is probably a cookies/caching issue, clear cookies and the site data, or try an incognito window.