Squid

Post your diagnostics.

You pretty much have to run it. And begin to think about converting from ReiserFS to XFS. Reiser hasn't had any updates in years upon years and never will again and eventually may cease to work on future kernel versions.

Try the browser without any addons that may be interfering. Try a different browser.

Yes in real time.

Because there are none to be found. What people do in that circumstance (eg: ESXi) is use "plop" https://forums.unraid.net/topic/38999-compiled-info-unraid-as-guest-on-esxi/, but no clue if this is still valid or not. And the first stumbling block would be that the OS requires a USB stick (even in trial mode)

The options in the drop down require (for everything except the basics) a template to be created via Add Container screen. Just translate that docker run command to be a template instead. You've got 1 port defined, 1 path defined and the repository Otherwise, you're going to do a docker exec -it gunbot /bin/bash (Although your screen shot implies instead of gunbot to use gunbotlast)

If the partition layout doesn't match what Unraid expects, then yes the drive will come up as unmountable when adding to the array. Yes

This is the default

First step is Docker tab, Container Size button

That's correct, but is also something that pretty much you would never do (nor is there any real reason to ever do it)

Right now, disk 12 would be showing up as emulated. Unassign the drive, start the array, stop the array, re-assign the drive as disk 12 start the array. It'll start building onto itself. The drive completely dropped offline -> probably due to a cable connection issue.

You never need to actually pre-clear any drive. If the drive isn't precleared, then Unraid will automatically clear it when adding it as a new drive to a parity protected array Without a parity drive (or on a new config and assigning a parity drive), Unraid will not automatically clear any new additional drive

Yes

Just set disk 12 back to being it. No need to clear it again. It needs to be as large or larger than the largest data drive. And yes Absolutely. You're running in a degraded state right now and you want to clear that up first.

This. Oh and Unraid (like most of the rest of the world) prefers HBA's (or a RAID controller in IT mode vs IR mode)

WD changed their shroud on the drives a number of years ago with the net result that only sata cables which are actually made to spec will work properly. (And many / most of the locking cables are not to spec, whereas every non-locking cable is made to spec). You're looking for a little internal "bump" inside the connector. All non-locking have them and many / most locking do not

Probably 6.8 something. Security over convenience.

Dec 25 18:07:48 Trinity kernel: ata2.00: exception Emask 0x50 SAct 0x80808001 SErr 0x4090800 action 0xe frozen Dec 25 18:07:48 Trinity kernel: ata2.00: irq_stat 0x00400040, connection status changed Dec 25 18:07:48 Trinity kernel: ata2: SError: { HostInt PHYRdyChg 10B8B DevExch } Dec 25 18:07:48 Trinity kernel: ata2.00: failed command: WRITE FPDMA QUEUED Probably because of this. Continual disconnects on the parity drive. Reseat the cabling. Also be aware that since the parity drive is a WD that if you're using a locking Sata Cable, it makes terrible connection unless the cable also has the internal "bump" that non-locking cables have (and many locking cables do not have them). Reseat the cabling (both ends) to the drive without disturbing any of the other cables.

Is SSH Enabled in Management Settings?

Did you run reiserfsck with --check first and did it tell you to run --rebuild-tree? or did you simply run --rebuild-tree (iirc the first thing --check usually says to do is run with --fix-fixable)

Yup. Obviously wrong

Yes

No. What I'm saying is that on average writes to the array average around 50-60MB/s (YMMV), but the OS caches transfers in RAM (hence the 113MB/s -> which is the line speed of 1G network) Eventually the RAM cache gets filled and the system has to slow down transfers because it needs to flush to the hard drive. This results in the dips you're seeing because it can't sustain 113MB/s transfer rate since no matter how you cut it the array can't keep up in transfer speeds. You're not particularly running out of memory. If the system didn't cache the writes at all, you'd see a solid ~60MB/s transfer rate. Since it cache's at the end of the transfer, the average rate over the time frame is going to be ~60MB/s but with the peaks and the dips reflecting the caching. At the schedule you set. Usually during off hours (default is 4am daily)

Changed Status to Closed

Jan 1 08:22:21 NightOwl emhttpd: unclean shutdown detected That cron setting is correct that's listed Dec 1st @ 2:30 am Since it's correct, and it's running at random times, it would appear that your system is randomly rebooting. (Confirmed by your diagnostics) Maybe the system event log in the BIOS would shed some light on what's going on.