2 hours ago, binhex said:

 

By the looks of this article I would say it is advisable to update, yes:- https://sharpsec.run/rce-vulnerability-in-qbittorrent/

AFAIK there have been no attacks in the wild yet, but it's better to be safe than sorry (i have updated).

I went to check my qbit and it shows version 4.6.3. I tried running a check for updates, force updating, and I even removed the container/image and pulled it from "previous apps". It still shows the same as what is in my screenshots. Am I missing something? Is the web UI version number different than the actual qbit version? Does this have anything to do with being on the binhex/arch-qbittorrentvpn:libtorrentv1 repo? Just want to make sure I don't leave myself open to the current vulnerability.

 

 

14 minutes ago, Zacaronii said:

Does this have anything to do with being on the binhex/arch-qbittorrentvpn:libtorrentv1 repo?

Yes, you've forced it to a 10 month old tag.

 

35 minutes ago, Kilrah said:

Yes, you've forced it to a 10 month old tag.

 

 

On 7/5/2024 at 7:03 PM, nraygun said:

Once unRaid 7 comes out, we can revert to using the regular Qbittorrent with libtorrentv2 since the kernel is going to 6.8.12, right?

Seems like there was a kernel fix for this a while back: https://github.com/arvidn/libtorrent/issues/6952

 

On 7/7/2024 at 2:59 AM, binhex said:

correct again

 

I see, I was under the impression that using the libtorrentv1 tag was still necessary, until Unraid 7 comes out and we get a kernel update. I did not realize that tag was so far behind. I know I started using that tag, because I was having issues. I suppose I will go ahead and update to the latest tag and cross my fingers. I'd rather do that than continue to be on a version with a known vulnerability. 

What's the easiest way to downgrade back to 4.x?  I went through the whole fiasco of the username and pass, was able to get into it by turning the VPN in the Qbit docker settings, got everything changed, added my vpn network/subnet to the settings, and still can't get in unless I turn the vpn setting off. 

5 hours ago, binhex said:

 

By the looks of this article I would say it is advisable to update, yes:- https://sharpsec.run/rce-vulnerability-in-qbittorrent/

AFAIK there have been no attacks in the wild yet, but it's better to be safe than sorry (i have updated).

Thanks! 

 

I have my repository for my instance in unraid pointing to "binhex/arch-qbittorrentvpn:4.5.4-1-03"

 

How can I point this to 5.0.1? Is it safe to update from this repo? 

49 minutes ago, Roncore said:

What's the easiest way to downgrade back to 4.x? 

Just add a colon and tag number after the name in the container repository field. You can find tag numbers from the dockerhub link in the first post.

11 minutes ago, urbanracer34 said:

How can I point this to 5.0.1? Is it safe to update from this repo?

Just delete the colon and tag number in the repository field.

9 minutes ago, wgstarks said:

Just add a colon and tag number after the name in the container repository field. You can find tag numbers from the dockerhub link in the first post.

Thanks! How can I back up my data I currently have before I pull the pin? 

7 minutes ago, urbanracer34 said:

Thanks! How can I back up my data I currently have before I pull the pin? 

Hopefully you are using the appdata backup plugin to make regular backups but you could also use dynamix file manager plugin to make a copy of the binhex-qbittorrentvpn folder.

12 minutes ago, wgstarks said:

Hopefully you are using the appdata backup plugin to make regular backups but you could also use dynamix file manager plugin to make a copy of the binhex-qbittorrentvpn folder.

I haven't set it up yet.

 

I used the Dynamix plugin to make a copy of the data to another share. I then attempted to copy it to my mac and it said the folowing error: "The operation can’t be completed because you don’t have permission to access some of the items."

 

I even took the copy and set the owner to my unraid user. Same error. 

1 minute ago, urbanracer34 said:

I haven't set it up yet.

 

I used the Dynamix plugin to make a copy of the data to another share. I then attempted to copy it to my mac and it said the folowing error: "The operation can’t be completed because you don’t have permission to access some of the items."

 

I even took the copy and set the owner to my unraid user. Same error. 

I wouldn’t mess with the permissions of the copy. Every docker sets its own permissions required by the app. Just make another copy to the share and it’ll be there in the unlikely circumstance that you might need it. If you don’t need it you can just delete it later.

On 11/5/2024 at 7:18 PM, binhex said:

@plantsandbinary This is your first issue:-

 

Note how the container port 8080 is not the same as the host port 8128, Please see Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/qbittorrentvpn.md

 

This worked perfectly. I couldn't find this info previously. Thank you SO much. WOW. It finally works!

I'm having an issue where I'm trying to route another container through this VPN container.

I've managed to set it up and everything is working alright, except that the container being routed is a iptv streaming app. Every channel and epg is fetched ok, but when I try to stream a channel through the VPN to ffmpeg, and pass it on to let's say VLC, it fails.

Any clues on why?

11 minutes ago, kjettern said:

I'm having an issue where I'm trying to route another container through this VPN container.

I've managed to set it up and everything is working alright, except that the container being routed is a iptv streaming app. Every channel and epg is fetched ok, but when I try to stream a channel through the VPN to ffmpeg, and pass it on to let's say VLC, it fails.

Any clues on why?

Check you have performed all the steps in Q24 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

16 hours ago, binhex said:

Check you have performed all the steps in Q24 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

I did. Everything inside the container is working like it should, except for the ffmpeg playback. I've also used terminal to check if the IP is correct and it is behind the VPN. People are reporting that other VPN containers like Gluetun is working like it should, so I really can't figure out why the binhex is failing

1 hour ago, kjettern said:

I did. Everything inside the container is working like it should, except for the ffmpeg playback. I've also used terminal to check if the IP is correct and it is behind the VPN. People are reporting that other VPN containers like Gluetun is working like it should, so I really can't figure out why the binhex is failing

As its a stream you may need to add in a port with connection type UDP, give that a shot.

I only just now learned that one can run containers through other containers' VPN and tried it with jDownloader following the instructions given at https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md,  Q24 and Q4.

Result is the container works flawlessly and I can manage it through myjDownloader.org but I can't access the Web UI locally. Assuming that I don't really understand the principle behind it, I am uncertain whether the "any non conflicting port number" in "Enter in the applications Web UI port for 'Container port' from your list taken earlier in step 4. above and any non conflicting port number for 'Host Port' (host port must not be used by another container)." actually means that I should use any wild  port no. that is not in use on the NAS so far? And would it have to reappear somewhere else?

Would I use the "Container port" or the "Host port" to access the jDonwloader Web UI?

 

Also I am uncertain how to make sure I follow Note 1 (if relevant).

Edited November 8, 20241 yr by whauk

1 hour ago, whauk said:

Would I use the "Container port" or the "Host port" to access the jDonwloader Web UI?

I use the webUI port number for jDownloader. If you have everything configured correctly this will be in the VPN Input Ports setting in the qbit container.

Thanks, that is what I did.

And about the "Host port" - any port no. will do? And I can still access the NAS with http://local_IP:Web_UI_port_no.?

1 hour ago, whauk said:

Thanks, that is what I did.

And about the "Host port" - any port no. will do? And I can still access the NAS with http://local_IP:Web_UI_port_no.?

Correct. Any port not used by some other container.

Thanks again, that's also what I did.

How about accessing the Web UI? From within my LAN it's still http://local_IP:Web_UI_port_no.?

1 minute ago, whauk said:

Thanks again, that's also what I did.

How about accessing the Web UI? From within my LAN it's still http://local_IP:Web_UI_port_no.?

Yes. The local IP of the qbit container.

Ok, that seems to be a misunderstanding. The qbit container does not have a separate IP - the NAS has a local IP. I differentiate containers only by port nos. If I address the qbit container by its port no. I get the web UI of the qbit client. If I address the jDownloader container by its Web UI port no. I get an error message.

Edited November 8, 20241 yr by whauk

Hi

 

OVPN has some maintenance and that is fair.

 

But is it possible to have more "VPN wireguard configs" ? Just if one is down then it trys another?

 

Hope it makes sense

 

Thanks!

1 hour ago, whauk said:

Ok, that seems to be a misunderstanding. The qbit container does not have a separate IP - the NAS has a local IP. I differentiate containers only by port nos. If I address the qbit container by its port no. I get the web UI of the qbit client. If I address the jDownloader container by its Web UI port no. I get an error message.

Why don’t you post your docker run command for qbit as well as the qbit supervisord log.