Squid

Nov 20 17:59:33 nas CA Backup/Restore: Backup / Restore Completed Why not instead restore the backup you had previously made before the SSD swap? It always works Probably about 100x faster than using UnBalance to move stuff around and at least 1000x faster than doing the same thing with mover? Having you tried recreating the docker image yet?

General rule. Any random card will pass through. The difficulties come mainly via the motherboard choice, and how it's set up for IOMMU groups etc and whether if you need it the ACS override settings will work for you... When in doubt, you're always better off with full size motherboards instead of mini ATX as they at least give you more options for configurations / playing around.

Only reason for a drive to spin back up is that a read is currently happening for it. If the parity also spins back up at the same time, then a write is happening to that data drive. In terms of why, the first guess is that your docker image file (or folder) is sitting on a data disk. Alternatively, your appdata share is on a data drive. Additionally, if you're running NextCloud / Owncloud then due to their own designs, any disk which is a member of its media shares will always stay spinning.

Probably post parameters

Top of my head, the mce is because of the microcode update being issued to the CPU and is probably no issue Nov 19 16:35:03 Punisher kernel: microcode: CPU0: patch_level=0x08701021 Nov 19 16:35:03 Punisher kernel: microcode: CPU1: patch_level=0x08701021 Nov 19 16:35:03 Punisher kernel: microcode: CPU2: patch_level=0x08701021 Nov 19 16:35:03 Punisher kernel: microcode: CPU3: patch_level=0x08701021 Nov 19 16:35:03 Punisher kernel: microcode: CPU4: patch_level=0x08701021 Nov 19 16:35:03 Punisher kernel: microcode: CPU5: patch_level=0x08701021 Nov 19 16:35:03 Punisher kernel: microcode: CPU6: patch_level=0x08701021 Nov 19 16:35:03 Punisher kernel: microcode: CPU7: patch_level=0x08701021 Nov 19 16:35:03 Punisher kernel: microcode: CPU8: patch_level=0x08701021 Nov 19 16:35:03 Punisher kernel: microcode: CPU9: patch_level=0x08701021 Nov 19 16:35:03 Punisher kernel: microcode: CPU10: patch_level=0x08701021 Nov 19 16:35:03 Punisher kernel: microcode: CPU11: patch_level=0x08701021 Nov 19 16:35:03 Punisher kernel: microcode: Microcode Update Driver: v2.2. Nov 19 16:35:03 Punisher kernel: IPI shorthand broadcast: enabled Nov 19 16:35:03 Punisher kernel: sched_clock: Marking stable (11946833916, 343487151)->(12438976477, -148655410) Nov 19 16:35:03 Punisher kernel: mce: [Hardware Error]: Machine check events logged Nov 19 16:35:03 Punisher kernel: registered taskstats version 1 Nov 19 16:35:03 Punisher kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 27: faa000000000080b Nov 19 16:35:03 Punisher kernel: mce: [Hardware Error]: TSC 0 MISC d012000800000000 SYND 5d000000 IPID 1002e00000500 Nov 19 16:35:03 Punisher kernel: mce: [Hardware Error]: PROCESSOR 2:870f10 TIME 1668897207 SOCKET 0 APIC 0 microcode 8701021

Stop the docker service (Docker Tab). Enable Template Authoring Mode Now when you're on the template screen there will be an addition button named "Save" Clicking it will show both the generated XML and the docker run command that would be issued

Should be noted that 2666 is also an overclock. The actual speed of the memory is 2133 (https://www.corsair.com/ca/en/Categories/Products/Memory/VENGEANCE-LPX/p/CMK32GX4M2E3200C16#tab-tech-specs) and that is the speed that it should be run at. Anything over that speed will always introduce instability into any system

Those errors are indicative of a poor connection to the drive(s) either sata or power (SATA cabling is a very poor design). Reseat the cabling at both ends. ATA3 is WDC WD100EZAZ-11TDBA0 - disk 9 Take care not to disturb cabling adjacent to the ones you're reseating (or reseat them all)

Unraid runs from RAM and the files are unpacked from the flash drive. To make any changes persistent, you must reapply them via an appropriate script either via the user scripts plugin or via the "go" file (/config/go) on the flash drive

Something (odds on a container) is creating it. There are no symlinks or anything that puts boot into a user share. The date however is weird. You can always browse through the share via the shares tab to see whats in there.

ls -ail /mnt/user It'll be listed.

Go to /var/lib/docker That's where the image (or folder) ultimately resides But you might find it easier to simply go to the console of the individual container via the webGUI rather than sorting out all of the various layers etc within the docker subsystem.

And while I haven't checked this (since I don't use it), any out of tree driver being used or a proprietary module (eg: nVidia) will also wind up tainting the kernel.

Referencing everything by the user shares (/mnt/user/...) the system will sort it all out by itself. Even if for some reason you directly reference the share by disk (/mnt/disk7/...) then you can either adjust the references or simply assign the disks to the same slot. Nowhere does the system force you to have disk4, and the OS is perfectly happy having disks1-3 and disks 5-7 assigned with 4 unassigned

What created the video files in the first place?

What is the error in Sonarr's logs about why it won't import?

That screenshot looks like you or something else (cat perhaps) is initiating the shutdown.

Either you're running a script which is creating a share named boot (/mnt/user/boot) or a path mapping on one of your docker containers has a path mapping of /mnt/user/boot Whenever that script runs or the container starts it will recreate it

There's nothing wrong with enabling the syslog server mirror to flash. The message warning that appears is Which is 100% correct Everything in Unraid, especially once you get to VMs is "tainted" They aren't errors per se, but rather a flag / note to the kernel maintainers that the particular module / executable etc isn't the "stock" module that comes with the base kernel but has been modified. The maintainers will see this if you are ever submitting to them a bug report etc and then choose whether or not to help you because the coding has been modified. In other words, it is not an error at all in the Unraid world and is expected.

Plugins get installed from the flash drive and nothing to do with any data on the array

yes

That is disk 1 You need to use --rebuild-tree As an aside, you should highly consider copying the files off of the reiser disks and putting them onto XFS formatted disks. ReiserFS has been effectively deprecated for a decade and will soon be removed from the Linux Kernel.

fixed

Most likely the 36C. Unlikely its the ones that are the temp of the sun...

Should this plugin now be deprecated @Mettbrot?