MarkusMcNugen

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.

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.

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

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.

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

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

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.

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.

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.

Which container? SFTP? Would help if you could post the logs from the running container.

That's expected output. Can you send, attach, or post the CrushFTP.log file from the appdata folder?

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.

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!

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.

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.

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.

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.

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. Sorry about this guys, must have left my personal config for the ports in the default config. It's been fixed now. 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." https://github.com/jotyGill/openpyn-nordvpn/issues/107

@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.

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. 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. Check your messages, PMed you! Also in the message I sent to you! 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. Yep, indeed they have. Fixed it now, but not really worried about it. Haha, yeah, pretty stupid mess up on my part... Sorry for the sabbatical guys. I have returned!!!

Please attach your ovpn file (You can remove the keys from the file before posting)

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.

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