JorgeB

Run it again without -n or nothing will be done, if it asks for -L use it.

You need to check filesystem on disk4.

Most common cause is bad RAM, start by running memtest.

Changed Status to Closed Changed Priority to Other

This is usually a flash drive problem, try re-creating it using the USB tool or using a different one, and please continue discussion here:

All looks normal like that, if you want post new diags with PCIe ACS disable.

Btrfs errors are from disk4, data corruption detected, this is likely caused by a hardware problem. As for the cache, formatting one of the devices is not a good idea, but post new diags after a reboot, with the array started.

Drive is failing to initialize: Apr 5 18:11:08 DeathStar kernel: .............................................................................................not responding... Apr 5 18:11:08 DeathStar kernel: sd 1:0:3:0: [sdg] Read Capacity(16) failed: Result: hostbyte=0x00 driverbyte=0x08 Apr 5 18:11:08 DeathStar kernel: sd 1:0:3:0: [sdg] Sense Key : 0x2 [current] [descriptor] Apr 5 18:11:08 DeathStar kernel: sd 1:0:3:0: [sdg] ASC=0x4 ASCQ=0x22 Apr 5 18:11:08 DeathStar kernel: sd 1:0:3:0: [sdg] Read Capacity(10) failed: Result: hostbyte=0x00 driverbyte=0x08 Apr 5 18:11:08 DeathStar kernel: sd 1:0:3:0: [sdg] Sense Key : 0x2 [current] [descriptor] Apr 5 18:11:08 DeathStar kernel: sd 1:0:3:0: [sdg] ASC=0x4 ASCQ=0x22 Apr 5 18:11:08 DeathStar kernel: sd 1:0:3:0: [sdg] 0 512-byte logical blocks: (0 B/0 B) Apr 5 18:11:08 DeathStar kernel: sd 1:0:3:0: [sdg] 0-byte physical blocks Apr 5 18:11:08 DeathStar kernel: sd 1:0:3:0: [sdg] Test WP failed, assume Write Enabled Apr 5 18:11:08 DeathStar kernel: sd 1:0:3:0: [sdg] Asking for cache data failed Apr 5 18:11:08 DeathStar kernel: sd 1:0:3:0: [sdg] Assuming drive cache: write through Apr 5 18:11:08 DeathStar kernel: sd 1:0:3:0: [sdg] Spinning up disk... Apr 5 18:12:49 DeathStar kernel: ..................................................................................................not responding... Apr 5 18:12:49 DeathStar kernel: sd 1:0:3:0: [sdg] Read Capacity(16) failed: Result: hostbyte=0x00 driverbyte=0x08 Apr 5 18:12:49 DeathStar kernel: sd 1:0:3:0: [sdg] Sense Key : 0x2 [current] [descriptor] Apr 5 18:12:49 DeathStar kernel: sd 1:0:3:0: [sdg] ASC=0x4 ASCQ=0x22 Apr 5 18:12:49 DeathStar kernel: sd 1:0:3:0: [sdg] Read Capacity(10) failed: Result: hostbyte=0x00 driverbyte=0x08 Apr 5 18:12:49 DeathStar kernel: sd 1:0:3:0: [sdg] Sense Key : 0x2 [current] [descriptor] Apr 5 18:12:49 DeathStar kernel: sd 1:0:3:0: [sdg] ASC=0x4 ASCQ=0x22 Apr 5 18:12:49 DeathStar kernel: sd 1:0:3:0: [sdg] Attached SCSI disk Try swapping cables/backplane slot whit another drive, if it still fails it's likely a drive issue.

Very bad idea to use USB for array devices, I guess no other options with a NUC but you're better off getting different hardware for the server.

Please post the diagnostics: Tools -> Diagnostics

The option is to run reiserfsck --rebuild--tree.

The errors you're seeing are because of the other pool device dropping earlier, you need to run a scrub, more info here.

Problem with disk8 looks more like a power/connection issue, replace/swap both cables and try again.

Docker service is starting, image looks new, you can just re-add your dockers using CA previous apps.

Get one of the recommended LSI HBAs, cables mostly depend on if you end up getting a SAS2 (SFF-8087) or SAS3 (SFF-8643) model.

Likely a flash drive problem, if you're using a USB 3.0 port try USB 2.0.

One thing you can try it to boot the server in safe mode with all docker/VMs disable, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one.

As should all the shares.

Those are wrong, it should be: drwxrwxrwx 1 nobody users

Please post output of: ls -al /mnt/user

Reboot and post new diags after array start.

Note that parity won't be 100% valid due to the read errors on disk5.

Check filesystem on disk10: https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui Disk5 appears to be failing, and since parity is not valid you may lose some data there.

Set it to xfs or run the check from the CLI.

Not seeing any trim error on the syslog.