trurl

No, the USB flash drive is required for licensing.
 
None of the OS is installed to any of your storage.
 
The OS is unpacked fresh from archives on the flash drive, into RAM, at each boot, and the OS runs completely in RAM. Think of it as firmware.
 
The flash drive also saves settings you make from the webUI in the config folder so your configuration can be reapplied at boot.
 
Other than that, the flash drive isn't accessed much.

I didn't finish all I had to say because you don't want to do anything else at all unless and until RAM is working perfectly.
You need to run a correcting parity check, but not until RAM is working perfectly.
 
I don't know what that was about either. We don't see reiser that much in syslogs anymore, not since I have been studying diagnostics. It seemed to be doing some sort of reiser check against all your devices regardless of how they were assigned, and it didn't think sde looked like a good reiser disk, which it isn't.
 
Usually when working with an array disk, it would be referred to as md# instead of sdX, because operations on the md devices include parity updates when writing or all the array to calculate the data when emulating a missing disk or whatever needs to be done with a disk assigned to the parity array. If you were to write the sdX device in the array, for example, it would invalidate parity since parity is bypassed unless you use the md# device.

cache is part of user shares. Your appdata share is configured to cache:prefer, so it will prefer to keep the files there, which is the default and best place for it, but it needs to be backed up.
 
/mnt/cache/appdata is that portion of appdata that is on the pool named 'cache'. In your case that is all of appdata currently.
/mnt/user/appdata is all of the appdata share, including any appdata that might be on the array or other pools.
 
If the cache pool ever gets less than Minimum Free, appdata could overflow to the array since it is prefer instead of only. But since you have no Minimum Free set for cache, it will never overflow, so if it fills up, writes to it will fail. Often btrfs seems to corrupt when it gets too full, so this may be the cause of your original problem.
 
/mnt/user/appdata covers more situations, /mnt/cache/appdata might be more efficient but doesn't cover as many situations.
 

Check filesystem on disk10

Unraid IS NOT RAID
 
The 8TB would have to be the parity disk since no data disk can be larger than parity. The other spinners in the parity array, nvme in cache pool.
 
You could go without parity until you get the data transferred. How old is that 8TB? Are you sure it is in good health?
 
Do you have a backup of anything important and irreplaceable?
 
Or...
 
Just keep that 8TB as backup, assign one 4TB as parity and the other 2x4TB as data, nvme in cache pool.
 
You can mount the 8TB using Unassigned Devices plugin to transfer its data to the array.

I would never suggest wiping the entire array since only one disk is corrupt. Each data disk in the array is an independent filesystem that can be read all by itself on any linux. Disk2 corruption has nothing to do with anything on the other disks.
 
Are you backing up only disk2? That seems to be the only affected disk. Of course, if you don't have backups of anything important and irreplaceable, you should take care of that whatever disk they are on.
 
After you get the backups done, certainly worth trying to repair disk2 just to see what happens. Then you can consider what to do with the results.

User shares definitely broken but not clear why. Disable Docker and VM Manager in Settings, then reboot in SAFE mode and see if they come back. Then we can go from there.

Try clearing it from SMB Extras. Might have to stop/start array. Go ahead and let extended self-test complete.

Your seed pool has an empty top level folder named TV in it.
 
User shares are simply the combined top level folders on array and pools.
 
 

These single words aren't enough to make sense of them but nobody has thought of anything better to call them. You can toggle help on/off for most settings by clicking its label. You can also toggle Help for everything with the Help (?) button on the main bar. 
 
Also, the wiki can be accessed by clicking "manual" at lower right of your webUI, or the Documentation link at bottom of the forum. 
 
https://wiki.unraid.net/Manual/Shares#Use_Cache_.28and_Mover_Behavior_with_User_Shares.29

The SMART report was already in the diagnostics. UDMA CRC Errors are recorded in the drive firmware by the drive firmware when inconsistent data is received by the drive based on checksum. These are almost always connection problems.
 
Emulated disk4 was mounted in those Diagnostics.
 
If you think you have fixed connection problems you can try again.
 
https://wiki.unraid.net/Manual/Storage_Management#Rebuilding_a_drive_onto_itself

Unraid reads config/super.dat to get the array disk assignments, and that file isn't plain text.
 
 

Which data disk did you replace? Disk12 has little if any data. Is that expected?
 
Both parity disks and both cache disks have disconnected. Looks like those are all on this controller:
02:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset SATA Controller [1022:43c8] (rev 01) Subsystem: ASRock Incorporation Device [1849:43c8] Kernel driver in use: ahci Kernel modules: ahci  
Both parity disabled, and cache pool is unmountable, but maybe that will come back when the disks do.
 
You should always double check connections when inside the case.
 
Do any of your other disks show SMART warnings  (thumbs down) on the Dashboard page?
 
No point in doing read check unless you just want to exercise and test those other disks.
 
Unrelated, but appdata has files on the array.
 
Shutdown, check connections, power and SATA, both ends, including splitters.
 
Reboot, start the array, and post new diagnostics.

A single eSATA connection will not work well for multiple disks.
 
Probably the best approach if you are going to limit yourself to that hardware is just to upsize your disks. I always recommend fewer large disks instead of many small disks. Each disk requires more hardware to support it. Large disks perform better than small disks. Perhaps most importantly, each additional disk is an additional point of failure.
 
I have always used small form factor builds, and have just replaced my small drives with larger drives to get more capacity. All my drives were 2TB or smaller when I started, now they are all 8TB, and the smaller disks have been reused in other ways such as offsite backups for the truly important data.
 
I also have a backup server, also small form factor, made up of leftover parts from upgrading my main server. It is all 6TB disks that were formerly in my main server. The backup server gets backups of my media (not important) and is only powered up occasionally.

Follow these instructions very carefully.
Tools - New Config - Retain All - Apply. Assign new disk3, leave all other disk assignments as before. Important: In Main - Array Operations, check BOTH parity valid and Maintenance mode, then start the array. This will accept all disks into the array just as they are without writing to them. Stop the array, unassign disk3, start the array in normal mode (not Maintenance) with nothing assigned as disk3. This will disable disk3 so we can check if it is emulated well enough to rebuild, or needs filesystem repair before attempting rebuild. Then post new diagnostics
 

Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 30% 18804 13059870608  
Replace

You will have to reboot and figure out what you are doing to make it happen.
 
The usual cause of filling rootfs is something writing to a path that isn't actual storage. Only subfolders of /mnt are actual storage. All other folders are in the OS space, rootfs. If you fill rootfs, the OS has no room to work in.
 
Check your docker mappings

According to diagnostics, you don't have any assigned disks. You can set a New Config with any disk assigned however you want and rebuild parity. Be sure you don't assign any disk with data on it to any parity slot.
 
https://wiki.unraid.net/Manual/Tools#New_Config

Probably you corrupted docker.img by filling it. 
 
Why do you have 100G docker.img? 20G is often more than enough. Making it larger won't fix filling it, it will only make it take longer to fill.
 
Recreate docker.img. Try making it only 20G. If that is enough to start your dockers in then it is probably enough to run them in if you fix the reason you are filling it.
 
The usual reason for filling docker.img is an application writing to a path that isn't mapped.
 
https://wiki.unraid.net/Manual/Docker_Management#Re-Create_the_Docker_image_file
 
https://wiki.unraid.net/Manual/Docker_Management#Re-Installing_Docker_Applications

Connection problems with parity disk. Shutdown, check connections, power and SATA, both ends, including splitters. Reboot and try again.

Corrupt docker.img, Delete, recreate, reinstall previous apps
 
https://wiki.unraid.net/Manual/Docker_Management#Re-Create_the_Docker_image_file
 
https://wiki.unraid.net/Manual/Docker_Management#Re-Installing_Docker_Applications
 
 
 

pools are not "in the array"
 
Not sure I've seen that before on pool disks, they really can't be "emulated" since they are outside the parity array. Post a screenshot.
 
I guess you could New Config/Trust Parity.
https://wiki.unraid.net/Manual/Tools#New_Config
 
Your appdata and system shares have files on disk5. You will have to set to cache:prefer, disable Docker and VM Manager then run Mover. If they are duplicates you will have to clean up manually.
 
You can see how much of each disk is used by each user share by clicking Compute... for the share on the User Shares page, or the Compute All button

No way for anything to know that, and it doesn't matter.
 
What matters is the flash drive. The license is registered to the GUID of the flash drive.
 
If that is the same flash drive you were using before, no reason you need a trial key. You can probably get most of your configuration working again on that old hardware. Did you already wipe it out? Do you have a flash backup?

If it is you will have to live with it since you can't install drivers.
 
Are you running any VMs?

Why did you wait so long?
 
SMART attributes for disk5 look OK, no self-test runs.
 
Emulated disk5 mounts, you can rebuild the drive to itself. Somewhat safer to rebuild to a spare if you have one since that keeps the original as a backup in case of problems. Check connections, both ends, power and SATA, including splitters. You can run an extended SMART self-test on the disk if you want.
 
Some of your disks are very full. Too many user shares to examine them all, but looks like you have no Minimum Free for many and they are set to Fillup Allocation. Full disks don't perform as well, and filesystem repair needs some free space if that ever becomes necessary. You should set Minimum Free to larger than the largest file you expect to write to the share. I would move some files off disks 1,2 and try to keep 50G or more free on each disk.
 
Why are you still on 6.9.2?