binhex

can be ignored. ok so i have just tested it connecting to cambodia via wireguard protonvpn and the port is correctly assigned and qbittorrent is correctly configured and once i add in a torrent then the orange flame turns into a green globe to indicate port forwarding is operational, so i cannot reproduce it at present 😞

ok thanks for the info, leave it with me, i did do extensive testing with protonvpn and i have a 1month subscription so i can test it, but unless something has changed this WAS working with the current image.

wireguard or openvpn? also which country endpoint are you using?

When you say maintenance mode, what exactly do you mean? is there a message on the plex web ui telling you its in maintenance mode?.

why do you have a vm, what is the purpose of this?, all you need is this container running, it includes qbittorrent web ui and all required tooling to connect to a vpn provider. EDIT ahh ok i read up a bit further, so the container is running just fine and your qbittorrent app running in your vm is not, im afraid that's out of scope for this support thread, i only support the container, if you are trying to setup a vm running qbittorrent then you are on your own, sorry.

Please see Q15 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md In short your router has nothing to do with port forwarding whatsoever when using a vpn.

See Q5:- https://github.com/binhex/documentation/blob/master/docker/faq/plex.md

Ive spotted the issue!, the code to modify the ovpn file was nested in the wrong if block, fixed it, please pull down latest image just built and you should be good.

most probably, yes, i would suspect your database(s) is corrupt due to the lack of space, your options are:- 1. restore your sqlite database from backup 2. delete the database file, restart the container and reconfigure the database files will be located at /config/jellyfin/data/data/

@Tpole @modsa @Yock as i cannot reproduce the issue i decided to simply re-create the image, please issue a 'force update' to pull down the image just built and see if it fixes the issue.

can you try issuing the commands in my previous post.

the is the exact fix i have implemented via code, i simply do not understand yet how it works for me and appears to be completely missing for you, even though we are both using what appears to be the same image!. ok can you go to the 'console' of the container and then copy and paste the command below:- grep -P -o 'crl-verify' < /root/start.sh if you have the latest image then this will return 4 matches which will printed to the screen, like so:- sh-5.2# grep -P -o 'crl-verify' < /root/start.sh crl-verify crl-verify crl-verify crl-verify if nothing is returned then you are out of date, please let me know the outcome.

I will need to see the log to help further, please see the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md#unraid-users

ok so sadly that doesnt give me much a clue apart from i can see the obvious issue which shouldnt be occuring, namely the CRL failing, that should be stripped from the ovpn file. ok can you try the following:- stop the container go to host (unraid) 'terminal' type 'docker pull binhex/arch-int-vpn:latest' type 'docker pull binhex/arch-qbittorrentvpn:latest' exit out of the terminal start the container and try openvpn again

ok so i have copied and pasted your config and restarted the container i have setup for testing and it modified the ovpn file correctly and the web ui for qbit is accessible (vpn tunnel established), so im not too sure whats going on yet. Can you left click container icon, select edit and paste the output from 'Repository' here.

ok so this file should be modified to strip out CRL and set compression, but for some reason this is not happening, I am guessing its related to line endings, can you open the ovpn file with notepad and look at the bottom right does it say CRLF or Unix (LF)? it should be LF, snippet:-

i need to see the entire file really including certs as the issue is around the CRL cert, there is no need to strip it as authentication is done via username and password not inline cert.

can you please include the contents of file /config/openvpn/<name of your ovpn file>

To be honest, i dont see how that is possible with the settings you have, it would be of been transcoding to /dev/shm inside of the container, which for my containers is a measly 64MB in size, this MAY be the source of your disk space related issue.

Yeah so that is incorrectly setup, you have a host path /dev/shm that bind mounts to /transcode, that is all good, you then set TRANS_DIR to point at the host path /dev/shm, this is not right, it should be pointing at '/transcode'. Keep in mind env vars (container variables) are defined inside of the container, so you have to use container paths not host paths, the host path will not be accessible.

one thing i have spotted in your supervisord.log is this:- So using /dev/shm SHOULD be ok, do you have a bind mount for that, a screenshot of 'unraid webui/docker/plex/edit' container settings would help.

yes please

i could still do with those logs guys:-

The CRL issue is for VPN provider PIA only, AFAIK no other providers have this issue, so you should be fine with AirVPN.