itimpi

You only get a lost+found folder if the repair process found files/folders for which it could not find a directory entry to give them the correct name. 

You need NetBios enabled under Settings->SMB  for SMB1 to be available.   It is disabled by default as it is a security risk.

If Safe boot works and normal mode does not then it is almost certainly one of your plugins that is causing the problem. 
 
Which one I am not sure but I notice you have a version of Mover Tuning installed that is is incompatible with Unraid 7.0.0 so at least that needs fixing although I do not think it would cause your issue.
 
To investigate you can disable any plugin by renaming its .plg file to have a different file extension and rebooting.  Reverse the rename and reboot to get it enabled again.

Do you not have the option to format Unmountable drives near the bottom of the main screen.   If so make sure that it lists only the drive(s) you want to format before proceeding.

Once you have pool set up (name can be anything) then if you want to use it for caching a share go to that share on the Shares tab and set the pool as Primary Storage, the array as Secondary storage and mover direction as Pool->Array.

This is all that is needed.   
 
Note that the parity2 has to stay in that position as moving it to parity 1 would require parity to be rebuilt.

How are you determining this?
If called from the CLI the default should be to anonymize (there is a -a parameter if you do NOT want it anonymized).
 
Note that if you have mover logging enabled then its output is NOT anonymized - but then you should not normally leave that active unless investigating a mover issue.
 

If you are still getting nowhere then it may well be worth using rufus to format the drive as that has been known to resolve it for some people.

Which share do you think is the problem?   I can see only one potential candidate and that looks like there IS a capitalisation issue with the .cfg file.
 
v---t shareUseCache="yes" # Share does not exist V---t shareUseCache="no" # Share exists on cache, disk7, disk8, disk9  

Check in the config/shares folder on the flash drive that the .cfg files for your shares have the same capitalisation as the folder corresponding to the share on the array drives/pools.    If there are two files with the same spelling but different capitalisation remove the one that is not correctly capitalized.   You can also take the opportunity to remove any that correspond to shares you no longer have.   After doing that check your share settings are still as you want them.

Not sure I understand?   What are these arguments to?   If to the docker run I would have thought you pass them via the Extra Parameters or the Post Arguments fields

The procedure is documented here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. The Unraid OS->Manual section in particular covers most features of the current Unraid release.

It is surprising how many times we have seen this initiated by a pet (cat or dog).   I think they may find the top of  the server a nice warm place to rest  

If that is the case then you can use the Parity Swap procedure to make the new drive a parity drive and then use the old parity drive to replace an array drive.

Should not be necessary.
Yes.    Note that you can also make the flash drive visible over the network (as the 'flash' share) by clicking on it on the Main tab and setting the SMB settings appropriately For security reasons it is not shared over the network by default.

It is normal for parity checks (and other array level operations) to slow down over time as the heads move towards the inner tracks (which hold less sectors per track).

The parity drive is not being seen at all by the system.     You need to carefully check power and SATA cabling just in case one of them has worked loose.  
 
Failing that you need to work out if that drive really has died.  Perhaps plugging it into another machine if possible to see if it recognises it.
 

If the pool is also being used for caching purposes, then you should make sure that you set a sensible Minimum Free Space value.  Typically something like twice the size of the largest file you intend to cache (or more).  This will mean that the 'cache' functionality starts by-passing the pool when free space falls to this value so avoiding such issues.

It looks like this is the problem share?
d--a shareUseCache="no" # Share exists on temp-cache, disk1, disk2, disk4, disk5 m---a shareUseCache="no" # Share exists on media-cache, disk1, disk2, disk3, disk4, disk5, disk6, disk7, disk8 However it looks like you have other share swith the same spelling but set differently?
D--a shareUseCache="yes" # Share does not exist M---a shareUseCache="yes" # Share does not exist The Linux level underlying Unraid is case sensitive whereas Samba is not so only one of these two will be used.
 
I suggest that you look in the config/shares folder on the flash drive to see if I am correct and then if so delete the ones that are not correct.  After that check the share settings again to make sure they are correctly set to move files from cache to array.

With only primary storage set mover will take no action on the share (note that setting for primary mentions it only applies to NEW files/folders).   To get files/folders already on cache moved you need cache set as primary, array as secondary, and mover direction as cache->array.    When everything is moved to the array you can then (optionally) having just the array as primary storage.
 
They only get created when you enable the service (docker or VMs) that need them.   You currently have these disabled.

1.  Your assumptions are correct when applied to the main Unraid array, although you have some order over how drives get filled up depending on the settings for shares.  Since each drive is a self-contained file system (which means you can have a mixture of file system types in the array) reading/writing is constrained at max to the speed of a single drive.  Regarding redundancy since each drive is self-contained one of the strengths of Unraid is that if you have more failures than parity drives is that the data on the remaining drives is still available.  However this does mean that writing directly to the parity protected array is slower than many people expect although tends not to be an issue if storing large numbers of media files (a typical use) which are only written once.
 
It is also worth pointing out that with Unraid 7 the main array is optional and you can have your drives in pools outside the main array that use standard RAID techniques (with their standard advantages and disadvantages) from both a performance and resilience view.
 
2.  Any type of drive can be used as cache and its purpose is to improve performance.   It is intended to improve the 'perceived write' speed by caching the initial write and later moving files to the main array, although whether this caching happens is configured at the individual share level.  It can also be used for application purposes (docker containers, VMs) to avoid the performance penalty of slow writes to the main array.
 
3.  The 'cache' is completely optional.   Do not get confused that you can have by the fact that you can have a pool named 'cache' and the caching cap[ability that is configured at the individual share level.   The name is just a legacy from before support for docker and VMs when caching was the only thing it could be used for and the pool name is up to the user.
 
4.  You can do what you want even without using Tailscale, although it is now probably the easiest to set up.

The default used to be 0, but that quite frequently lead to issues, so in one of the recent Unraid releases the behaviour was changed so that now defaults to value that (I think) is based on size of largest disk in the share.

I would suggest that you contact support as they are the ones to deal with licence related issues.    You tend to get reasonably prompt responses from them.

Looking at the diagnostics I can see you have not set the array to autostart under Settings->Disk Settings.   
 
You must have done that at some point on the other server and forgotten about doing it  

I notice that you have the NerdTools plugin installed which is not compatible with Unraid 7 although it does look as if you are not installing anything via this so probably not the cause of any issue.   I also notice the RealTek 8168 plugin installed - you may be better off removing this; and then rebooting to use the one built into Unraid as the built-in one appeared to initialise OK.
 
you also appear to be using Jumbo Frames on the 10G link (but not the 1G link)   Nowadays this is not recommended as it provides little performance benefit and can cause networking issues when running a mixture on the same LAN.