itimpi

This is a setting in the Mover Tuning plugin, so set it if you want this behaviour.   However I do not know if it ever has applied to other array operations although you suggest it did.   You should ask in this plugins support thread if you think it has changed.
 

This is not new behaviour - it is just that some bugs in the Parity Check Tuning plugin that could stop this behaviour working properly have been corrected.   It is controlled by a a setting in the Parity Check Tuning plugin so if you do not want this behaviour then you can switch it off in the plugin’s settings.  In most cases it is more efficient to pause the Parity Check while mover is running as the two processes both badly adversely affect each others performance.   It is obviously only relevant if mover DOES start while a parity check is already running which is outside the control of this plugin.

I thought the Parity Check Tuning plugin should also apply this behaviour if set for all array type operations so I need to work out why it has not done so in your case.
 
 
 
 

No.   When you selected the option to format it would have warned you that doing so would update parity to say the disk would then have an empty formatted disk and it was NOT the way to proceed if you wanted to keep the data.
 
As I said your only chance is to use specialist disk recovery software such as UFS Explorer or something similar.

Yes
 
That way if by any chance there a dive fails when building the new parity1 disk you have the old one available for recovery purposes.
 

This is the process that supports the User Share capability so you would expect it to always be running.

All the .cfg and the .ini files in the config folder on the flash drive should be human readable text files.   The disk.cfg file is in the diagnostics and is certainly corrupt as it is not plain text.
 
Do you have a backup of your flash drive?    It is possible that the flash drive is failing and needs replacing.

I’m assuming your parity drive(s) are at least 18TB as no data drive can be larger than the smallest parity drive?
 
when you rebuild to a larger drive the last step is to expand the file system to fill the drive.

Handling of unmountable drives is covered 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.

This is not possible in the current release as you cannot have pools as both primary and secondary storage, and mover therefore will not move files between pools.  It is possible that this restriction may be removed in a future release (perhaps 6.13) but until it happens what you want cannot be done.

This section of 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 discusses this issue.

you should update to 6.12.3 as it contains a docker related fix that might fix this.    Post again if it does not.

If you turn on User Shares then all top level folders of the same name on any array or pool drive are automatically treated as a User Share with the name of the folder and the share covers all drives containing that folder.   Note that this is just another view of your files - nothing is actually changed under the covers.

Each transcoded file effectively IS a new file so the behaviour you describe is exactly what Unraid should do.    Probably the best thing to do is to make sure the Minimum Free Space for the cache is set to a value that will stop it over-filling, and then when the free space falls below that value Unraid will start by-passing the cache for new files/transcodes.  

The rebuild starts by replicating exactly the existing disk contents, and then when it completes that stage the file system is expanded to fill the whole disk.  It is possible that you may have to reboot to get the file system expansion to take place although in theory the reboot should not be necessary.

Have you checked that the Export option is not set to No on the shares as that would stop them being visible on the network.?
 
if the answer to the Export setting is Yes have you tried running Tools->New Permissions on a share showing no files to see if that fixes the issue?

The process for changing the flash drive is covered 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.

This suggests  failing drive as the USB stick is formatted as FAT32 (which Windows should be happy with) when working normally.
 
All settings are saved in the config folder, so if you copy it onto a new flash drive your settings should all be there.   However when creating the new flash drive I would first check it boots OK in case some of the settings in the config folder got corrupted and later cause problems when booting after you overwrite the default settings with your specific ones.
 

Have you actually formatted the data disk from the Unraid GUI using the format option on the Main tab?

Easiest is to have the Unassigned Devices plugin installed (to handle mounting the USB) and Dynamix File Manager plugin (to handle copying files to/from the USB).

That suggest the flash drive is not being found correctly in the later stages of the boot sequence.   It could mean the flash drive is failing, but often simply rewriting its contents can fix such issues.

This will be because Unraid is ‘emulating’ the missing drive using the combination of the other data drives plus parity drive.   When you put in a replacement for the drive what is showing on the emulated drive is what will be rebuilt onto the replacement dtive.

Good chance the error was a CRC error which indicates a connection issue caused a failed transfer initiating a repeat,   Chances are you changing canoes has resolved the issue.  Since CRC errors are recorded on the drive and never rest to 0, if you click on the thumbs down symbol and select Acknowledge from the displayed menu Unraid will only warn you again if the value increases.   Occasional CRC errors are nothing to worry about but if they occur regularly you want to look into it as they slow down transfer speeds. 

I am not an expert on this, but should the exports not have a unique value for the -fsid option for each share?   The ones that you are saying are going wrong are where they have the same fsid value as another entry.

If you rename the folder on disk1 it will automatically become part of the Backup1 share..   This will happen even before you change the Included disks setting as that setting only applies to where New files go, not to reading existing files.

That is quite normal.   Rerun removing the -n option and adding the -L option.   If you then restart the array in normal mode I would expect the drive to mount OK.

You need to remove the -n option or nothing will be fixed.  If xfs_repair asks for it use the -L option.