Everything posted by binhex
-
[Support] binhex - Plex Pass
Yep confirmed, from your log:- Database corruption: sqlite3_statement_backend::loadOne: database disk image is malformed See Q5:- https://github.com/binhex/documentation/blob/master/docker/faq/plex.md
-
[Support] binhex - Nicotine+
Sorry i cannot support GlueTunVPN.
-
[Support] binhex - Nicotine+
In a word, no, instead network sharing is where I'm trying to go with any future docker images, maintaining VPN enabled docker images is hard work so i would prefer to keep the workload as light as possible and leverage existing VPN connectivity instead, as mentioned above I am working on a solution to read in the incoming port from a VPN enabled docker container, the tricky part is reconfiguring Nicotine+ when the port changes.
-
[Support] binhex - Nicotine+
i am doing just this, routing nicotine+ network through privoxyvpn, but you could use any of my vpn images to do this, and yep at present there is no mechanism to get the assigned incoming port, but i am working on a cunning plan to pass the info so you can see what the port is set to.
-
[Support] binhex - Nicotine+
are you guys not seeing the wizard on initial startup of nicotine+ where it asks you to create a username and password? screenshots from the container:- so basically enter in whatever username and password you like, obviously you will need to have a unique username that is not already in use and you should be good!.
-
[Support] binhex - qBittorrentVPN
OK that makes sense to me, so for obvious reasons I have to permit outgoing and incoming traffic to the VPN endpoint in order to establish the VPN tunnel in the first place, and thus iptables permit this. qBittorrent is a very chatty Bittorrent client and it will communicate on all adapters by default, including the LAN adapter, and as the VPN endpoints have to be open qBittorrent may (not always) attempt to connect to the VPN endpoint over the LAN, obviously it would fail as the VPN endpoint is not a Bittorrent client. But i hear you cry, can't you simply tie qBittorrent down to use just the tunnel adapter?, well yes you can and i do exactly this by editing the configuration file before qBittorrent starts, but it appears qBittorrent does not always (looks to be random) pick this setting up straight away, leading to this approx. 1 second delay before switching to talk only on the tunnel adapter (as defined in the config file), so i can only assume this is a bug in qBittorrent - it should be reading the configuration and binding to the adapter BEFORE attempting any communication. In any case, this in my opinion is NOT an IP leak, your VPN provider already knows your ISP assigned IP address by this point and obviously a lot more besides, you are not talking to another Bittorrent client so there has been no peer to peer communication taking place and thus the risk is extremely low (in my opinion it's zero).
-
[Support] binhex - qBittorrentVPN
@Matrix another question whilst you get the log, the obfuscated IP address for the 'Server' in your screenshot, if you do a IP lookup of that IP address does it match the VPN Endpoint you are connecting to?.
-
[Support] binhex - qBittorrentVPN
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
-
[Support] binhex - qBittorrentVPN
How are you using this docker image?, are you simply using the built in vpn or are you sharing networking with another container?, any use of socks4/5 proxy or similar?.
-
[Support] binhex - Nicotine+
OK, i was just checking. Also do keep in mind you have in effect shared your entire array, as you have set:- And as /media is pointing at /mnt/user/ that is all user shares, if i did this in Nicotine i can guarantee it would either stop working due to sheer volume of content to index or would take days/weeks to index, thus i think this is the reason for your - 'it's just very slow & lags a lot/locks up!', i would recommend only sharing what you REALLY want to share, or at the very least share it in media type chunks e.g. /media/Movies, /media/TV, /media/Music etc. EDIT - Actually I'm talking bollox, you have specified /media as /mnt/user/Music (could of sworn it was set to /mnt/user), so that SHOULD be fine, how large a music collection do you have in Gigabytes? for reference i am currently sharing around 130 GB and so far have not observed any slow down or lock outs, the media share index scan took about 30 mins.
-
[Support] binhex - Nicotine+
so does '/mnt/user/mediashare/torrents/Nico+/Nico+' exist? cos that's what it is in effect by specifying '/data/Nico+', I assume it doesn't and should actually be:- shared = [('media', '/media'), ('Nico+', '/data')]
-
[Support] binhex - Nicotine+
OK open the following file with notepad++ or notepad:- /config/home/.config/nicotine/config then look for this line, here is what mine looks like:- shared = [('Dance', '/media/Albums/Dance')] Paste that line here, I suspect its incorrectly defined and thus nicotine has its knickers in a knot cos it cannot index it to share the files.
-
[Support] binhex - Nicotine+
so whats defined in nicotine/settings/shares? screenshot please also left click the container select 'edit', change something, change it back to what it was and click apply at the bottom and paste the output text here.
-
[Support] binhex - Nicotine+
Glad you got it sorted, i am also sharing networking with privoxyvpn for Nicotine+, its working a treat!, im currently coming up with a ingenious plan to share the assigned incoming port so i can then configure Nicotine+ to use it.
-
[Support] binhex - Overseerr
TBH you are better asking about this in the Nginx Proxy Manager support thread you will get more replies as the issue is around NPM and not the Overseerr Docker image.
-
[Support] binhex - Nicotine+
Reserved
-
[Support] binhex - Nicotine+
Overview: Support for Docker image arch-nicotineplus in the binhex repo. Application: Deluge - https://nicotine-plus.org/ Docker Hub: https://hub.docker.com/r/binhex/arch-nicotineplus/ GitHub: https://github.com/binhex/arch-nicotineplus Documentation: https://github.com/binhex/documentation If you appreciate my work, then please consider buying me a beer For other Docker support threads and requests, news and Docker template support for the binhex repository please use the "General" thread here
-
[Support] binhex - DelugeVPN
from your log:- AUTH: Received control message: AUTH_FAILED Please see Q16 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md
-
[Support] binhex - DelugeVPN
nothing wrong in that log file, just checking though, what is the ip of the machine running the web browser that you are using to connect to the applications web ui?.
-
[Support] binhex - DelugeVPN
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
-
[Support] binhex - Plex Pass
from your log:- attempt to write a readonly database so either the database is corrupt or your permissions are screwed up, start with looking at permissions first.
-
[Script] binhex - no_ransom.sh
why not simply run a cron job, this is what i do.
-
[Support] binhex - DelugeVPN
from your logs:- AUTH: Received control message: AUTH_FAILED Please see Q16 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md
-
[Support] binhex - qBittorrentVPN
from your log:- AUTH: Received control message: AUTH_FAILED Please see Q16 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md
-
[Support] binhex - Plex Pass
Def be patient, but if it does take more than a few hours and you see no progress in the log then it maybe stuck again, fingers crossed it will go through for ya.