nickydd9
Members
-
Joined
-
Last visited
Everything posted by nickydd9
-
@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:
-
I should mention that I understand with br0 and basically anything other than "bridge" that port mapping are really not relevant because there is no port to map. I am just wondering why for containers that are network type = NONE that its showing port mappings for an entirely different container......?
-
Hello, I am relatively new to Unraid and in the process of setting up my server. I have binhex-qbittorrent setup, and I am routing some other containers (firefox + prowlarr) through that VPN container. On the Firefox and Prowlarr containers I have network type set to none, but after a while they will randomly show that they have a port mapping. I am not sure they actually do, I am thinking this is just a glitch. What I have noticed is that they will always show a mapping using the IP address I have assigned to my most recently installed container, which in this case right now is Overseer that I have installed most recently. 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. Anyone experienced this before? Any clue why? Is it actually a concern? Of course the last thing I want is duplicate IP's on my LAN. I am running everything as br0.
-
wow 12 years old hahaha..... but to be fair it does sound pretty similar to what is happening and lines up with the fact that once its communicating it doesn't drop out until I reboot Unraid. Well it seems the script I have created is probably the best method for me to deal with after all since it will just keep force trying the connection until I catch the UPS not busy. Thanks!
-
No, I've made sure this if off, UPS cable set to "Custom", and UPS type set to "Dumb". I have noticed my exact UPS model is not listed here: https://networkupstools.org/stable-hcl.html
-
Well as a follow up to my last post, again the behavior remains strange. If I just keep trying to start NUT it just eventually works and then its solid until a next reboot. Of course this means that if my server was to shutdown due to a power event and come back up on it's own I would want NUT to be connected and working automatically. At this point all I've been able to come up with is a script I am running in CA User Scripts that I am running at array start. It simply just pgrep's "upsmon" and if not running then it will continually loop "/etc/rc.d/rc.nut start" until "upsmon" is running. I think I should be ok with this, but if anyone sees any drawbacks with this or has something more graceful I could try then I am all ears. #!/bin/bash # Define the process name to check process_name="upsmon" # Function to check if the process is running is_process_running() { pgrep -x "$process_name" > /dev/null } #Check if process is running if is_process_running; then echo "Process is already running." #If not running, start it else echo "Starting the process..." /etc/rc.d/rc.nut start sleep 20 # Loop until the process is running while ! is_process_running; do echo "Process still not running, trying again..." /etc/rc.d/rc.nut start sleep 20 done echo "Process is now running." fi
-
Hey, I have a CyberPower LX1325GU-FC UPS and am using NUT 2.8.1 backend. I am connected with USB cable, in Standalone mode, and using usbhid-ups. It works great for the most part, however from time to time NUT will fail start, like for example is I reboot my whole Unraid Server it may just not start up. It's very sporadic though, sometimes it does sometimes it doesn't. When it doesn't start up usually I can just go in and disable and re-enable NUT and then it will come up. Looking at the system log I was seeing: Can't initialize data from HID UPS Then after turning up the log debug levels a bit I was also noticing this: Fatal error: insufficient power configured! Any ideas what's up? I have tried different USB ports, but not a new cable yet. But since it's working pretty much rock solid until I have a reboot I don't really suspect cable issue.
