nickydd9
Members
-
Joined
-
Last visited
-
@binhex, bumping my questions from last week. Do you have any comments? I understand this is probably number 51 on the Top 50 things to do, so mostly just curious.
-
Would there ever be consideration for packaging an alternative WebUI into this container? Right now I have Vuetorrent installed by grabbing the latest build from Github, extracting it into my appdata folder in Unraid and then mapping it to binhex-qbittorrentvpn, however I can't figure out any easy way to keep Vuetorrent up to date without manually updating it. If Vuetorrent was packaged in this would be a more seamless upgrade experience through Community Applications just having to update the VPN container. Hotio's qbit container has it packaged in.
-
I tried clearing browser cache to no avail. I ended up just re-installing Theme Engine plugin and its working again. Thankfully I use one of the default templates in Theme Engine so I didn't have much setting back up to do.
-
@binhex I am betting your "host access to custom networks" is probably disabled which is why you wouldn't hit the qbit container with a custom br0 IP. As described in the Unraid Docs:
-
It is working for me. I have WireGuard setup for remote access to my Unraid server. My "Peer type of access" is Remote Tunneled Access and I am using the desired config of "Use NAT = No", "Host Access to Custom Networks = Enabled" and I have a static route from my WireGuard subnet to my Unraid host with a metric of 1. Basically just followed this guide: https://docs.unraid.net/unraid-os/manual/security/vpn/ In the DockerMan template for your qbit container, I also ensured to add the WireGuard subnet in the "LAN_NETWORKS" variable so that I can access the Web UI. With this type of setup I can access the containers WebUI while connected to my LAN, or while remote connected through a WireGuard VPN tunnel. I have not tested access via a port forward because I've never wanted to expose the container that way.
-
I haven't experienced a crash since moving my USB 3.0 drive to a USB 2.0 Port on the motherboard. I am still generating syslog and will continue to monitor for a while.
-
Yes absolutely. From another laptop and a desktop both addressed inside of 192.168.1.0/24 I am able to hit the Web UI of the qbit container (192.168.1.50:8080), which is why I am confused with you saying it shouldn't work.
-
What, since when? I am using custom br0 network for my container assigned as IP 192.168.1.50, and my LAN_NETWORKS is permitting 192.168.1.0/24,10.253.0.0/24. I don't think I am experiencing any issues with accessing the container locally or remotely via WireGuard.
-
@JorgeB I will do that, but do the messages I posted above seem to hint that it would be hardware or software related, or hard to tell?
-
Just for s#its and giggles I am going to move my flash drive to a USB 2.0 port and see if that makes any difference. I don't know why all of a sudden it would cause an issue being in a 3.0 port if its been working fine for a couple months though.
-
Hi, I am currently running 6.12.6 and every few days my server will lock up. I am unable to access the web GUI. Certain containers I can access, but some I can not. Only way to fix is to hard reboot the server and then it's fine again for a few days. I did run a Memtest and at first was getting errors, but noticed I was not getting them when I disabled XMP Profile. I flashed my BIOS to a newer revision as the release notes stated there was some memory fixes, and after flashing Memtest made it through a few passes without errors. I keep a monitor, keyboard and mouse connected to this server, and I notice on the screen I see these messages: exit status 1 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null exit status 1 from user root /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null I will attach my diagnostics as well. Is this a plugin related issue? What can I do as this is getting rather annoying since it's about the 5th time its happened in 2 weeks. I have been making a lot of changes as I have basically been building the server fresh for the first time so forgive me if I am just doing something stupid. eq-server-diagnostics-20240131-2333.zip
-
@manrw is there no appdata configuration for this container similar to most other containers on Unraid? I went looking in my appdata folder and don't see anything there for dashdot.
-
@binhex this might be noob questions, but I am confused still about the NAME_SERVERS variable. From what I understand, the first step is resolving the VPN Provider's remote gateway, which uses the DNS on your host (which the docker also have available to it) and that this can be any Public DNS Server (in my case I am using Quad9 on my host). So now I am wondering what NAME_SERVERS is for. Is this the DNS servers to resolve for anything after the VPN tunnel has formed? If so, why do we need to even specify DNS servers, wouldn't we want to be using the VPN providers DNS servers and not manually specifying DNS to avoid leakage? I am only asking because when I visit IPleak.net on a firefox container that I have routed through your qbittorrent vpn container, I do see my VPN Public IP address, but the DNS servers are listed as Cloudflare (which I currently have 1.1.1.1 configured as NAME_SERVERS because I skimmed through the template setup and didn't bother to change). I just kind of expected to see that I would be using my VPN providers DNS servers over the tunnel as I have always been told its best for security so you don't split DNS outside of the tunnel accidentally.
-
I have binhex-qbittorrent setup, and I am routing some other containers (firefox + prowlarr) through that VPN container with "--network=container:binhex-qbittorrentvpn". On the Firefox and Prowlarr containers I have network type set to none. What has been happening recently, I think as far back as 6.12.3 is that it will randomly start showing port mappings from other unrelated containers (usually a container thats had a recent change, like recently installed, or recently upgraded). For example, right now its showing mapping information from my Overseerr container for no reason. The only way I can get the port mapping to disappear on this screen is to edit both Firefox and Prowlarr and toggle their network type to something else, and then toggle it back to "None" and it will show no port mapping for a while. But over time it reappears with a new random mapping from a different container I have installed at random. Now I don't think this is actually a concern. I don't believe its truly trying to do any mappings, as again the network type = none. I think this is more of an annoyance, but I wonder why this changed all of a sudden? Could this be fixed and have it be changed to just be blank with no mappings? Alternatively, have it show mappings for the master VPN container they are being routed through? Seems others are reporting the same bug: https://forums.unraid.net/bug-reports/stable-releases/docker-tab-ip-view-broken-on-network-bridged-containers-r2768/ https://forums.unraid.net/bug-reports/stable-releases/6124-dockerpage-shows-bogus-port-mappings-r2632/ https://forums.unraid.net/bug-reports/stable-releases/6123-wrong-info-in-docker-tab-when-some-containers-route-via-other-ones-r2615/
-
Seems others are reporting the same behavior:
