nraygun

I see this in the Background jobs page: Last job execution ran 8 days ago. Something seems wrong. Is this also something that will get addressed when they issue the next update? I'm on 27.0.0-ls252 at the moment.

Thanks @mikl. I had changed the environment variable WEBGUI_PORT, and it did change the port in the container. But it was not accessible. It was only when I changed it in the app itself, not via any config, that it worked. I have since given up on this method. It also wreaked havoc on my VMs. I just put everything back to the way it was. I wasn't getting macvlan errors as of late. It was just in preparation for going to 6.12.

Is this anything to be concerned about? I see it in the syslog. The .45 address is my desktop PC. Everything seems to work (using Swag with Nextcloud). Jul 6 09:27:47 server nginx: 2023/07/06 09:27:47 [error] 6177#6177: *927621 recv() failed (104: Connection reset by peer) while proxying upgraded connection, client: 192.168.0.45, server: , request: "GET //wsproxy/5701/ HTTP/1.1", upstream: "http://127.0.0.1:5701/", host: "server.local"

Oh FFS! Still trying to understand the whole qbittorrent thing, but I fired up a VM for a routine thing I do on the first of the month and it didn't work. 😞 The VMs were using "virbr0" which I guess is not there anymore since br0 is not available. I was able to change one VM to use br1 and it worked, but some of the other VMs don't have the "Network Source:" option. I tried copying the XML from the working VM but got a duplicate MAC address situation, I think. What sort of things do I have to do with the VMs with this dedicated Docker network? I'm starting to doubt the value of using this dedicated network.

Here's my WebGUI value. I get this same behavior with DelugeVPN. It seems like it's stuck on having things route through privoxy for the webgui port until I change it to something else in the app. And I noticed I can change the container port by going to "bridge" mode, saving, then going back to "br1". Then I have to change the gui port in qbittorrent. For example, the container port is now 8585 instead of 8081 and it still works. Maybe there's a problem when switching network types?

Can someone help explain what's going on here? My container on a dedicated bridge on eth1 shows these mappings. Note 8080. 6881 and 8118 look fine to me and make sense. In the config, there is no 8080. It shows this: Shouldn't the port mappings show 8081 or 8585? Why is 8080 shown in port mapping? Where is it getting 8081 from?

I guess the deal is there is no container port when on a custom network. Things are weird when using this new br1 I created on eth1. I noticed when I changed the WEBGUI_PORT to 8585, it does show up this way in the app - I just can't get to it without going through the proxy. The only thing that seems to work is leaving WEBGUI_PORT at 8080, configure Firefox to use the proxy, and then go into the app with 192.168.0.6:8080 and changing to 8585 in the app. If I do it any other way, I can't get to the ui without going through the proxy. I also see that my Host Port 3 is set to 8585 with the container port set to 8081 but 8081 doesnt show up in the port mappings.

Well, I tried that and there is no container port field when I click add. If I edit one of the existing ports, it shows a container port. I might just leave well enough alone.

Got qbittorrentvpn working after a long night. Had to change the webgui port. I had to turn on the proxy in a browser, then go to the webgui and change it in the app. One odd thing, even though I changed the webgui port to 8585, unRaid's port mapping still shows 8080. But hey, it works.

I got it! But it's weird. I had to change the webgui port to 8585 in the container settings and in the app itself. unRaid's port mapping still shows 8080, but it's actually 8585. I also found that some of the arr's cant resolve hostnames even though they are on the same custom network. So I put static IPs for everything.

I think I got it! I had to turn off bridging on eth0 and change a few ports here and there. Everything seems to work except for qbittorrentvpn - I can't get to the webgui nor can the -arr's get to it. I can get to webgui of other containers just fine, just not this one. Nextcloud+Mariadb+Swag works fine on the new br1 too. If anyone has any suggestions, I'd appreciate it. I'll go pursue this in the binhex-qbittorrentvpn forum.

I changed my docker network to use a dedicated port on my server and now I can't get to the webgui of qbittorrentvpn. Here's what I did: https://forums.unraid.net/topic/137048-guide-how-to-solve-macvlan-and-ipvlan-issues-with-containers-on-a-custom-network/ The container now has an IP on the host's network. I can ping it, but it doesnt bring up the gui nor can the other arr's access it. If I put it back to bridge, it works fine. When on bridge, it got an ip of 172.17.0.2. When on the br1 bridge, it gets an IP of 192.168.0.10.

Can anyone help me? I think I'm missing something here but can't figure it out.

I see that there are folks having problems with a bot or something hitting Minecraft servers. One solution is to block a particular IP which I think I did in my router and it seems to have worked. I tried to use iptables inside of the container but I get an error as follows(that IP is the troublemaker): iptables -A INPUT -s 162.33.178.237 -j DROP iptables v1.8.9 (legacy): can't initialize iptables table filter: Permission denied (you must be root) Perhaps iptables or your kernel needs to be upgraded. Am I doing something wrong or is iptables not fully implemented in the container? I was also getting screen problems and using the command from the FAQ didn't work. Is there an updated command? I tried this: docker exec -u nobody -it binhex-minecraftserver /usr/bin/minecraftd console And it didn't work. Is there an updated command?

Uncle. I've tried to get this to work on my system but I think I'm missing something. While I was not getting macvlan issues, I figured I'd configure it this way on a separate network in anticipation of going to 6.12.x. Plus my R710 has 4 network ports - may as well use 'em. I configured my system as outlined in the original post. When I change my Swag container to use br1, I can't get to the webui. It seems with the old configuration using a custom docker network, it gives the container a different IP on a different network(172.18.0.3 443/80) that maps to the hosts network(192.168.0.100 1443/180). With proxynet custom docker network: 172.18.0.3:443/TCP <-> 192.168.0.100:1443 172.18.0.3:80/TCP <-> 192.168.0.100:180 With br1 configured as in this post: 192.168.0.2:443/TCP <-> 192.168.0.2:443 192.168.0.2:80/TCP <-> 192.168.0.2:80 Relative noob here. Hope someone can steer me in the right direction.

This month's parity check reported the correct information. My last one's reporting error must have been a fluke due to the scenario under which the parity check ran.

Thanks @TimTheSettler! So it's basically a weekly restart of the apcupsd daemon and no cause for concern, right?

@ConnerVTDid you ever find anything out about this log entry?

Any ideas why the parity completion message was wrong?

Wait a minute, it's showing the duration of the last parity operation. I had removed a virtually unused 500GB drive from the array and rebuilt the parity. That took the time as shown in the summary email. New question: Why did the parity check display the results of the prior parity operation? PS - Is my speed OK?

I have my system setup to run a parity check on the first of the month. It ran as scheduled and I got a confirmation email that it started on "May 1, 2023, 12:01 AM". It finished on "May 1, 2023, 6:59 PM". The summary email upon completion says, "Duration: 1 day, 4 hours, 32 minutes, 12 seconds. Average speed: 97.3 MB/s" Why does it say it took over a day when the start/stop emails say it took just under 19 hours?

I tried changing the mode without reconfiguring anything and not only did the containers not resolve host names, but my host server also does not resolve host names. I put it back, then tried to setup a second physical NIC but the interface would not show up in the containers. So I put everything back and have been running OK since. For a while there, the macvlan errors were happening pretty often.

Sorry to hear that. I'm still waiting to hear from someone if this whole thing is a bug or if this ipvlan stuff is the permanent fix. I was unable to implement the dual NIC thing and simply changing to ipvlan rendered my system pretty much inoperable. However, for the last week or so, it's been up with no sign of macvlan errors in the syslog. (knock on wood)

Thanks, but at this point I'm at a loss for what to do. This is above my pay grade! I just don't understand how setting up another ethernet port (I have 4 NICs on my R710) can still use macvlan and still work. Seems to have something to do with MAC addresses. Haven't had a warning/crash since the last reboot last night using macvlan. And when I get syslog entries on a possible macvlan issue, my server continues to operate. I'll see how it goes. Does anyone lknow what the overall plan is for this issue? Is this separate NIC thing a workaround or a permanent fix? Thought I saw somewhere that the macvlan issue was deemed a bug of some sort.

Thanks @JorgeB! As I mentioned in other posts, I had to go back to macvlan. I'll consider this one closed.