Dyon

Alright, then it seems to be something related to the DNS. Could you run "cat /etc/resolv.conf" in the terminal and share the output

Could you edit the container and change/add the following: Change the "Repository" field to "dyonr/jackettvpn:dev" Add another Path, Port, Variable, Label or Device > Config Type: Variable > Name: RESTART_CONTAINER > Key: RESTART_CONTAINER > Value: 0 > Default Value: 0 > Description: (empty) > Display: Always > Required: No > Password Mask: no This will add a new variable called RESTART_CONTAINER, if this is set to '1', 'yes' or 'true', it will exit the container when the network is down. When set to something else (like 0) it won't shut down. After changing this, start the container, open the console and please check if you can run the command `ping one.one.one.one`.

If you want another container to access the passthroughvpn container, you must use the internal docker IP. Next to the container, you will see something like "172.17.0.7:25570/TCP <----> 192.168.0.240:25570" in this case 172.17.0.7 is the internal IP of the container, so if you want another container to be able to access the container via the passthroughvpn container, you need to enter, in this case, 172.17.0.7 (with the correct port). Accessing the passthroughvpn container outside of you LAN is possible via port forwards. You could either forward the ports of your LAN (to access it via your own home IP), or, if your provider supports it, forward ports at the VPN Provider's side. Port-forwarding in both cases should be pretty straight forward. I hope it's clear, if not, let me know

I am not in the position to to write an extensive reply, but you might want to read the two scenarios I described in the GitHub page, I'll get back to you later, but this is some info already. https://github.com/DyonR/docker-passthroughvpn

Well, that explains a lot! Glad you found the issue. If you ever run into problems again, let me know!

That is really strange. As a test, I mounted my STACK in Windows, added a file, and a few moments later it did appear in the STACK folder on my Unraid. So it works for me... There are two things you can do. 1: Check the logs. Set the SILENCE_OUTPUT of the container temporary to "0". This will spam the container log, and not everything would be readable because of that. At the bottom of the spam, error should/could show up. (I haven't implemented something to output the log somewhere, might do that soon though, since it won't be a lot of effort) 2: Start Fresh. There could be an underlying problem that isn't easily visibele. Yes, you would need to redownload/resync everything with Unraid again. Stop the container. As long as the container is stopped, there is no risk in removing the folder. Remove the folder /mnt/user/data/Ralf/Stack/ from your Unraid. Start the container again, the folder should get created automatically.

Edit this Docker Container in Unraid, set the WEBUI_PORT environment variable to something else. Start the container. You should now be able to access it to the port you did set.

As far as I know (for my own experience), owncloud works sequential. So it will download all files first, when that is finished it will start the upload. So, you are saying if you upload a file via the STACK PC Client, it doesn't show up in the Unraid folder? Does it appear on the STACK website? Because I can't imagine it wouldn't sync that file

I don't see anything wrong with the other environment variables that you have set. Mine are exactly the same (I also use STACK) Since using "/TTD" works for you, I don't think it's a OC_PASS problem, so I assume you are already using the WebDav App Token from STACK. I suspect there might be a problem with the database that OwnCloud stores for synchronisation, since you switched from "/TTD" to "/" it might have gotten confused. What I would do it: Stop the container. As long as the container is stopped, there is no risk in removing the folder. Remove the folder /mnt/user/data/Ralf/Stack/ from your Unraid. Start the container again, the folder should get created automatically. Edit: These are my environment variables: OC_USER username OC_PASS webdav_app_token OC_SERVER my_ulr_for_stack.stackstorage.com OC_URLPATH / OC_FILEPATH / RUN_UID 1000 RUN_GID 100 TRUST_SELFSIGN 0 Sync Location /mnt/user/STACK/dyonr/ OC_WEBDAV remote.php/webdav OC_PROTO https SYNC_HIDDEN 0 SILENCE_OUTPUT 1 RUN_INTERVAL 30

Your OC_WEBDAV path is incorrect for TransIP Stack, in Unraid edit the owncloud-client docker, and expand the advanced settings at the bottom and set OC_WEBDAV to this (without quotes): "remote.php/webdav" Edit: Nevermind, yours is set correctly. Change the: OC_URLPATH: /owncloud/ to: OC_URLPATH: /

I've worked on a fix for the problem mentioned by @howyoulikethat, but while working on it, I've decided not to release this. I do not want to mess with the config file of users. The code below was intended to be a new section of the qBittorrent/start.sh file, to fix the config. Problems; 1a. It doesn't check if the user already fixed it themselves. 1b. It doesn't check the [BitTorrent] section in the config file to see if the new Session\DefaultSavePath etc already exist, so it keeps adding it on every reboot. 2. Moving the files is a dirty fix. 3. Messing with the .fastresume files is tricky. What if someone has a rule to automatically move it to a sub-directory? In that case the .fastresume file would be different than the default savePath29 / save_path29.

It seems like qBittorrent changed something that made the config different. I'll see if I can pushg a new update soon to fix this for everyone using this container. For now; 1. Open qBittorrent 2. Go to settings 3. In the first default tab (Downloads) change the 'Default Save Path' to '/downloads'.

Disabling SSL is indeed bugged at the moment. I will fix this in a future update. For now, if you want to disable SSL: - Stop the container - Set the environment variable ENABLE_SSL to 'no' - Go to the Unraid Appdata of this Docker container, appdata/qBittorrent/config/qBittorrent.conf Set 'WebUI\HTTPS\Enabled=true' to 'WebUI\HTTPS\Enabled=false' Want to reset the password? In the same config file set 'WebUI\Username' as 'WebUI\Username=admin' Remove the line 'WebUI\Password_PBKDF2' and replace it with this line: WebUI\Password_PBKDF2="@ByteArray(ARQ77eY1NUZaQsuDHbIMCA==:0WMRkYTUWVT9wVvdDtHAjU9b3b7uB8NR1Gur2hmQCvCDpm39Q+PsJRJPaCU51dEiz+dTzh8qbPsL8WkFljQYFQ==)" After that, stop and start the container. Note that having SSL disabled COULD cause login issues.

On my own system, I was never able to confirm DNS leakage. I tested it on 3 containers, my own 'docker-passthroughvpn', 'binhex/arch-mineos-node' and 'ich777/teamspeak', all giving me the same results. My results (37.xxx.xxx.xxx is my VPN IP): root@6cb7b6696c1d:/tmp# ./dnsleaktest.sh Your IP: 37.xxx.xxx.xxx [Netherlands, AS9009 M247 Ltd] You use 4 DNS servers: 141.101.64.196 [Netherlands, AS13335 CloudFlare Inc] 141.101.64.197 [Netherlands, AS13335 CloudFlare Inc] 141.101.75.126 [Netherlands, AS13335 CloudFlare Inc] 141.101.75.147 [Netherlands, AS13335 CloudFlare Inc] Conclusion: DNS may be leaking. root@6cb7b6696c1d:/tmp# While running it on Unraid itself yields a different result, showing my actual IP addresses root@Dyon-unRAID:/tmp# ./dnsleaktest.sh Your IP: 2001:xxxx:xxx:xxxx:xxxx:xxxx:xxxx:xxxx [Netherlands AS33915 Vodafone Libertel B.V.] You use 2 DNS servers: 94.xx.xx.xx [Netherlands AS33915 Vodafone Libertel B.V.] 2001:xxxx:xxxx:x:xxxx:xxxx:xxxx:xxxx [Netherlands AS33915 Vodafone Libertel B.V.] Conclusion: DNS is not leaking. It's hard for me to look into an issues that I can't replicate obviously. Could you share the log of your passthroughvpn container? Obviously, don't forget to mask out any sensitive information like IP-addresses, but keep them so that I can tell them apart. You can also open a console to the container and "cat /etc/resolv.conf". In there for me, it also lists the local IP of my router. What you can try is to install vi(m) and remove the line of your router to see if that fixes it maybe. If that's the case, I'll look into fixing that.

Just delete the '._' one. Should be fine. The .DS_Store, ._.DS_Store and ._melbourne.ovpn are created because you use a Mac. If you open or edit files in there these files will be generated. If I work on an update for the container, I'll try to add something to ignore those files. But for now, just delete any ._ files in there.

Try changing the filename from `._aus_melbourne-aes-128-cbc-udp-dns.ovpn` to `aus_melbourne-aes-128-cbc-udp-dns.ovpn` (remove the . and _ in front of it) and try again. Or just rename it to something like 'melbourne.ovpn'.

They finally released an update after more than two years? 🤡 Anyhow, the container is updating, should be up in max. 10 minutes after me posting this message

Did you alter the script in any way? Did you change the name of the passthroughvpn container? Could you go to your 'Docker' tab in unraid and check that the name of the passthroughvpn container is literally 'passthroughvpn' (no difference in capitalization) And then check if the script matches this on the 4th line where it says 'PASSTHROUGHVPNNAME=passthroughvpn' This error seems to be caused by a wrong container name, or wrong name in the script.

No, you should use your full subnet, for example 192.168.178.0/24. I think that would fix your issues. Let me know what does and doesn't work after changing that.

Great to hear you fixed it, sorry I couldn't help you with your problem.

You can just remove it from the Wireguard config file

@apefray Great to hear that it works with Windscribe! 😁 The MTU and other warnings is something you can ignore. I've been running systems for months without problems. You can switch to AES-256-GCM instead of AES-256-CBC to get rid of one error, I think. Do you also have to problem with connecting to Emby if you use an in-private/incognito window? Is your internet connection of where you host it (your 4G router) fast enough?

Well Windscribe obviously comes with additional costs, but if that is no problem for you, that would work of course. I use Windscribe static IP myself, so that must work. Just make sure to follow my explanation on my GitHub page precisely 😁

I fully understand what you wish to achieve, but sadly I do not think I can help with this. I do not use PIA myself and have no experience with it. The process of the PIA Portforwarding also seems quite complex. You can still try to give it a shot yourself. The GitHub Page (https://github.com/pia-foss/manual-connections) says that you need to run the following; git clone https://github.com/pia-foss/manual-connections.git cd manual-connections sudo ./run_setup.sh I do not think my container has git installed and sudo is also unnecessary, so I think you would need to run to following inside my container: apt update && apt upgrade -y && apt install -y git cd /tmp git clone https://github.com/pia-foss/manual-connections.git cd manual-connections ./run_setup.sh (Or any other script than run_setup.sh) Try to read the GitHub page and see how far you can get. Hopefully someone else has more experience with it and can help you. If I need to include something minor to the container to make stuff like this work for PIA users, I'm willing to do that.

Unfortunately Unraid didn't send me an email notification about this. But I'll look into it, but it looks like SABNZBd changed the way of how to compile it, so I have to look into this. I'll let you know if I updated it. Edit: It's updated