BestITGuys
Members
-
Joined
-
Last visited
Everything posted by BestITGuys
-
Thanks for the troubleshooting steps. The problem seems to have resolved itself, but it lasted basically the whole day yesterday. It wasn't a matter of multiple updates -- I usually have no problem letting those finish. But because the speeds were so atrocious, I just left them running, and it took a few hours to get them all finished. And it definitely wasn't a general internet connection issue -- as I mentioned in the OP, I was getting 600 Mbps from inside VMs and inside individual docker containers. But I never even considered DNS issues, since I wasn't getting any kind of errors. I'm not using the ISPs DNS. I use Google as primary and CloudFlare as secondary, but if it happens again, I'll try different ones, and I'll also post the diag
-
I don't really know how to even start troubleshooting this. I have docker updates for existing apps that are taking forever (hours). This is happening when trying to install new apps, or apply updates to existing containers. They all appear to get stuck "Pulling fs layer. Downloading ...". A layer of around 200MB size is taking around 20-30 minutes to download, so it's running at something like 100 kbps. But the download speeds everywhere else are absolutely fine, around 600 mbps. Can anyone suggest how anything I can do to fix it, or any troubleshooting steps to figure out what's happening?
-
I posted a thread about it in General Support a few days ago, but didn't get any replies. Since then, I've collected some more info, and discovered specific ways to reproduce the problem. So, here's what's going on: I have a tunnel set up in VPN Manager that's of type "VPN tunneled access for docker", and it's called wg0 It's the only VPN tunnel set up in Unraid. No others exist either in VPN Manager, or in any Docker containers I have several containers set up specifically to use that tunnel, so they're set up to to use a custom network wg0 I also have other containers that I don't want to be routed through that tunnel. Some of them are set up to use the Bridge network, and others are set up to use the Host network My expectation (and please correct me if I'm wrong) is that only the containers set up to use the wg0 network would actually use that VPN tunnel. If I check my public IP address from the console of any of those containers, I expect to see the VPN tunnel's public IP The rest of the containers should be using the local network, and if I check the public IP from the console, I expect to see my local network's public IP I'm using the following command to check the public IP from the container consoles: curl https://ipinfo.io/ip And here's where the weird behavior comes in. If I manually enable the wg0 tunnel from Settings --> VPN Manager, everything works exactly as expected. I can toggle the tunnel on and off while the containers are running, or I can stop and restart any of the containers, and nothing gets screwed up. However, under the following conditions, all docker containers (regardless of which network they're set up to use) start reporting the wg0 tunnel's public IP address: If I activate the tunnel from the main dashboard If I activate it manually from the terminal using wg-quick up wg0 if I set up Autostart for the tunnel, and reboot the server It doesn't matter if the containers are running, or if they are stopped and get re-started As soon as the tunnel is activated, all containers start reporting the tunnel's public IP As soon as the tunnel is deactivated, the containers that are set up to use wg0 as the custom network completely lose internet access (as expected), but everything that was set up for Bridge or Host networks revert back to reporting the correct local Public IP No matter how many times I tried toggling the tunnel on and off, this behavior continues The only time it starts acting normally (as expected) is if I activate the runnel from the VPN Manager UI page Also, just for testing purposes, I changed the network in one of my containers that's set up to use the Host network to use br0 instead. Since I use macvlan for Docker, that container lost its connection to the host (and I was obviously unable to access its WebUI), but I was still able to open the console and check the public IP. This container was not affected by any of the shenanigans described above. It worked just as expected in all circumstances server-diagnostics-20240914-0228.zip
-
I have it set up in VPN Manager (tunnel called wg0), and it's generally working as expected. I have specific containers set up to use the custom wg0 network, and those are the only containers that I want tunneled through it. However, that tunnel is being enforced on all other containers as well (anything using the Bridge or Host networks), and I don't see any reason why that's happening. The way I realize that this was going on is because I checked my public IP address from those containers, and they're reporting the tunnel's IP instead of my actual public IP. Is this expected behavior, and if so, how can I change it so that the Bridge and Host networks don't get forced into the tunnel? Update: when I disconnect the wg0 tunnel, the containers that were specifically assigned to use that tunnel completely lose their connection (as expected), but the rest of the containers revert to having the correct public IP. And as soon as the wg0 tunnel is reconnected, they start showing the public IP of the tunnel again
-
Anyone?
-
I'm sorry, do you mean that I should set it to "disabled"? I currently have it set to "enabled"
-
I've successfully set up a WireGuard VPN tunnel in VPN Manager, and I've set the peer to be "VPN tunneled access for docker". The tunnel activates successfully, but as soon as it does, I lose access to any Docker containers that are set up to use that tunnel. If I change the containers to use "bridge" network instead, they start loading just fine. So, is there a setting that I'm missing somewhere?
-
Thanks
-
Sorry for asking almost the same question as the OP, but I just wanted to clarify something... I'm trying to do the same thing (replace parity with a larger drive, and once it's done rebuilding, add the original parity drive to the array). I'm not using the same port, and both drives will always be connected at the same time. So, when I get to Step 5, and change Parity1 drive to the larger one, I get a warning that it's the wrong drive (see attached pic). It looks like it'll let me the array anyway, but that warning got me worried that I might trash my array by doing it this way. Can you guys please let me know if that's exactly what I'm supposed to be doing?
-
That worked! Thanks
-
I'm trying to update from 6.9.2 to 6.10.3, but there seems no way to do it. It also shows my current status as "unknown", and if I change the branch from stable to next, the whole row disappears. I'm attaching the screenshots... I've seen in other threads that their Plugins were also missing the "Check Updates" button, but in my case, it's there. So, what can I do to fix this? Thanks
-
Search is broken since the last update. Getting the following error in the log: File "/config/data/qBittorrent/nova3/nova2.py", line 36, in <module> import urllib.parse ImportError: No module named parse
-
That makes perfect sense. I didn't realize those variables could be used to replace the /watch and /output mappings
-
Just a suggestion -- maybe you can add an option (or change the existing setup) so that instead of /watch and /output being mapped as volumes, they could be subfolders of a common volume, something like /media. This would make moving large files from the watch folder to output much faster You could map a new /media volume (or just use the /storage volume and point it to the media folder), and then the names of watch and output folders would be docker variables instead of paths.
-
It's been a while since this discussion, but it's definitely an issue with jDownloader's 7zip library -- it can't handle rar5 archives. But the underlying library has been updated, and if you manually copy it into the docker, it stops having issues with rar5 archives. I've already tested this on my end, but I'm hoping that @Djoss could update this docker with the updated library. In the meantime, here's what you need to do to fix it manually: 1. Download the updated library from here 2. Extract the contents of the /libs folder. There should be 2 files there -- sevenzipjbinding.jar and sevenzipjbinding-Linux-amd64.jar 3. The first file is OK, but the second one needs to be renamed to sevenzipjbindingLinux.jar 4. Copy both files into whatever share you have mapped to jDownlader's /output 5. open the docker console, and type in the following commands (which rename the old lib files, copy the new ones, and set up the correct owner mv /config/libs/sevenzipjbinding.jar /config/libs/sevenzipjbinding.jar.old mv /config/libs/sevenzipjbindingLinux.jar /config/libs/sevenzipjbindingLinux.jar.old mv /output/sevenzipjbinding* /config/libs/ chmod app:users /config/libs/sevenzipjbindingLinux*
