DontWorryScro

right but not the <os> section.

for people who booted up fine the first time around, decided to give more cores or ram and went back to find the apple logo upper left and weird graphical anomalies try restoring the <os> section of the xml with what was originally there when you first installed. You're welcome. <os> <type arch='x86_64' machine='pc-q35-3.1'>hvm</type> <loader readonly='yes' type='pflash'>/mnt/user/domains/MacinaboxCatalina/ovmf/OVMF_CODE.fd</loader> <nvram>/mnt/user/domains/MacinaboxCatalina/ovmf/OVMF_VARS.fd</nvram> </os>

Is it really possible that my motherboard kept rebooting because it's date and time were insanely incorrect? It was not syncing with a time server and it was set to sometime in the early 1900's lol. Perhaps coincidentally since I've corrected the date and time in IPMI I've not had a crash.

I have a Supermicro x9scm-f motherboard and I'm trying to figure out how to get Fan 2 to react to CPU temp. In the IPMI tool I've been able to connect to the ip and have all the sensors read but I'm only getting the Temp sensor option in Fan Control for Auto, System Temp, Peripheral Temp and HDD Temperature. How do I go about getting Fan 2 which is my CPU fan to ramp up based on CPU temp?

The initial install goes great. Editing the VM afterwards to add CPU cores and RAM makes it boot to some display anomaly with distorted loading bars. Looks like some sort of resolution glitch using VNC.

I only see fan sensor events. Are these relevant? I just figured this was akin to benign messaging to display fan speed changes based on temperature.

ya ran it for 24 hours with zero errors just yesterday

Alright so docker loading may be totally unrelated to my issue. I may just have a bad motherboard. After enough hard reboots my usb starts to get corrupted and loses the server info and defaults to Tower from the server name I gave it on initial install. 2nd bad motherboard in a row? Supermicro x9scm-f. Just wish I could definitively pin point if my issue is software or hardware related. I hate blindly throwing money at issues in a lame pin the tail on the donkey game of buying, applying, and praying its now fixed. Any help available from Unraid?

Can someone check their syslog and tell me what your system does after it's loaded the last docker successfully? My server has been rebooting at this point. I feel like if I know what the next process is after the last docker was loaded I may know where my server is dying. So here's a snippet from a recent syslog. For me, openvpn is my last docker alphabetically to load. After your last one loads what does your syslog show? Thanks.. Oct 27 15:16:17 Snuts rc.docker: nextcloud: started succesfully! Oct 27 15:16:17 Snuts kernel: docker0: port 6(vethfd3be47) entered blocking state Oct 27 15:16:17 Snuts kernel: docker0: port 6(vethfd3be47) entered disabled state Oct 27 15:16:17 Snuts kernel: device vethfd3be47 entered promiscuous mode Oct 27 15:16:17 Snuts kernel: IPv6: ADDRCONF(NETDEV_UP): vethfd3be47: link is not ready Oct 27 15:16:17 Snuts kernel: docker0: port 6(vethfd3be47) entered blocking state Oct 27 15:16:17 Snuts kernel: docker0: port 6(vethfd3be47) entered forwarding state Oct 27 15:16:17 Snuts kernel: eth0: renamed from veth2d15c3f Oct 27 15:16:17 Snuts kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethfd3be47: link becomes ready Oct 27 15:16:17 Snuts rc.docker: openvpn-as: started succesfully! Oct 27 15:16:36 Snuts kernel: TCP: request_sock_TCP: Possible SYN flooding on port 39268. Sending cookies. Check SNMP counters. >crash and reboot here<

Sounds similar. Maybe I'll bite the bullet and just buy a new motherboard. Thanks.

I am fearing but also hoping this is the case. I just don't look forward to the prospect of putting money into yet another (third) motherboard in the hopes that it fixes it without knowing exactly why I'm having the issue. If it's a bad USB? Bad CPU? I'm running memtest86+ again right now and will let it roll for a while. It just is concerning to me that I can run memtests for hours on end without a reboot but something in UnRaid is sinking me. Certain things point to software. Certain things point to hardware. I just don't know enough about servers and computer software/hardware to deduce which. I may scrap it all and start from scratch though. And kick myself because at the end of the day with the money I've put in to fix or replace shoddy ebay items and/or troubleshooting I could have just gone for a more modern architecture with more cores.

I changed the USB mount point to a different port. The problem persists. Still not sure if this is hardware of software.

ok ill keep replying to my own post in the hopes that something resonates with someone. But also thank you for your insight and help with troubleshooting, Testdasi. I have swapped USB ports and will see where we wind up. I will say I've noticed that without fail the reboots happen after the last docker gets init-ed. I initially thought OpenVPN-as might be a culprit because after the "openvpn-as: started succesfully!" message in the syslog it would reboot. However I came to find that it wasn't OpenVPN-as that was triggering the reboot. Openvpn-as was merely the last docker alphabetically in my docker list. To test this I deleted Openvpn and sure enough the next time around, nextcloud was the docker that loaded last before the system rebooted. So something about initing the dockers is triggering a reboot it seems? Which to my ignorant mind sounds like software, not hardware. Here's an example of a crash happening that was so bad that on restart had reverted back to some sort of default state and renamed my server back to Tower. Sure would be nice to have some UnRaid rep chime in here with some help. Oct 25 15:54:47 Snuts rc.docker: mariadb: started succesfully! Oct 25 15:54:47 Snuts kernel: br-3918c056127b: port 2(veth2b247b1) entered blocking state Oct 25 15:54:47 Snuts kernel: br-3918c056127b: port 2(veth2b247b1) entered disabled state Oct 25 15:54:47 Snuts kernel: device veth2b247b1 entered promiscuous mode Oct 25 15:54:47 Snuts kernel: IPv6: ADDRCONF(NETDEV_UP): veth2b247b1: link is not ready Oct 25 15:54:47 Snuts kernel: br-3918c056127b: port 2(veth2b247b1) entered blocking state Oct 25 15:54:47 Snuts kernel: br-3918c056127b: port 2(veth2b247b1) entered forwarding state Oct 25 15:54:47 Snuts kernel: br-3918c056127b: port 2(veth2b247b1) entered disabled state Oct 25 15:54:48 Snuts kernel: eth0: renamed from veth6d65f8b Oct 25 15:54:48 Snuts kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth2b247b1: link becomes ready Oct 25 15:54:48 Snuts kernel: br-3918c056127b: port 2(veth2b247b1) entered blocking state Oct 25 15:54:48 Snuts kernel: br-3918c056127b: port 2(veth2b247b1) entered forwarding state Oct 25 15:54:48 Snuts rc.docker: nextcloud: started succesfully! Oct 25 15:54:48 Snuts kernel: docker0: port 6(vethee229b0) entered blocking state Oct 25 15:54:48 Snuts kernel: docker0: port 6(vethee229b0) entered disabled state Oct 25 15:54:48 Snuts kernel: device vethee229b0 entered promiscuous mode Oct 25 15:54:48 Snuts kernel: IPv6: ADDRCONF(NETDEV_UP): vethee229b0: link is not ready Oct 25 15:54:48 Snuts kernel: docker0: port 6(vethee229b0) entered blocking state Oct 25 15:54:48 Snuts kernel: docker0: port 6(vethee229b0) entered forwarding state Oct 25 15:54:48 Snuts kernel: eth0: renamed from vethcd7dd32 Oct 25 15:54:48 Snuts kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethee229b0: link becomes ready Oct 25 15:54:48 Snuts rc.docker: openvpn-as: started succesfully! Oct 25 15:55:02 Snuts sSMTP[19070]: Creating SSL connection to host Oct 25 15:55:02 Snuts sSMTP[19070]: SSL connection using TLS_AES_256_GCM_SHA384 Oct 25 15:55:05 Snuts sSMTP[19070]: Sent mail for [redacted]@gmail.com (221 2.0.0 closing connection j11sm93555pfa.127 - gsmtp) uid=0 username=root outbytes=668 Oct 25 17:10:43 Tower kernel: mdcmd (44): set md_write_method 1 Oct 25 17:10:43 Tower kernel: Oct 25 17:10:43 Tower cache_dirs: Arguments=-l off Oct 25 17:10:43 Tower cache_dirs: Max Scan Secs=10, Min Scan Secs=1 Oct 25 17:10:43 Tower cache_dirs: Scan Type=adaptive Oct 25 17:10:43 Tower cache_dirs: Min Scan Depth=4 Oct 25 17:10:43 Tower cache_dirs: Max Scan Depth=none Oct 25 17:10:43 Tower cache_dirs: Use Command='find -noleaf' Oct 25 17:10:43 Tower cache_dirs: ---------- Caching Directories --------------- Oct 25 17:10:43 Tower cache_dirs: .Trash-99 Oct 25 17:10:43 Tower cache_dirs: Archives Oct 25 17:10:43 Tower cache_dirs: Media Oct 25 17:10:43 Tower cache_dirs: Test Oct 25 17:10:43 Tower cache_dirs: appdata Oct 25 17:10:43 Tower cache_dirs: data Oct 25 17:10:43 Tower cache_dirs: domains Oct 25 17:10:43 Tower cache_dirs: downloads Oct 25 17:10:43 Tower cache_dirs: isos Oct 25 17:10:43 Tower cache_dirs: nextcloud Oct 25 17:10:43 Tower cache_dirs: system Oct 25 17:10:43 Tower cache_dirs: windowsdisk

After 18 hours it indeed rebooted again and then went into such a severe reboot loop that it could not even turn on. It just kept clicking as it tried to start. In the process it nuked the USB and seems to have reset to some default state using Tower as the server name (different than what I had it set as). This whole process is really testing my patience.

If I start getting random reboots again I'll try a different port. It's currently mounted on the internal USB port on the motherboard itself.

It looks like this was actually a USB issue. Whatever made the server crash initially seemed to have corrupted the USB stick. I pulled the stick, repaired it in Windows, reformatted with the UnRAID installer, restored the data from a previous flash drive backup and I've been up and running crash-free for the past 10 hours. At least for now, I'll call this solved.

Seems like the repeating theme I see, though maybe just coincidence, is this line shortly before a reboot: Oct 24 14:44:57 Snuts rc.docker: openvpn-as: started succesfully! Edit: I've restored appdata from an older backup before all these shenanigans started to see if somehow the Openvpn docker got corrupted and was causing my entire server to reboot. (But is that possible?) Edit2: Nah, just rebooted again

Just crashed again right around here: Oct 24 14:44:57 Snuts rc.docker: openvpn-as: started succesfully! Oct 24 14:46:32 Snuts autofan: Highest disk temp is 44C, adjusting fan speed from: 56 (21% @ 484rpm) to: 233 (91% @ 1695rpm) Oct 24 14:47:01 Snuts ool www[28109]: /usr/local/emhttp/plugins/dynamix/scripts/rsyslog_config Oct 24 14:47:03 Snuts rsyslogd: [origin software="rsyslogd" swVersion="8.1903.0" x-pid="30855" x-info="https://www.rsyslog.com"] start Oct 24 14:49:50 Snuts ntpd[1780]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Oct 24 14:50:38 Snuts autofan: Highest disk temp is 45C, adjusting fan speed from: 233 (91% @ 1737rpm) to: FULL (100% @ 1890rpm) Oct 24 14:54:00 Snuts root: Fix Common Problems Version 2019.10.13a Oct 24 14:54:07 Snuts root: Fix Common Problems Version 2019.10.13a Oct 24 15:09:39 Snuts kernel: microcode: microcode updated early to revision 0x21, date = 2019-02-13 Oct 24 15:09:39 Snuts kernel: Linux version 4.19.56-Unraid (root@matrix) (gcc version 8.3.0 (GCC)) #1 SMP Thu Jun 27 13:13:13 BST 2019 Oct 24 15:09:39 Snuts kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot Oct 24 15:09:39 Snuts kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' Oct 24 15:09:39 Snuts kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' Oct 24 15:09:39 Snuts kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' Oct 24 15:09:39 Snuts kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 Oct 24 15:09:39 Snuts kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. Oct 24 15:09:39 Snuts kernel: BIOS-provided physical RAM map: Oct 24 15:09:39 Snuts kernel: BIOS-e820: [mem 0x0000000000000000-0x00000000000987ff] usable Oct 24 15:09:39 Snuts kernel: BIOS-e820: [mem 0x0000000000098800-0x000000000009ffff] reserved Oct 24 15:09:39 Snuts kernel: BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved Oct 24 15:09:39 Snuts kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000ae9ebfff] usable

I had considered this as well. I bought the PSU brand new from EVGA when I built this server about 6 weeks ago does but that should not exclude it from being a potential cause. Unfortunately I'd have to drop some coin on a new, more powerful one to test it. But as a last resort I'll go that way. Or try my hand at working with EVGA on some sort of upgrade discount.

More than happy to provide additional info if there’s not enough to go on.

Edit: It was an underpowered PSU. Should have taken in to account the fact that I had expanded exponentially with HDDs and had a top tier, power hungry CPU. Swapped out the 550w for a 1000w and flawless ever since. I have a fairly new Unraid server (version 6.7.2) that was running flawlessly until about 3 days ago. It all started when I was moving ISOs around via mapped drive locations on my Windows 10 PC. This was the first time the server went straight to shut down as if someone pulled the plug. I believe the reboot happens because bios is set to return to last state after power failure. Since that initial reboot things have gone downhill. Of course after the hard reset the server goes in to a parity check which in and of itself seems to tax the system into crashing and rebooting again. I have kept an eye on temps and it does seem that some of these reboots are attributed to heating issues. But it also seems that even when I am specifically watching for heat issues, if I transfer large amounts of data between shares or from mapped drives on my Windows pc it will trigger a reboot. I still suspect this is a heat issue but I am not sure how else to tackle this. I notice the CPU fan is often times at 100% when I'm up around 60C. I'm not overclocked here and I'm hardly doing anything I'd consider CPU intensive. If nothing is immediately apparent in the diagnostics I fear I'm in for a full tear down and rebuild with special emphasis on thermal paste application. Do I really need to go the cpu tower cooler route for a server build? Is something else going on here? I tried to set up a syslog server on my Windows pc to grab info about why my server was crashing but I can't really figure out how to get it up and running. My hardware: Supermicro X9SCL-F Intel Xeon E3-1270 v2 32 GiB DDR3 ECC Kingston Noctua NH L9i EVGA SuperNOVA G2 550w 80+ Gold PSU A combo of shucked 10Tb and 8Tb WD white label reds with a smattering of pre-used 5GB/6GB HGST drives ADATA and Samsung SSDs as unassigned devices (and appdata) HP EX920 1TB m.2 cache drive GTX 1050 gpu Mellanox MNOA19-XTR Connectx2 10 gigabit card LSI SAS9211 card Some PCIe nvme card My dockers: binhex-delugevpn binhex-jackett binhex-krusader binhex-plexpass binhex-radarr binhex-sonarr duckdns Firefox letsencrypt mariadb nextcloud openvpn-as Plugins: CA Auto Turbo Write Mode CA Auto Update Applications Ca Backup/Restore Appdata CA Cleanup Appdata Community Applications controlR Disk Location Dynamix Active Streams Dynamix Auto Fan Control Dynamix Cache Directories Dynamix Date Time Dynamix S3 Sleep Dynamix SCSI Devices Dynamix SSD Trim Dynamix System Buttons Dynamix System Information Dynamix System Statistics Dynamix System Tempurature Fix Common Problems IPMI support Nerd Tools Preclear Disks Speedtest Command Line Tool Statistics Tips and Tweaks Unassigned Devices unBALANCE Unraid Nvidia User Scripts DontWorryScro-diagnostics-20191024-0500.zip

I had Sonarr and Radarr stop communicating with binhex-delugevpn sometime in the past 48 hours. Could not for the life of me figure it out. I could not add or search for shows and movies without getting an error. And testing Deluge as the download client failed. Then I realized I had both Sonarr and Radarr using the proxy provided by Deluge, Privoxy. I selected Use Proxy "No" and all the errors went away and Sonarr and Radarr are once again working. Is the problem with the Privoxy function or is it with PIA? Edit: Also I just now realized all the trackers residing in Jackett were also all erroring out. Removed proxy info from Jackett and all is well again. Is something currently wrong with the privoxy function? 2nd Edit: Restoring Privoxy appdata from a backup got me functionality back. Disregard the post. Seems I may have had some corrupt files.

It was the one you had linked me. itConfig for Deluge v2

Looks as though using Docker Safe New Perms in Tools fixed me up.

Not sure if it's relevant but this seemed to have started after I upgraded from my trial of UnRaid to UnRaid pro and stopped and restarted the array. I did also add 2 users but did not set them on any shares yet. I had network mapped to my Media folders and a download folders via my 10 Gigabit Mellanox Connectx2 card and things were fine. And now I get a prompt from Windows Security asking me to enter network credentials. I've tried every combination I can think of. root+password, one of the new users I just created + password, the name of the server + password. Even my Windows users login for my PC that I'm using to access Unraid through the browser. All to no avail. When I do try to enter a log in (which I did not have to before) I get this: What changed?