trurl

Mouseover the 👎 and it will tell you what it is (40 reallocated). Since it passed extended test and there aren't many of those it's probably OK for now. You can Acknowledge by clicking on 👎 and it will warn again if that or any of the other monitored attributes increase.

https://wiki.unraid.net/Manual/Docker_Management#Re-Installing_Docker_Applications

https://wiki.unraid.net/Manual/Docker_Management#Re-Create_the_Docker_image_file

Make sure your server has the correct time 

All of your shares except B-----s are set to prefer cache, which means it should keep them on cache and move any that are on the array to cache.
 
Typically you only want appdata, domains, system shares set cache:prefer, at least until you have a better idea of what and why you want other shares to stay on cache.

SMART Extended Self-test Log Version: 1 (1 sectors) Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 90% 35 60768 Definitely return it

See the Unassigned Devices thread for how to use that plugin. If you are on v6.10+ you can also install Dynamix File Manager plugin to work with the files directly on the server.
 
If all this is too much to learn to get started you can just transfer over the network.

No, you haven't, so system share still has files on the array that can't be moved because they are open.
 
 

CRC errors are connection problems, the drive firmware has detected inconsistent data received (checksum). The data is resent in these cases so usually nothing to worry about.
 
Click on the SMART warning on the Dashboard page for that disk and you can acknowledge the current value, then it will warn again if it increases. If it does increase frequently you need to figure out why.
 
Do you have Notifications setup to alert you immediately by email or other agent as soon as a problem is detected?
 
Do any of your other disks have SMART warnings on the Dashboard page?
 
Didn't look at syslog, if you want us to take a closer look at your setup, attach diagnostics to your NEXT post in this thread.

Have you rebooted?

Your go file isn't starting the webUI. Unlikely the result of the upgrade. Download any version and unzip it to see what the stock go file should look like in config/go

Looks like parity2 disk is failing. Replace

Depends on whether you have Krusader configured to allow disk access. If you are on v6.10+, Dynamix File Manager plugin is better and you can get rid of Krusader.

array
btrfs raid1 pool
another pool, could be xfs if single disk.
 

Looks like you have 250G Minimum Free for that share.

Have you done memtest recently?

Flash is showing % flash drive used, Log is showing % log space used, Docker is showing % docker.img used.
 
At command line
df -h might give some more insight:
Filesystem      Size  Used Avail Use% Mounted on ... /dev/sda1        15G  1.1G   14G   7% /boot ... tmpfs           128M   11M  118M   9% /var/log ... /dev/loop2       20G  9.3G  9.9G  49% /var/lib/docker  
Also
free -h  
total used free shared buff/cache available Mem: 30Gi 5.6Gi 373Mi 1.3Gi 24Gi 23Gi  

Do you have a current flash backup?
 
You can get the zipped download of whichever version at the download link in upper right of the forum, then copy the bz* files from the download to the top level of your flash drive

docker.img only using a few MB, probably empty really.
 
https://wiki.unraid.net/Manual/Docker_Management#Re-Create_the_Docker_image_file
 
https://wiki.unraid.net/Manual/Docker_Management#Re-Installing_Docker_Applications

Since you're on 6.10, install Dynamix File Manager plugin.

You might try Tools - New Permissions on your Apple share.

memtest86.com

Not exactly wrong, but mostly unnecessary.
 
There is no reason to preclear the disk. There is only one scenario where Unraid requires a clear disk. That is when adding a disk to a new slot in an array that already has valid parity. This is so parity will remain valid, since a clear disk is all zeros which has no effect on parity. In this scenario, if the disk hasn't been precleared Unraid will clear it.
 
Other than that one scenario, preclear is only for testing, and not really even necessary for that.
 
When you use a disk for rebuild, the entire disk is overwritten, so it doesn't matter at all what is on the disk, clear, empty, full of data whatever.
 
Also, it isn't even necessary to remove the drive, all you need to do is start the array with the drive unassigned to get Unraid to consider the drive a replacement when you reassign it.
 

Left-most icon on the main bar of your Unraid webUI
 

Aug 2 00:10:59 Tower kernel: sd 1:0:4:0: [sdf] tag#4651 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=6s Aug 2 00:10:59 Tower kernel: sd 1:0:4:0: [sdf] tag#4651 Sense Key : 0x3 [current] [descriptor] Aug 2 00:10:59 Tower kernel: sd 1:0:4:0: [sdf] tag#4651 ASC=0x11 ASCQ=0x0 Aug 2 00:10:59 Tower kernel: sd 1:0:4:0: [sdf] tag#4651 CDB: opcode=0x88 88 00 00 00 00 01 c2 c4 b5 58 00 00 02 38 00 00 Aug 2 00:10:59 Tower kernel: blk_update_request: critical medium error, dev sdf, sector 7562638792 op 0x0:(READ) flags 0x0 phys_seg 57 prio class 0 Aug 2 00:10:59 Tower kernel: md: disk1 read error, sector=7562638728 Aug 2 00:10:59 Tower kernel: md: disk1 read error, sector=7562638736 Aug 2 00:10:59 Tower kernel: md: disk1 read error, sector=7562638744 ... Parity sync was still ongoing when those were taken, and later diagnostics seem to indicate parity valid, so it might be possible to rebuild disk1 to a new disk.
 
But if disk1 didn't have any data on it yet I don't think I would bother, and it might be better to not trust parity anyway.
 
You can start over without that disk if you want by doing New Config without it and rebuilding parity.