JorgeB

Possibly related to this? https://forums.unraid.net/topic/3531-looking-for-better-ideas-how-how-to-sleepsuspend-my-unraid-box/?do=findComment&comment=1128998

Ignore the above, missed the times: Jul 8 18:50:52 Biest elogind-daemon[1977]: Power key pressed. Jul 8 18:50:52 Biest elogind-daemon[1977]: Powering Off... Jul 8 18:50:52 Biest elogind-daemon[1977]: System is powering down.. Jul 8 18:50:52 Biest elogind-daemon[1977]: Suspend key pressed. Jul 8 18:50:52 Biest shutdown[5530]: shutting down for system halt Jul 8 18:50:52 Biest init: Switching to runlevel: 0 Is this elogin something you installed? Can you try without it.

Unraid tracks devices by serial number, not by filesystem UUID, once you assign the new disk Unraid only cares about that one.

Something is missing, a shutdown either by using the GUI or a quick press of the power button, should always be logged like this: Jul 9 08:53:04 Test2 kernel: md: sync done. time=2860sec Jul 9 08:53:04 Test2 kernel: md: recovery thread: exit status: 0 Jul 9 08:53:31 Test2 shutdown[48304]: shutting down for system halt Jul 9 08:53:31 Test2 init: Switching to runlevel: 0 Jul 9 08:53:31 Test2 init: Trying to re-exec init Please test that yourself by actually pressing briefly the power button.

Please use the existing plugin support thread:

You just need to restore the config folder from the backup, and if you want to boot UEFI rename EFI- to EFI.

I assume it shutdown between these? Jul 8 18:06:44 Biest rc.inet1: ip link set lo down Jul 8 18:45:06 Biest kernel: microcode: microcode updated early to revision 0x49, date = 2021-08-11 If yes, not shutdown command, so possibly a hardware issue.

Issue looks NIC related, cannot tell you if it's serious or not, but assuming the NIC keeps working after these probably not.

Try using the Google DNS servers.

Array did start in safe mode, but not all services started and there were still some strange errors, last diags look mostly OK, except some wrong csrf errors.

emhttp is segfaulting, please try rebooting in safe mode, if still the same post new diags.

Shares as just all the top level folders, and new ones would be created, but with the default settings, if you want to keep current share settings copy all the files from /config/shares, for the array assignments you need /config/super.dat, and for the pool(s) the /config/pools folder, assuming v6.9 or newer. Best to backup, re-create the flash drive and copy just what you need.

If there is bit-rot in a disk, which in my experience is extremely rare, and you run a correcting check parity will be incorrectly updated, note that we always recommend running non correcting checks unless sync errors are expected, like after an unclean shutdown for example, if sync errors are found without a known reason and the user has checksums for the data disks he can then first check those and then decide how to proceed. Depends on how you do the backups, I for example use btrfs send/receive to backup all my array disks 1 to 1, the stream is checksummed all the way, if there's a checksum error on read it will abort, and as far as I understand the sent metadata also includes the checksums. Usually you cannot have just the benefits of something, Unraid is very flexible with for example using the full capacity of different disks sizes, recovering the data from the remaining disks if you lose more disks that redundancy can save, but there are also some drawbacks, like array speed and array bit-rot fix, there are the pools where can have redundancy, but btrfs raid5/6 is not stable enough for the typical user and raid1/10 is not very efficient for large pools, soon you'll be able to create a zfs pool, of course you'll lose some of Unraid array advantages, like can't fully use different size disks with raidz and you can lose the complete pool if more disks than current redundancy can support are lost, again you cannot have everything.

Usually yes, assuming no RAID controllers involved.

Logs are not saved automatically to /boot/logs, they can be if you configure syslog server to save there, typing 'diagnostics' on the console will save the complete diags to that folder, but the syslog will only cover the current boot.

Run a scrub on the pool, though like mentioned here nocow shares can't be fixed, since there are no checksums, your domains share is nocow, so assuming the vdisks are there you might need to restore them from backups if available, always recommend using cow shares for anything btrfs. As for the cause of the problem, most likely a device/firmware/controller issue, some writes were lost, all should be recovered after a scrub (except nocow shares like mentioned).

Enable the syslog server and post that and the diagnostics after a crash.

That's an unsigned disk, danger is user shares and disk shares for array/pool disks.

Out of memory.

There's an OOM error, other than that it's clean, see if you can limit resources to docker/VMs.

Assuming it's XFS you can, just need to change the UUID first, that can be done in the UD settings page.

Yes, but parity check can only go as fast as the slowest disk at that position.

Not really, but you are have some USB disks in the array, those are not recommended, and not just for performance reasons, you can use the diskspeed docker to benchmark your disks/controllers.

There won't be a log entry for anything that reads a disk and makes it spin up, search the forum, there are some tools to help find what's causing them to spin up.

SMART reads happen when Unraid detects that the disk spins up, not the other way around, i.e., something else is spinning up the disks first.