MarkusMcNugen
-
Posts
38 -
Joined
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by MarkusMcNugen
-
-
4 hours ago, ffhelllskjdje said:
anyone else getting constant disappearing ssh keys ? I set my key for sftp, and it usually works for a day or so, but eventually it always removes my key. I have to go back in user preferences and readd the key. I put my key in /usr/local/lib if it matters.
Are you mounting that folder to the docker host? If not then it wouldn't have persistence.
There is already a volume for persistence that you can use for the container. Check out the docker hub or within pages for the container. You should have /config mounted to the docker host and your ssh key for the SFTP server should go in /config/sshd/keys. You'll probably need to be logged in as root on your Unraid server to get into that folder once you have /config mounted, its locked down pretty hard for security.
-
2 hours ago, jmbrnt said:
First up thanks @MarkusMcNugen for the efforts.
In SFTP my goal is to share a directory from my unraid array with a friend. I create him a user and he can SFTP connect fine, but so far no amount of trial and error has successfully shared the files with him. What do I need to add to the container under Unraid to make this work?
Say I wanted him to log in and see the content of my /mnt/users/videos dir?
Cheers
SFTP users are jailed in their home directories. If you want to share that folder with him you have to mount /mnt/users/videos inside the home directory for his user profile in the container, something like /home/*usersname*/videos.
Here's an example with a user named josh and a music folder:
https://github.com/MarkusMcNugen/docker-sftp#sharing-a-directory-from-your-computer
I'm sure you can see how this would get rather cumbersome the more users and folders you have. Which is why you can also use a bash script to mount directories in users home folders that are mounted somewhere else inside the container. It's all on the github and dockerhub readmes. If you have any specific questions, ask away.
https://github.com/MarkusMcNugen/docker-sftp#bindmount-dirs-from-another-location
The thing is, since you have access to the sshd_config file you can make edits to it with the unraid root user where you have the sftp container mounted to your host, so you can configure it however you want. Dont want users jailed to their home directory? Want to jail them in a different directory? Want to filter based on user group and apply some options to specific users? All up to you
-
2 minutes ago, skaterpunk0187 said:
I checked the log no plugin error. That will work, I used to pay for them to use with my Synology when I used that but I couldn't remember where I purchased them from. I don't mind paying I just didnt want to pay an arm and leg for a cert to use myself.
Well that sucks, sorry I couldnt help more. If you are just looking for a cert for HTTPS than just use the Swag container with LetsEncrypt and SNI and forward with the reverse proxy to the crushftp http interface. You only really need the LetsEncrypt plugin with CrushFTP if you plan on doing direct HTTPS access from the outside or FTPS. I personally dont use FTPS, I just stick with SFTP and call it good. It's all about the SSH keys at that point instead of a SSL cert.
-
48 minutes ago, skaterpunk0187 said:
I thought I used the CrushFTP 10 version the first time but I used the link and tried that and it still doesn't show in the plugin list. I even tried removing and removing the appdata directory as well and still not there. I guess when I get some time ill look into the reverse proxy since it will allow for other passthrough as well. Thanks for looking into it.
Only other thing I can think of would be to check the CrushFTP.log file and see if it lists some kind of error when trying to read the plugin. I use letsencrypt for HTTPS with the swag container but purchase certs for other things. You can get some super cheap certs these days, ssls.com is where I buy mine.
https://www.ssls.com/ssl-certificates/comodo-positivessl
-
5 hours ago, skaterpunk0187 said:
I'd like to say I'm really liking the CrushFTP container. I have been looking for something like this since I switched to unraid.
I would really like to use the LetsEncrypt plugin. I have downloaded it and copied it to my /*/appdata/crushftp/plugins but I can not get it to load, I have tried restarting and stopping and starting the container and nothing. I'm assuming its a java issue since it says it doesn't work with java 9 & 10. Maybe a feature request to add for an update or maybe I'm going something wrong. Thanks
Did you use the correct plugin file, maybe you grabbed the CrushFTP 9 version? I copied the CrushFTP 10 version to the plugin directory, restarted the container and it's there. 😉
CrushFTP LetsEncrypt Plugin:
https://www.crushftp.com/crush10wiki/attach/LetsEncrypt plugin/LetsEncrypt.jar
-
37 minutes ago, skaterpunk0187 said:
I'd like to say I'm really liking the CrushFTP container. I have been looking for something like this since I switched to unraid.
I would really like to use the LetsEncrypt plugin. I have downloaded it and copied it to my /*/appdata/crushftp/plugins but I can not get it to load, I have tried restarting and stopping and starting the container and nothing. I'm assuming its a java issue since it says it doesn't work with java 9 & 10. Maybe a feature request to add for an update or maybe I'm going something wrong. Thanks
Let me do some testing and see if I can get it to work myself. I can tell you that the base alpine container it's running on uses Java 16.
My setup is a bit funky since I dont want to use a non-standard HTTPS port and I already have a bunch of existing sites behind a reverse proxy. So I use the Swag container with lets encrypt to reverse proxy external HTTPS with SNI to CrushFTP for webdav access and have the other ports forwarded directly to the container through my firewall. That doesnt match up with everyone's use case so Ill need to do some testing myself to see what issues there may be with that CrushFTP plugin and Ill let you know.
-
34 minutes ago, Dent_ said:
CrushFTP
Further playing around, I can access crush on my test server using the edge (chrome) browser, I cannot access crush on my main server through edge. The crushFTP.log looks fine until I try and access crush on my main server then it gets those long log entries. Confusing part, I can access crush on my main server and test server using chrome browser just fine.
If it's working with chrome but not with edge then that leads me to believe it's a cookie or cache issue with the edge browser. If you havent already try clearing those and see if it's working.
BTW, you are all good. You dont have to say what container you are talking about, I was asking fasur87 because it wasn't entirely clear and they didn't provide much info lol.
-
1
-
-
20 hours ago, Dent_ said:
CrushFTP.log 133.71 kB · 0 downloads
Here is the log, only thing I changed is the wan IP. Question, if I change the ports that I want to use in unraid during setup is there a config file somewhere that I also have to edit?
Server is starting just fine. What is the network mode set to? Host? Bridge? br0? However you are accessing the server it's sending a ridiculous HTTP Header that looks like it's meant for Unraid.
-
6 hours ago, fasur87 said:
For me still doesnt works first says port allready used then change port ok ...and then nothing happed some erros
Which container? SFTP? Would help if you could post the logs from the running container.
-
7 minutes ago, Dent_ said:
I probably did something to muck this up. Once installed and the container starts I cant access the ui. When looking at the log this is what I get. Is there a permission I am missing?
Unzipping CrushFTP...
Creating default admin...
Admin user written to:./users/MainUsers/
cat: can't open '/etc/system-release': No such file or directory
CrushFTP is not currently running...
cat: can't open '/etc/system-release': No such file or directory
Starting CrushFTP... OKThat's expected output. Can you send, attach, or post the CrushFTP.log file from the appdata folder?
-
On 8/11/2020 at 10:41 AM, AgentXXL said:
Is there a change log for the docker container update that unRAID/Fix Common Problems notified me about? I assume it's to update the qBittorrent client but as the current container has been rock solid, I'm reluctant to upgrade until I'm aware of what's changed.
No changelog. When I update a container that's simply what it is unless something is broken. I try to design containers so nothing has to manually be done to build an update other than run the build on Dockerhub. I've started using test tags and branches to test updates now after the whole SFTP debacle.
For example, when a build is initiated for qbittorrentvpn it dynamically grabs the latest version number of qBittorrent from their website and then downloads and installs that version. This way nobody has to manually edit the Dockerfile and change anything.
-
1
-
-
On 2/12/2021 at 10:30 AM, Squid said:
If the app / tag the template has listed can no longer be downloaded, it gets blacklisted because it can't be installed at all. It's also the reason why the Update Available is listed as being "Not Available"
Hey Squid,
The container has been fixed, upgraded, and put back up on dockerhub in perfect working order. Is there anything I need to do to get it unblacklisted?
Thanks!
-
On 2/12/2021 at 10:53 AM, WuGing said:
Ah, gotcha. Good to know. I was like, blacklisted?? Cool. Thanks!
Not you, the container was blacklisted because it was broken. The base image it's built on actually broke syslog-ng because of an error they made in it's config file. I didnt have any time to put toward fixing it at the time. I actually just pushed an update that fixes everything and includes a few small improvements.
-
13 hours ago, vyreks said:
Hi,
Recently you updated the docker to version 4.2.1 which broke most (if not all) private trackers as they don't have 4.2.X whitelisted yet. Could you create a tag on dockerhub for latest version on 4.1.X please?I will see if I can do this over the weekend. I usually just build from dockerhub with auto triggers and call it good but I have a VM I use for building as well.
-
On 12/19/2019 at 1:50 AM, je82 said:
Hi!
I was playing around with markusmcnugen/qbittorrentvpn and i cannot get vpn to connect when not having the docker run in "privileged" mode, i feel like i don't want anything to run with elevated permissions unless i really really really have to.
Is there any workaround to get the vpn to work without using the docker in privileged mode?
Thank you!
Nope, with the way docker and VPNs work it has to be privileged mode due to the host sharing the kernel space with the docker.
-
On 12/13/2018 at 8:34 PM, AboveUnrefined said:
Hello!
I'm trying to get the qbittorrent container going but I'm having issues. I'm hoping someone can help me out!
I keep getting this issue while it's starting up:
Error: Nexthop has invalid gateway.This is from the docker log, everything in the qBittorent log looks fine (no errors or any red flags) I can include more if needed:
Fri Dec 14 01:24:57 2018 [VPN] Peer Connection Initiated with [AF_INET]185.80.222.63:443 Fri Dec 14 01:24:58 2018 TUN/TAP device tun0 opened Fri Dec 14 01:24:58 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Fri Dec 14 01:24:58 2018 /sbin/ip link set dev tun0 up mtu 1500 Fri Dec 14 01:24:58 2018 /sbin/ip addr add dev tun0 local 10.10.8.110 peer 10.10.8.109 Fri Dec 14 01:24:58 2018 Initialization Sequence Completed 2018-12-14 01:24:58.890754 [info] WebUI port defined as 8082 2018-12-14 01:24:58.925592 [info] Adding 192.168.45.0/24 as route via docker eth0 Error: Nexthop has invalid gateway. 2018-12-14 01:24:58.958437 [info] ip route defined as follows... -------------------- default via 10.10.8.109 dev tun0 10.10.8.1 via 10.10.8.109 dev tun0 10.10.8.109 dev tun0 proto kernel scope link src 10.10.8.110 172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.8 185.80.222.63 via 172.17.0.1 dev eth0 -------------------- iptable_mangle 16384 1 ip_tables 24576 3 iptable_filter,iptable_nat,iptable_mangle 2018-12-14 01:24:58.994864 [info] iptable_mangle support detected, adding fwmark for tables 2018-12-14 01:24:59.041228 [info] Docker network defined as 172.17.0.0/16 2018-12-14 01:24:59.092341 [info] Incoming connections port defined as 8999 2018-12-14 01:24:59.125368 [info] iptables defined as follows... -------------------- -P INPUT DROP -P FORWARD ACCEPT -P OUTPUT DROP -A INPUT -i tun0 -j ACCEPT -A INPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --sport 443 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 8082 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --sport 8082 -j ACCEPT -A INPUT -s 192.168.45.0/24 -i eth0 -p tcp -m tcp --dport 8999 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT -A INPUT -i lo -j ACCEPT -A OUTPUT -o tun0 -j ACCEPT -A OUTPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT -A OUTPUT -o eth0 -p udp -m udp --dport 443 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --dport 8082 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --sport 8082 -j ACCEPT -A OUTPUT -d 192.168.45.0/24 -o eth0 -p tcp -m tcp --sport 8999 -j ACCEPT -A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT -A OUTPUT -o lo -j ACCEPT -------------------- Adding 100 group groupadd: GID '100' already exists Adding 1000 user 2018-12-14 01:25:00.392667 [info] UMASK defined as '002' 2018-12-14 01:25:00.432182 [info] Starting qBittorrent daemon... Logging to /config/qBittorrent/data/logs/qbittorrent-daemon.log. 2018-12-14 01:25:01.468780 [info] qBittorrent PID: 213 2018-12-14 01:25:01.472233 [info] Started qBittorrent daemon successfully...thanks for helping out and for all the great work!
Not sure how you have this setup, but it looks to me like you have the wrong LAN_NETWORK defined. ip route command seems to show 172.17.0.0/16 as the connected LAN network. You have it set to 192.168.45.0/24.
-
I recently updated the docker manually to force qBittorrent to v4.1.4 since it's been released. I ran into an issue where the Web UI wasn't defaulting to english like it was suppose to if it's blank in the config so the WebUI was showing up as mostly blank. This can be easily fixed by setting the language in the WebUI settings or by editing "/config/qBittorrent/config/qBittorrent.conf", or from the Unraid host "/mnt/cache/appdata/qbittorrentvpn/qBittorrent/config/qBittorrent.conf", and setting "General\Locale=en" in the file.
This is definitely a qBittorrent issue, but if anyone runs into this issue here is the fix. For new installs I set the default qBittorrent.conf file to default the locale to en to avert this issue. The bug has officially been reported to qBittorrent here.
-
On 11/6/2018 at 1:24 PM, MarkUK said:
Hey Markus & all,
I've started using this recently and have found it to be pretty good so far! Only, I've got two (very likely related) problems:
- Sometimes there is data left in /temp/ even for files that have completely finished downloading. This perhaps is by design and I just need to leave it for longer, but otherwise I'm having to clear out /temp/ occasionally?
- The Cache drive was filled up today as the mount must have disappeared. (i.e., what was /mnt/user/downloads/ -> /downloads/ disappeared). There has been an outstanding issue that I believe hasn't occurred again whereby /mnt/user disappears off the entire server - but this is just relating to a single docker. Even after the mount was restored a number of files began downloading off the 'internal' version (within the Docker) and not the 'external' Unraid share. Any idea why? And any idea if there's an straight forward way to make a kill switch or other system that prevents downloads if the mount has disappeared?
I dont think there is much I can do about the temp folder, that sounds like a qbittorrent issue. As for the unmounting issue, that sounds like an Unraid/Docker issue. I dont think there is much that can be done from my end to detect and stop that issue. If it occurs again you may try opening a troubleshooting topic on here and posting your logs.
On 10/13/2018 at 8:16 PM, Dataone said:Yeah can confirm ports dont match on default install. Just need to change 8081 to 8080 and all worked instantly for me.
BTW, any idea of estimated download speeds compared to running on another system/vm? Quite slow compared to VPN on my Desktop but at least it works and is automated.
Sorry about this guys, must have left my personal config for the ports in the default config. It's been fixed now.
On 11/4/2018 at 4:12 PM, Dataone said:I just switched to Mullvad, I was having an issue where it would connect to peers and seeds yet just not download or seed anything. I changed my server from USA to Australia (closer to me) and this problem dissapeared.
However, now whenever I use the UDP protocol I consistently get this error:
Sun Nov 4 20:52:25 2018 AEAD Decrypt error: bad packet ID (may be a replay): [ #256450 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warningsAny clue what could be causing this?
Possibly related?
"This is beyond the scope of openpyn but looks like it's likely that some UDP packets are getting dropped (wifi reception is not that good?). https://airvpn.org/topic/14094-weird-log-entries/
It won't happen if you use "--tcp" but there might be some speed loss."
-
@Everyone
qBittorrentvpn
WebUI and ConnectionPort overwrite issue resolved
I have fixed the stupid issue with the broken WebUI and Connection port environmental variables not setting correctly in the config file. (In fact, everyone should check the qBittorrent.conf config file and delete any extra WebUI and ConnectionPort lines that may have been added to it... my bash script was left in a broken state, forgot to sync the changes to github, that would echo the line into the config every time instead of replacing the correct line...)
CSRF protection disabled by default on new installs
New installs will have CSRF protection disabled in the options by default. This is the setting that breaks basic reverse proxy configs from working and stopped the WebUI link from Unraids menu from working. This option can be enabled at any time via the WebUI or qBittorrent.conf config file.
If you updated this docker, this feature will not be disabled by default. If you want it disabled then you can edit it via the WebUI qBittorrent preferences in the WebUI section, or add "WebUI\CSRFProtection=false" to your qBittorrent.conf config file.
HTTPS
I purposely did not generate any certs and apply them for HTTPS for qBittorrent's WebUI. I assumed that most people would be running this behind a reverse proxy like letsencrypt or Nginx that would provide the TLS encryption necessary to secure the connection coming in from the outside. I also assumed that if you were savvy enough to set something like that up, you probably had the means to generate your own certificate and key to paste into the qBittorrent preferences via the WebUI to enable it. If this feature is requested by multiple people I will add it and possibly set it as the default.
SFTP
I am open to suggestions on how to make this docker more user-friendly and to simplify the installation and configuration process. If anyone has any ideas, voice them. I specifically made this because I couldnt find any good SFTP dockers made for Unraid. Willing to create a develop branch for testing changes and have people test if any improvements or suggestions are provided.
-
Hello everyone, I am back! I'm sorry to all you guys I left hanging over the summer. I left some things in a broken state by mistake (Didnt sync my last changes to github like a flucking idiot...) Decided to take a sabbatical and spend time with my two kids over the summer. Now that it's starting to get colder outside I have returned and will continue to maintain these dockers.
-
On 5/4/2018 at 1:04 AM, Kuusou said:
Woops, didn't realize what logs were which.
It seems your update fixed the white screen for me though.
My issue now is that changing the two given webui ports to the port I want seems to keep the 8080 port involvement, and then not let me access the webui anymore.
If I just use 8080 it works fine. is there something else I need to edit here that I cant see?
Edit: I was reading up on the other qBittorrent dockers and they seem to have the same issue. It might be a limitation of some kind. Let me know if you work around it. I'd love to change the port.
Edit2: I'm unable to tunnel Radarr and Sonarr through the docker to use as a.. proxy.. for my proxy.., which I currently do with my other torrent client. Is there a workaround for this, or something I need to enable/do differently? Or would you simply recommend doing it a different way if I'd like to utilize this container from now on?
Also I wanted to thank you for creating, working on, and updating/fixing this container. I had been waiting for someone to do so for a while, and even looked into options for doing it myself, but have little experience with dockers in unraid, so having a ready, or mostly ready option is just beautiful.
Hi Kuusou,
First, I screwed up my script before taking the summer off to spend with my family. The WebUI and Connection port environmental variables were not being applied correctly to overwrite the default config. This has been fixed.
Second, qBittorrent had a feature to block cross site request forgery which blocked proxies (unless they were configured properly to not send the referrer IP in the header. They finally added an option to disable this feature, which I have now enabled by default with new installs of this docker. If you update the docker, you can disable it yourself from the WebUI or by editing the qbittorrent.conf config file and adding "WebUI\CSRFProtection=false" to it. This also fixes the WebUI not working when trying to open from the Unraid menu.
On 7/16/2018 at 10:32 PM, jaxder said:Any chance of implementing the qBittorrent search feature into this docker?
This is a feature they is in development for the WebUI. I'm not so much a developer as a hobbyist. I know some Python, PHP, Bash, C#, Visual Basic and a few others. I can work my way around code to understand how it works but I dont do much with contributing to actual projects. My degree is in computer networking, unfortunately not programming.
On 7/22/2018 at 6:50 AM, plantsandbinary said:@MarkusMcNugen Hi and firstly thanks so much for this amazing docker. The VPN credentials part was by far the easiest of any docker I've used here. Binhex's dockers are great but require a crazy amount of configuring to get working. Just being able to drop my .ovpn config server file of choice in and throw in my username and password is exactly the kind of simplicity I honestly expected from other dockers, instead of being tailored the hard way to only work with one or two providers.
I have a problem though. No matter what I do or what interface or port I choose, I absolutely cannot open the WebUI. You said that clicking "WebUI" from unraid doesn't work. But neither does going to http://<MYIP>:8080 or whatever port that I pick. I've tried every interface I've created and made available except Host. I either just get a completely blank page or a "page cannot be displayed" error.
Can you give me a hand?
Also is there any chance you could set up some kind of SSL and .htaccess security for this? I know I'm just being lazy asking for it but running over HTTP is kinda crazy in this day and age.
When I get the WebUI sorted I'm going to try and reverse proxy this so I can access it from the web but keep it secure with .htaccess. I'm happy to do both in the meantime but without the webui loading I can't do anything.
I'd post a log but it looks like everything is meant to be working correctly. It's just the UI that does not load. I did attach my .ovpn config file though.
Here's the last part:
Thanks, and I seriously hope I see more dockers from you with the same simplicity.
Check your messages, PMed you!
On 7/24/2018 at 6:08 PM, plantsandbinary said:After 3 days and about 20 cups of coffee trying to work how to reverse proxy this container I finally got it sorted.
Using linuxserver.io's letsencrypt docker. I made my own proxy.conf file here:
# qBittorrent devs on Github indicated the Origin and Referer headers needed to be surpressed, # and that the X-Forwarded-Host needed to match what was seen in the browser, # as of version 4.0.3 these are the working settings. # Note: For some users, several windows in the Web UI will still be blank, such as when adding # a new torrent from a URL/magnet or local file. # If so, uncomment the last line "add_header" # to enable password access, uncomment the two auth_basic lines location /qbt/ { # auth_basic "Restricted"; # auth_basic_user_file /config/nginx/.htpasswd; proxy_pass http://192.168.1.50:8080/; proxy_set_header X-Forwarded-Host $server_name:$server_port; proxy_hide_header Referer; proxy_hide_header Origin; proxy_set_header Referer ''; proxy_set_header Origin ''; # add_header X-Frame-Options "SAMEORIGIN"; }This successfully fixes the redirection issue due to mismatching header data and well... it just works in general. I tried for ages to get it working on a subdomain but I just couldn't. Always ended up getting the blank page issue.
Either way I'm not picky. This works fine for my needs.
Credits mostly to: https://github.com/qbittorrent/qBittorrent/wiki/NGINX-Reverse-Proxy-for-Web-UI
The developer of this container @ MarkusMcNugen may be able to use the same thing to fix the inherent issue regarding the webUI redirect problem mentioned in the first post.
Also in the message I sent to you!
On 9/23/2018 at 6:37 AM, cheesemarathon said:URGENT!!! @MarkusMcNugen It looks like with your qbittorrent template you have forgotten to remove your VPN username and password from the template. Lines 71 and 76 currently contain values. I suggest you remove them!
Yeah, can't believe I did that... lol. It's alright, I switched VPN providers and have a different username and password anyways. On top of that my account is locked down and I use the max connections from my provider at all times.
On 9/23/2018 at 6:54 AM, CHBMB said:He hasn't visited the forum for a month and those have been there since April looking at the github.
Yep, indeed they have. Fixed it now, but not really worried about it.
On 9/23/2018 at 7:11 AM, cheesemarathon said:Shame, his loss then....
Haha, yeah, pretty stupid mess up on my part...
On 9/28/2018 at 1:32 PM, plantsandbinary said:Ok so today for seemingly no reason what-so-ever the WebUI is telling me that my password is wrong. Checked the encrypted md5 hash and cracked it and sure enough my password is correct and is the same I've been using forever.Restarting the container didn't work. Forcing an update didn't work...So I guess that's it for me then. I'll use ruTorrent from now on. I really like qBittorrent but we don't seem to get any updates anyway. I'm not messing around with stuff like this that just randomly decides to stop working.EDIT: Fucking Bitdefender blocking the login because it sends the password unencrypted... Added the url to exceptions and it works fine.
Also as others have said Mark doesn't seem to come here any more. I've messaged him twice about a month ago and am yet to get a reply.
Sorry for the sabbatical guys. I have returned!!!
-
19 hours ago, Demiurgous said:
I'm having the same error previously reported:
I'm not sure which file has the extra spaces, or what formatting it should have. If it matters, all VPN config files are from PIA, which are publicly available here.
I assume the above is why I can't access the WebUI for QBittorrent in the browser.
Please attach your ovpn file (You can remove the keys from the file before posting)
-
On 4/24/2018 at 8:08 AM, whauk said:
Take mine - I have the same problem..;-}qbittorrent.log
Container and template have been updated. You can now provide the VPN username and password to environmental variables and it will create the credentials.conf file and configure your ovpn config file automatically. You can also edit the WEBUI_PORT_ENV and INCOMING_PORT_ENV variables (Youll need to change the exposed ports as well) to modify the ports qBittorrent uses without having to do port forwarding and getting the DNS rebinding issue.
If you already have the container installed you may need to delete and recreate it to get the new template applied, or just simply update the container and add the variables to the config yourself. You can see the template here.
-
On 4/24/2018 at 8:08 AM, whauk said:
Take mine - I have the same problem..;-}qbittorrent.log
Hi Whauk,
Thank you for providing that log. qBittorrent implements a security feature against DNS rebinding which seems to be messing with Bridge/HOST configurations and port forwarding done by Docker. Im about to update the container to allow people to change the official qBittorrent ports with environmental variables.
Source: https://github.com/qbittorrent/qBittorrent/issues/7641
[Support] MarkusMcNugens Docker Repository
in Docker Containers
Posted
You shouldn't need to create the users manually. You can just them in the config file and the container will create them automatically. If the SSH key exists for the user it will copy it to their authorized_keys file as well.
I'm glad you got it figured out at least. Sorry I didn't have team to look I to it further this week. Was waiting for the weekend to test it myself.