itimpi

Yes.
 
What the manual is trying to say is at this point you proceed as if the disk had failed.  in such a case shutting down the system to replace a failed drive is likely to be your only option.

It looks like it could be the Minimum Free Space setting for your Games share that could be the issue.
shareFloor="976434990" I think that is less free space than any of your drives have?

I am afraid this is about all you can expect if writing to the Unraid style parity protected array.   To understand why it can be worth reading 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. The Unraid type of array is optimised for things other than speed as it is typically used for WORM (Write Once, Read Multiple) type access such as media files.
 
You can get better performance if you use a pool for the storage, and for that you have a choice of BTRFS or ZFS type pools (and you can have multiple pools if wanted).  With Unraid 7 the Unraid parity protected array is now optional so you can if you want just have a mixture of pools to meet your needs.
 
in your case I would have suggested that you do the initial data load onto the Unraid type array without a parity drive assigned and without caching as then you avoid the overheads of updating parity in realtime, although you would still be limited by the write speed of individual drives as Unraid does not use striping on that type of array. The parity could then be added afterwards.   For normal running you could then add caching to get better perceived write performance as long as the data does not exceed the size of the pool being used for caching.  The mover would then typically transfer the data overnight (relatively slowly) when the system is otherwise idle.   

That would almost certainly be the wrong path to use.  You are normally better off running this from the GUI (from the dialog you get when clicking on the drive on the Main tab) as it the system then automatically gets the device name right.

What you posted would work, but not sure that steps 3 and 4 are actually necessary.
 
Regardless you should keep the old parity drives intact until step 8 completes error free.

That is expected behaviour.   The cutover points are determined by the size of the largest drive, not as a percentage of each drive.   The 8TB drives fills until there is 6TB left (the same as the 12TB ones before going back to disk1.

This (as long as you really have removed all references).

The files will remain where they are.    Unraid never moves files unless the share settings are such that mover gets involved and moves files between the CURRENT primary and Secondary storage

You need to look in the config/shares folder on the flash drive where there should be a .cfg file for each share.   Make sure that the capitalisation matches the actual folders for the share on your drives as a mismatch can cause mover to not function as expected.
 
it looks like this might be your issue.
S-----e shareUseCache="yes" # Share does not exist s-----e shareUseCache="no" # Share exists on cache, disk1, disk2, disk3, disk4  

It looks like there may be an issue with the config file for the appdata share on the flash drive.    I suggest you go into its settings under the Shares tab, make a nominal change (e.g. change the comment) to get the Apply button enabled and press Apply to regenerate that config file.    If you then post new diagnostics then we can check that the settings now look correct.

How are you powering it when adding it to the main array?   Your description sounds as if there might be a power related issue.  Are you sure your PSU is up to the task?  Also it might be worth trying powering it via a molex->SATA adapter in case you have the a drive that has the "3.3v issue".

Looking at the syslog-previous in the diagnostics an explicit reboot was issued just after 05:00.   Looks like that is scheduled to run (probably in User Scripts).

a rebuild never clears the unmountable status.   If that was the status of the emulated drive then it will also be the status of the rebuilt drive.   Normally we recommend doing the check filesystem before the rebuild.
 
So yes you need to do the fix.    After doing that it should mount when the array is restarted in Normal mode.

I also note that you have the Nerdtools plugin which is not compatible with Unraid 7.

The parity will not be valid unless you had zeroed the drives before removing them, so you should NOT check that option and need to build new parity based on the remaining drives.

You can edit the .cfg file for the share which will be on the flash drive in the config/shares folder.    You can use the Dynamix File Manager that is built into Unraid 7 to do this.

If the emulated disks look OK and the drives pass the extended SMART test you can use the procedure 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.

You can use Tools->New Config with the option to keep all current assignments.   When you return to the Main tab you can check the Parity is Valid checkbox to avoid parity being rebuilt and then start the array.
 
This assumes that parity IS valid.   It might be a good idea after this to do a parity check to confirm this.

Have you tried looking directly at the drives on the main server rather than through the User Shares?    Your screenshot suggests to me that you might have accidentally duplicated files on disk1 and disk2?   In such a case Unraid would only show one copy when viewed via a User Share although both copies are taking up space.  
 
if it is not that then you are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread. It is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current syslog.

What btrfs profile are they using?  As long as it is RAID1 then you can remove 1 drive.
 
You can post the diagnostics if you want us to check.

No, what you describe will not work as no data drive can ever be larger than the smallest parity drive.
 
What you want is the Parity Swap procedure that allows you to replace the parity drive with a larger one, and as part of the same process then use the old parity drive to replace failed drive.   Once you have done that you can use the standard disk replacement process to upgrade any of the data drives using the other new drive, or (if you have a free SATA slot) add it as an additional drive.

Cannot see any sign of the LAN port even being seen at the hardware level in the diagnostics.   You might want to check it has not been disabled at the BIOS level

Best option is to do a Check Filesystem on the rebuilt disk as it may recover everything. 
 
Was the emulated disk showing as unmountable before you started the rebuild?    If so then it being unmountable afterwards is expected as a rebuild only clears a disabled status - not an unmountable status.

All you have to do is rename the EFI- folder to remove the trailing - character.    

That implies that the server is NOT shutting down cleanly when you lose power.     Can you normally shutdown tidily (and how long does it take?   In fact it might be worth just seeing how long it takes to stop the array from the Main tab.  
 
Have you checked out the online documentation here on handling unclean shutdowns?