itimpi

The USB Creator tool can be picky sometimes.   Try using the Manual Install method instead.

Unraid 7 supports one pool acting as a cache for another pool.

blacklisting an IP is not really a solution as it does not stop an attack from a different one.
 
Unraid is not hardened against internet attacks.   If you want to allow access from the internet then a better solution would be to only allow access via a VPN (such as the WireGuard one built into Unraid or an alternative such as Tailscale. ) so that there is no direct access from the internet to vulnerable ports.  Then you do not need to have many ports forwarded in the first place.

It looks as if the 'appdata' share is using up that space - is it too big to fit onto the 'cache' pool? 
 
You should also set a Minimum Free Space for the pool to avoid it filling up too far (at the moment you have this set to 0).   This should be set to be larger than the biggest file you expect to be cached.

Since this is a shucked drive it could be affected by the SATA 3.3v issue (google for details) and fixes.   This might explain why it is seen when connected some ways and not others.  If so then powering it via a molex connector (if possible) might help as that does not supply 3.3v.

The SSDs should be put into a pool and then you can configure a share to only use that pool.

With stock Unraid I would expect it to start again from the beginning.    The Parity Check Tuning plugin provides an option to restart from point last reached, but only if there was a clean shutdown which I would not expect if the system suddenly lost power.

I can see in the syslog in the diagnostics that the clear starts, but then almost immediately you fet
Aug 5 12:44:51 optimus kernel: sd 1:0:16:0: Power-on or device reset occurred Aug 5 12:44:51 optimus kernel: mpt2sas_cm0: log_info(0x31120303): originator(PL), code(0x12), sub_code(0x0303) ### [PREVIOUS LINE REPEATED 8 TIMES] ### Aug 5 12:44:52 optimus kernel: sd 1:0:16:0: Power-on or device reset occurred Aug 5 12:44:52 optimus kernel: mpt2sas_cm0: log_info(0x31120303): originator(PL), code(0x12), sub_code(0x0303) ### [PREVIOUS LINE REPEATED 7 TIMES] ### Aug 5 12:44:53 optimus kernel: sd 1:0:16:0: Power-on or device reset occurred Aug 5 12:44:54 optimus kernel: mpt2sas_cm0: log_info(0x31120303): originator(PL), code(0x12), sub_code(0x0303) ### [PREVIOUS LINE REPEATED 7 TIMES] ### Aug 5 12:44:54 optimus kernel: sd 1:0:16:0: [sdr] tag#674 UNKNOWN(0x2003) Result: hostbyte=0x0b driverbyte=DRIVER_OK cmd_age=6s Aug 5 12:44:54 optimus kernel: sd 1:0:16:0: [sdr] tag#674 CDB: opcode=0x8a 8a 00 00 00 00 00 00 00 08 40 00 00 04 00 00 00 Aug 5 12:44:54 optimus kernel: I/O error, dev sdr, sector 2112 op 0x1:(WRITE) flags 0x4000 phys_seg 128 prio class 2 Aug 5 12:44:54 optimus kernel: md: disk16 write error, sector=2048 Aug 5 12:44:54 optimus kernel: md: disk16 write error, sector=2056 Aug 5 12:44:54 optimus kernel: md: disk16 write error, sector=2064 Aug 5 12:44:54 optimus kernel: md: disk16 write error, sector=2072 Aug 5 12:44:54 optimus kernel: md: disk16 write error, sector=2080 Aug 5 12:44:54 optimus kernel: md: disk16 write error, sector=2088 Aug 5 12:44:54 optimus kernel: md: disk16 write error, sector=2096 and then ongoing errors of a similar sort.  Quite why this is happening I am not sure.   Have you carefully checked the cabling (in particular power) to the new drive?
 
 

This message almost certainly means you have something (typically a docker container) that is configured to explicitly mention /mnt/cache_nvme.

Your share settings look a bit strange as you should not be allowed to have the same settings for the Primary and Secondary storage!
 
you need to set the pool as primary storage; the array as secondary storage; and the mover direction as array->pool to get the equivalent of the Prefer’ method you mentioned.
 
This should all be covered 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.

Not directly.
 
You should be able to achieve the effect that I think you want by setting the Split Level setting for the Multimedia share to Manual and then creating the folders at the next level only on the drives you want to be used for that folder (and its contents).   
 
Note:   There is a bug in the 6.12.10 release that stops it correctly honouring the Manual Split Level.    You need to either be on an earlier Unraid release or the 7.0.0 beta for this to work correctly.
 

Those screenshots show an issue reading from the flash drive.
 
Sometimes downloading the zip file for the Unraid release you are using and then extracting all the bz* type files and overwriting the 9nes in the root of the flash drive can help.

It is really up to you.   When doing a replacement a pre-clear just allows a stress test of the drive before using it in anger.  It does not otherwise affect the replacement process as that overwrites every sector on the replacement drive anyway.   
 
This is different to adding the drive as a new drive to a new slot as then the pre-clear can run asynchronously to adding it thus speeding up the add process so there is more to gain (although still strictly speaking not necessary).
 
 
I agree this seems unnecessary in a case where you are replacing a drive that you believe is still good.    Just keep the drive that is being replaced intact until the rebuild onto the new larger drive has completed successful.

Unraid identifies drives by their serial number and not by where they are connected.   You would need to look at the serial numbers of the various drives and then assign them to appropriate disk slots in the Unraid GUI.   If you have already done some assignments you can use Tools->New Config to put the system back into the state where drives can be assigned.

Note that I said the Minimum Free Space for the pool - not the shares.   The one for the shares is aimed at stopping you filling up array drives too far.  You need to click on the pool on the Main tab to get to that setting for the pool.

You may find this section useful from 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. 

That will be because this setting is on the shares - not the disks.

Your syslog appears to be ful of
Jul 16 20:46:03 Tower kernel: XFS (nvme0n1p1): Metadata corruption detected at xfs_dinode_verify+0xa0/0x732 [xfs], inode 0x6017cf8d dinode Jul 16 20:46:03 Tower kernel: XFS (nvme0n1p1): Unmount and run xfs_repair Jul 16 20:46:03 Tower kernel: XFS (nvme0n1p1): First 128 bytes of corrupted metadata buffer: Jul 16 20:46:03 Tower kernel: 00000000: 49 4e 41 ed 03 01 00 00 00 00 00 63 00 00 00 64 INA........c...d Jul 16 20:46:03 Tower kernel: 00000010: 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jul 16 20:46:03 Tower kernel: 00000020: 61 71 64 89 0d 84 32 3f 61 71 64 89 0d 84 32 3f aqd...2?aqd...2? Jul 16 20:46:03 Tower kernel: 00000030: 63 dd c3 85 1e f8 8b 7c 00 00 00 00 00 00 00 54 c......|.......T Jul 16 20:46:03 Tower kernel: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jul 16 20:46:03 Tower kernel: 00000050: 00 00 00 02 00 00 00 00 00 00 00 00 77 39 4a 6b ............w9Jk Jul 16 20:46:03 Tower kernel: 00000060: ff ff ff ff 78 8b 49 98 00 00 00 00 00 00 00 04 ....x.I......... Jul 16 20:46:03 Tower kernel: 00000070: 00 00 06 34 00 0b a9 ed 00 00 00 00 00 00 00 00 ...4............ which I believe is your cache pool.     You would need to run a check filesystem on this to repair the file system. 

Unraid does not (currently) have a standard way of doing that.    You can control access on a particular share, but at the SMB level you have to make the sharer visible on the network or not regardless of the user.   The closest would be to have the shares as "Hidden" but then the users would need to know the share name they need to access.

Isn't this just a summary of the steps in the online documentation for handling Unclean Shutdown?

d--a shareUseCache="yes" # Share exists on disk1, disk2
You have the ‘data’ share set to move its files to the array, so why are you surprised they disappear from the cache?  
 
Do you have something configured to look directly on the cache rather than via /mnt/user/data which would find files regardless where they are located

The versions on the cache would take precedence over those on the array.   It is quite possible the array versions would have your docker and BM settings.
 
my suggestion would be:
stop docker and VM services under Settings. Rename the docker.img file and libvirt.img file to something else (so you can revert later if needed) move the copies on the array to the ‘system’ folder on the cache drive and then delete the ‘system’ folder from there. set secondary storage for the ‘system’ share to none so they stay on the cache drive. re-enable the docker and VM services and see if you have things back as they were.   If they are you can delete the renamed copies from earlier.  
 
 

Did you follow the procedure to do this as documented here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI.
 
You could have done that on the emulated disk before rebuilding, or on the physical drive after rebuilding.  Since it appears you removed the physical drive (which is a shame as you are going to need to rebuild it again) sounds as if you are going to need to do it on the emulated one.

You cannot stop the system during the Parity Swap procedure - it must run to completion without interruption.   You will need to restart from the beginning.

This.
 
The parity operation is always the size of the largest parity drive (if they are different sizes).   They the parity drives not need to be the same size as long as the smallest parity drive is at least as large as the largest data drive.