gwhal

@Zonediver and @johnnie.black Well that kinds sucks. Obviously I should have done more homework in that regard. Does appear there are some Kaby Lakes that will support ECC so maybe I need to side-grade to one of those. Intel - ECC Memory Supported Memtest won't run till tonight. Family hasn't had access to Plex in 24+ hours and they're starting to twitch.

Thanks @Zonediver but I know that's not the case. SuperMicro lists the make/model that is compatible with their boards and that's what I bought.

Forgot to mention how that screen starts. unRAID boot timer of 3, 2, 1 Posts Loading /bzimage.... OK Posts Loading /bzroot.... OK Screen refreshes (goes black and then back to the "Loading /bzroot.... OK" as the last thing shown to happen) Screen sits at "Loading /bzroot.... OK" for a good 30 seconds Then we go strange pixel per the picture above Then it reboots I'l try memtest to see if the RAM is bad. Everything is brand new so who knows. Everything works fine when I have it boot to GUI though. Can't find any discernible errors in syslog.

So I've moved my old 6.3.3 build from a 10 yr old system to a new build. New build stats: Supermicro X11SSM-F-B Intel i3 7100 2 x 8GB Samsung ECC RAM Case, PSU, blah, blah Reused my 7 x 4TB Constellation drives and replaced my cache drive with a 256GB SSD. Followed the Replace a Cache Drive article on how to do that. So here's the rub. First boot, everything was fine. Used the old USB drive on the internal USB3 header and was great. After the next reboot, here's what I started to get: Here's everything I've done to troubleshoot: Boot to every other mode (unRAID OS GUI Mode is the only one that works) Old USB in different USB3/USB2 ports Set the BIOS to boot to AHCI Set the BIOS to boot to legacy Replace bzroot, bzimage from a fresh download New USB3 32GB, ran through the same tests Is there any sort of log I can look at that would help me/us figure this one out?

All the PC's that backup to the Crashplan container backup to a share on the array and not to the container. 7.04/10.0 GB used on the Docker img file. I did have it running all the time but I turned that off when I wrote my post a few hours ago. Server has 8GB of RAM in it and is only using 25% as of right now. I do see this strangeness in the logs from the other day. Aug 14 15:32:31 Storage avahi-daemon[9805]: Joining mDNS multicast group on interface docker0.IPv4 with address 172.17.42.1. Aug 14 15:32:31 Storage avahi-daemon[9805]: New relevant interface docker0.IPv4 for mDNS. Aug 14 15:32:31 Storage avahi-daemon[9805]: Registering new address record for 172.17.42.1 on docker0.IPv4. I'm using a 172.16.x.x subnet so I'll have to figure out what that's all about. EDIT: OK, figured out the 172.17.42.1 IP address. Must have not updated the ui.properties file the last time. Edited it to 0.0.0.0 and still can't connect with the GUI. I'm about ready to give this up.

Has anyone had a problem with the CrashPlan-Desktop stop being able to connect to the CrashPlan container? I've got the Crashplan-Desktop container set with the defaults (3389 for the port, "--volumes-from CrashPlan" set). If I add both containers to Docker, I can get Desktop container to connect and everything works great. After some time (days?), GUI will no longer load. The only way I've been able to fix it is to delete both containers, delete all the files/folders on the unRAID host, add the containers back, and then setup everything from scratch. At the same time, my 4 CrashPlan clients are actively backing up to the Crashplan container so it's not like Crashplan is dead. I can telnet to 4244 but not to 4243. Any ideas? I'm going to read back through this thread again for the 5th time to see if I missed something. Apparently I missed the tutorial that someone posted earlier.