gurulee

The issue just reoccurred at around 3:30pm / 15:30. All webUI connectivity lost to unraid mgmt int (br0)and all my dockers. But I was still able to ping the interfaces and dockers with custom bridge vLAN's static IP's. The issue resolved itself after approx. 3min and the webUI mgmt int of unraid and dockers became accessible again. I looked at my enhanced syslog plugin and this is the only entry around the time of the issue: Sep 10 11:05:13 Tower root: Fix Common Problems: Error: Macvlan and Bridging found ** Ignored Sep 10 11:10:40 Tower kernel: eth0: renamed from vethe9b73b7 Sep 10 11:15:06 Tower webGUI: Successful login user root from 192.168.100.90 Sep 10 11:18:48 Tower kernel: vethb78d931: renamed from eth0 Sep 10 11:19:03 Tower kernel: eth0: renamed from vethd9921c1 Sep 10 12:17:41 Tower emhttpd: spinning down /dev/sdf Sep 10 12:45:53 Tower emhttpd: read SMART /dev/sdf Sep 10 13:06:06 Tower emhttpd: spinning down /dev/sdd Sep 10 13:16:28 Tower emhttpd: spinning down /dev/sdf Sep 10 13:19:08 Tower emhttpd: read SMART /dev/sdd Sep 10 13:54:51 Tower emhttpd: read SMART /dev/sdf Sep 10 13:55:06 Tower emhttpd: spinning down /dev/sdd Sep 10 15:30:46 Tower emhttpd: read SMART /dev/sdd

Thank you! I will report back 48 hours.

Returning to my question as it relates to my issue, should I switch from macvlan to ipvlan even though I am not aware of any macvlan errors and my vLAN's use bond0 ?

Okay, I have completed the upgrade from 6.12.8 to 6.12.13 successfully with no known issues. I will monitor it to see if the issue returns.

I have been holding off due to all the issues I'm reading about in the release notes and with users. But if that has a specific fix for this, then I will plan for it.

I am experiencing a new issue, and as of recent, with dockers on my custom vlan's (br0, br0.4, br0.5, br0.6) become unresponsive. However, I can still ping IP's on any of the networks. But I just cannot get to the web services running on any of them when the issues occurs, including the unraid webUI on br0. No other network changes have occurred and my unraid has been up for 3.5 months so far. The issue occurs when there is heavier network load on them. For example, Plex mobile app downloading content locally to view offline while another docker is performing downloads, or if multiple people are watching Plex. Uptime-Kuma docker webUI also becomes inaccessible during the issue, but when it resolves, it shows docker monitor events stating: 'Knex: Timeout acquiring a connection. The pool is probably full. Are you missing a .transacting(trx) call? Additionally, external PRTG monitors show HTTPS monitors for Plex and other dockers as timing-out. Additionally, I cannot get to unraid mgmt. webUI on br0 when the issue occurs either. ***When the issue is occurring, unraid CPU, RAM, and network utilization is low as well. The issue resolves itself after approx. 3-5min.... I'm on unraid version: 6.12.8 My network config. (not changed in over a year): Two physical eth interfaces (eth0, eth1) with bonding and bridging enabled. Bond0 (eth0, eth1) is connected to Cisco switch using LAG port config. All vLAN's use parent interface bond0 Docker vLAN br0, br0.5, br0.6 use upstream Opnsense firewall for DHCP pool. Docker custom network type: macvlan I do not see any kernel 'call trace' in my enhanced syslog plugin output. Can someone help me narrow this down and/or recommend if I should try switching to Docker network type: ipvlan ?

Thanks! The docker names must be lower case and match the results of the cmd you provided. 👍

Turns out using the container ID is no good since it changes when you update the docker. I tried using the name of the docker as it shows on my dockers page in the webui.

So I already had that in my docker template. What resolved it for me was to use the docker container ID in the monitor instead of the docker name.

What is the purpose of the Docker setup and docker monitoring type in Uptimekuma then?

I successfully setup and tested the docker host in UptimeKuma. But when I add monitors for docker name, they all fail with 'Request failed with status code 404' Any help would be greatly appreciated.

Thank you! This answered my earlier question on the 'jail.d' folder being missing.

Better late than never 😎 Thank you for posting this.

I would love to see an option to hide the Autostart and Uptime column for the group rows when compressed, but display it when the group is expanded ?

I had the same issue. Just remove the reference to 'http2' on those two lines in your conf file. Then restart Swag.

Ditto, for my wife 😉

Upgraded from 6.12.6 and all went smooth, no issues to report so far 🙂

This issue hit me yesterday after two months of uptime while on 6.12.6. Thank you for the quick fix to get the array stopped and restarted without needing to reboot. Sent from my SM-N986U using Tapatalk

Offer valid on SKU WD201KFGX bought online through the Western Digital Store. Sales quantities are limited to a maximum of 6 units (3 bundles) per customer. Offer is only valid while supplies last. This promotion is valid between January 22, 2024 and February 4, 2024. https://www.westerndigital.com/products/internal-drives/wd-red-pro-sata-hdd?sku=WD201KFGX Sent from my SM-N986U using Tapatalk

I encountered the issue too with one docker in a started state not being accessible by its webUI. I tried killing it in this manner by PID, but it was not clear what integer was the PID in the grep output. However, I was not able to cleanly stop or restart the docker. I ultimately had to stop all other containers, stop the array (which hung), and eventually had to reboot unraid softly to resolve the issue with one docker. All my other dockers were healthy. I'm on unraid 6.1.2.6

Unraid Mgmt interface / webui should support MFA in this day and age even-though it should NEVER be exposed to the Internet.

THANK YOU!

Greetings friends! Since plugins will not update unless we're on 6.12.x (e.g. Community Apps), I was forced to upgrade unRAID to bleeding-edge which is not how I typically upgrade in general. I am relieved to share that I successfully upgraded from 6.11.5 to 6.12.6. The only issue so far is my Swag docker is not starting, it returns Execution 'server error' popup. There as also a pending Swag docker update I then completed successfully... However, it still does not start with same above error. UPDATE: I had to go into Settings > Management Access and change the HTTPS port from 443 to 4434, even though 'use SSL/TLS' for webGUI was ahready set to 'NO'. When I applied the change, it still tried to redirect me to the webGUI on 4434 w/TLS for some odd reason... I had to force my browser to use HTTP/non-TLS to get back to webGUI. Swag docker starts fine now. [emoji41][emoji106][emoji6]

Same feelings here! 👍

So smart and a great reminder. Thank you