CablDeViL

Hello all, I have eth0 set for no bond no bridge. This interface used for the Unraid access / shares and plex docker. Eth1 is setup on its own vlan on a different network with bridging enabled. I receive this in the logs and it is messing with ip address and access to unraid. ar 29 04:07:24 Unraid kernel: vethcbcc6ea: renamed from eth0 Mar 29 04:07:25 Unraid kernel: eth0: renamed from veth9f1932f Mar 29 04:07:30 Unraid kernel: veth3005291: renamed from eth0 Mar 29 04:07:57 Unraid kernel: eth0: renamed from vethe239e55 Mar 29 04:08:02 Unraid kernel: vethf978886: renamed from eth0 Mar 29 04:08:14 Unraid kernel: eth0: renamed from veth811c7d3 Mar 29 04:08:21 Unraid kernel: vetha7ab26d: renamed from eth0 Mar 29 04:08:23 Unraid kernel: eth0: renamed from veth4bd73f7 Mar 29 04:08:34 Unraid kernel: vethfda06d3: renamed from eth0 Mar 29 04:08:43 Unraid kernel: eth0: renamed from veth5908af7 Mar 29 04:08:45 Unraid kernel: veth5e20ec6: renamed from eth0 Mar 29 04:08:45 Unraid kernel: eth0: renamed from veth0a7cf4d My docker is set to ipvlan not mac. Docker custom network type ipvlan Host access to custom networks: Disabled Preserve user defined networks: No IPv4 custom network on interface br1: Subnet: 192.168.4.0/24 With all the latest changes to the docker network setting in recent releases I am not sure what is causing this. I do have a ubiquity throughout my home if that matters. When this first stated I decided to install an intel nic just for the majority of my docker containers. I move all of them off of eth0 except for plex. etho is the motherboards nic. The intel e1000 nic is a 2 port nic and I could disable eth0 and move it to eth2 if that would help stability. When eth0 goes down and I cannot access Unraid I can still access the other dockers on eth1 on the other network. So, I know the box is not locked up just the eth0. Thank you for any light you canb shine on this issue.

Ahhh. Thank you.

Thank you. I dont know what the renaming of eth0 was about. I did a search and did not find this anywhere in the prior log. Have that server sending logs to another Unraid box. ty

To add more contexts this is the first night after I migrated all of my dockers to eth1 to avoid MacV issues. Just before this log entry was the first docker auto update. I just found that Cloudflare docker was still on bridge of eth0. I turned eth0 to no bridge or bond during my migration. This tends to make me feel that it was my config that borked eth0 connectivity. Ty

This morning, I realized my server was not responding to its eth0 address / GUI. My dockers are on eth1 and they were fine. It wasn't a crash, but the log was odd. I am pasting it here for someone smarter than me to tell me what is going on with the renaming of eth0. Ty in advance, Jan 18 04:00:02 Unraid kernel: veth5b038fa: renamed from eth0 Jan 18 04:00:07 Unraid emhttpd: read SMART /dev/sdh Jan 18 04:00:07 Unraid emhttpd: read SMART /dev/sdd Jan 18 04:00:07 Unraid emhttpd: read SMART /dev/sdb Jan 18 04:00:07 Unraid emhttpd: read SMART /dev/sdf Jan 18 04:00:07 Unraid emhttpd: read SMART /dev/sdc Jan 18 04:00:07 Unraid emhttpd: read SMART /dev/sdi Jan 18 04:00:12 Unraid kernel: eth0: renamed from veth23eb521 Jan 18 04:00:18 Unraid emhttpd: read SMART /dev/sde Jan 18 04:00:28 Unraid kernel: veth7cab188: renamed from eth0 Jan 18 04:00:30 Unraid kernel: eth0: renamed from veth8799693 Jan 18 04:00:37 Unraid kernel: veth902c7e7: renamed from eth0 Jan 18 04:00:46 Unraid kernel: eth0: renamed from veth597cac5 Jan 18 04:00:52 Unraid kernel: vethbad49d0: renamed from eth0 Jan 18 04:01:15 Unraid apcupsd[8228]: Communications with UPS lost. Jan 18 04:01:18 Unraid kernel: eth0: renamed from vethd8f65e5 Jan 18 04:01:24 Unraid kernel: veth1ff0bdf: renamed from eth0 Jan 18 04:01:24 Unraid kernel: eth0: renamed from veth6f9f45e

Latest unraid Local Network 10.66.77 Scan from Unraid server from port 808 Port scanning 192.168.2.2 Starting port 49727 All the Dockers are updated Potential Risk This is associated with someone scanning your network, or a potential data leak opportunity. This is not necessarily harmful.Detection Category Web Server SignatureGPL WEB_SERVER 403 Forbidden Traffic Information Source IP10.66.77.xx:8080 Destination IP192.168.2.2:49272 Activity1.40 KB ActionBlocked Interfacebr0 ProtocolTCP Any help. Should I be worried? TY

I did have it set to 400 and then I read the help: If during a power failure, the UPS has run on batteries for time-out many seconds or longer; apcupsd will initiate a system shutdown. A value of zero disables this timer. If you have a Smart UPS, you will most likely want to disable this timer by setting it to zero. That way, your UPS will continue on batteries until either the % charge remaining drops to or below Battery level or the remaining battery runtime drops to or below minutes. Of course - when testing - setting this to 60 causes a quick system shutdown if you pull the power plug. If you have an older dumb UPS, you will want to set this to less than the time you know you can run on batteries. My second server is set to 0 as well. Am I reading this wrong? Since I can't find any log that are persistent maybe I should pull the plug and test.

Good day all. I have 2 Unraid servers. Both are plugged into the same UPS. Server 1 has the USB cable from the UPS plugged in and is configured in Settings to be the Master. Server 2 is connected to the service "NUT??" via IP:Port. Also, I have a Generac generator on an automatic transfer switch. When power goes out it takes about 90 seconds for the generator to take over and switch power. So, when the power goes out Server 1 (the one connected to the UPS directly) shuts down gracefully immediately. Server 2 stays up. When I get home, I have to power up Server 1. I can confirm this also because neither server does a parity or file system check. I have change around the settings on the UPS app and still I Cannot over come this. Here are my settings on Server 1. If anyone can point me into a direction that would be great. UPS cable: USB Custom UPS cable: UPS type: USB Device: Battery level to initiate shutdown (%): 10 Runtime left to initiate shutdown (minutes): 5 Time on battery before shutdown (seconds): 0 Turn off UPS after shutdown: NO APC001,025,0597DATE2023-07-08 14:27:01 -0400 HOSTNAMEUnraidVERSION3.14.14 (31 May 2016) slackware UPSNAMEUnraidCABLEUSB Cable DRIVERUSB UPS DriverUPSMODEStand Alone STARTTIME2023-07-07 18:55:45 -0400MODELTripp Lite UPS STATUSONLINELOADPCT24.0 Percent BCHARGE100.0 PercentTIMELEFT28.2 Minutes MBATTCHG10 PercentMINTIMEL5 Minutes MAXTIME0 SecondsALARMDELNo alarm NUMXFERS0TONBATT0 Seconds CUMONBATT0 SecondsXOFFBATTN/A SELFTEST??STATFLAG0x05000008 SERIALNOFW-2605 BEND APC2023-07-08 14:27:48 -0400

USB cable swap did not fix the issue. I did fix it though. I turned on the Start APC UPS daemon: to Yes. Log when clean. Hope this helps someone someday. CD

I will give it a try. Ill report back for others. thank you

I connected my trip lite to my unraid this week via usb. But now my logs are filled with this: an 1 04:09:06 Unraid kernel: usb 1-11.2: USB disconnect, device number 59 Jan 1 04:09:07 Unraid kernel: usb 1-11.2: new low-speed USB device number 60 using xhci_hcd J an 1 04:09:07 Unraid kernel: hid-generic 0003:09AE:2012.10F0: hiddev97,hidraw1: USB HID v1.10 Device [Tripp Lite Tripp Lite UPS ] on usb-0000:00:14.0-11.2/input0 Jan 1 04:09:21 Unraid kernel: usb 1-11.2: USB disconnect, device number 60 J an 1 04:09:22 Unraid kernel: usb 1-11.2: new low-speed USB device number 61 using xhci_hcd Jan 1 04:09:22 Unraid kernel: hid-generic 0003:09AE:2012.10F1: hiddev97,hidraw1: USB HID v1.10 Device [Tripp Lite Tripp Lite UPS ] on usb-0000:00:14.0-11.2/input0 Jan 1 04:09:37 Unraid kernel: usb 1-11.2: USB disconnect, device number 61 Should I change the USB cable or just the port? TY CD

Will do. All 5 drives that I purchased have the same errors with the same blocks. Crazy odd. I’m just going to destroy them. And get new ones not used server room picks ty cd

Sorry forgot to attach diag. ty diagnostics-20221118-1836.zip

I know I know. I purchased 5 IBM rebranded ST3000NM0043 3tb SAS drives. All pass bad blocks fine. But when I put each of them into my test Uraid server Uraid shows 128 errors. Every drive Same amount of errors 128 doesn't increase. Very odd. Looking for some advice. Log ov 17 15:01:55 SuperMicro emhttpd: error: ckmbr, 2348: No such file or directory (2): open: /dev/sdf1 Nov 17 15:01:55 SuperMicro kernel: mdcmd (8): import 7 sdf 64 2930266532 0 ST3000NM0043_B1_Z1Y0R1HD0000C4116FAS_35000c50057696593 Nov 17 15:01:55 SuperMicro kernel: md: import disk7: (sdf) ST3000NM0043_B1_Z1Y0R1HD0000C4116FAS_35000c50057696593 size: 2930266532 Nov 17 15:01:55 SuperMicro emhttpd: read SMART /dev/sdf Nov 17 15:02:24 SuperMicro kernel: sd 8:0:4:0: [sdf] tag#3203 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Nov 17 15:02:24 SuperMicro kernel: sd 8:0:4:0: [sdf] tag#3203 Sense Key : 0x5 [current] [descriptor] Nov 17 15:02:24 SuperMicro kernel: sd 8:0:4:0: [sdf] tag#3203 ASC=0x24 ASCQ=0x0 Nov 17 15:02:24 SuperMicro kernel: sd 8:0:4:0: [sdf] tag#3203 CDB: opcode=0x88 88 00 00 00 00 00 00 00 04 40 00 00 04 00 00 00 Nov 17 15:02:24 SuperMicro kernel: critical target error, dev sdf, sector 1088 op 0x0:(READ) flags 0x0 phys_seg 128 prio class 0 Nov 17 15:03:07 SuperMicro emhttpd: error: ckmbr, 2348: No such file or directory (2): open: /dev/sdf1 Nov 17 15:03:07 SuperMicro emhttpd: writing GPT on disk (sdf), with partition 1 byte offset 32KiB, erased: 0 Nov 17 15:03:07 SuperMicro emhttpd: shcmd (977): sgdisk -Z /dev/sdf Nov 17 15:03:07 SuperMicro kernel: sdf: Nov 17 15:03:08 SuperMicro emhttpd: shcmd (978): sgdisk -o -a 8 -n 1:32K:0 /dev/sdf Nov 17 15:03:09 SuperMicro kernel: sdf: sdf1 Log is the same for each drive. Thank you as always CD

Thank you. Helped me from beating my head against the wall again.