itimpi

Just realised I did not read your problem correctly.

The files you mention are perfectly normal as they are the container sub-volumes inside the docker.img file that is mounted at /var/lib/docker

You also mentioned your flash drive filling up - what with? It should not be the files you listed.

Are you sure it is crashing rather than simply not having a driver for your graphics card (which one are you using?). Have you checked in your router settings to see if the server is being assigned an IP address? If so you could try connecting a web browser to that address.

Parity and parity2 use different algorithms to calculate their contents so a simple Rename is not possible.

If you change Parity2 to no device, and assign the drive instead to the Parity slot its contents will need rebuilding. The array would be unprotected until this completes.

The CRC error count value never resets - all you can do is stop it increasing further.

That typically means you have something misconfigured (such as a docker container) that explicitly references the path.

Yes

You are getting continual retries on ata4 that look like cabling and/or power issues.

Jun 5 21:40:17 Dragon kernel: ata4.00: failed command: READ FPDMA QUEUED
Jun 5 21:40:17 Dragon kernel: ata4.00: cmd 60/80:a0:08:aa:aa/00:00:00:00:00/40 tag 20 ncq dma 65536 in
Jun 5 21:40:17 Dragon kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error)
Jun 5 21:40:17 Dragon kernel: ata4.00: status: { DRDY }
Jun 5 21:40:17 Dragon kernel: ata4: hard resetting link

I think this is the parity2 disk?

If you want to check the drive's health you should run the extended SMART test on it.

For mover to move anything you need the pool set as primary storage, the array as secondary storage and mover direction as pool->array.

If you only have primary storage set (as seems to be the case) then mover takes no action and leaves files where they are.

Just move them to where they should be and everything should look after itself. Do not forget that each top level folder on any drive is effectively a User Share with the same name. Parity is maintained throughout though it would not do any harm to run a parity check in case a few parity errors got introduced when the file system issue happened.

Make sure you are either doing a share->share or a disk->disk move. Do not do disk->share as this can lead to data loss.

You are getting continual retires on disk3. You should check the power and sata cabling to that drive.

Yes. With that value set to 0 you will basically never get files by-passing the pool. The pool needs to have a value larger than the biggest file you want to be cached. If you are downloading multiple files in parallel then a value larger than their combined size is needed.

Looks like there are many files missing from the ‘config’ folder on the flash drive so much of your config is missing. In particular the ‘go’ file that starts the GUI is missing. You can restore the default one from a zip download of the Unraid release.

You can skip steps 4 & 5.    However since all your settings and licence are in the 'config' folder on the flash drive you could also simply follow the procedure and at the end copy across the config folder and all its contents from the zip you have overwriting the one on the flash drive.

I thought the runtime=nvidia went into the Extra Parameters field (only visible if Advanced View toggle on)?

At any point in time a file is either on the pool set to be used for caching or on the array (never both).   As long as the docker container is configured to use the User Share path ( /mnt/user/media ) then the current location is transparent to a docker container.

I think that there is no "correct" answer for this as it depends on personal preference.

The main thing in either case is to make sure you have a backup of the 'appdata' share for containers working data, and the flash drive which has the templates for reinstalling applications with settings intact.

Your diagnostics show that 'appdata' still appears to have something on disk1.
appdata shareUseCache="only" # Share exists on cache, disk1 With the 'only' setting any files on the array are left there.   To get them moved you need Primary:cache, Secondary:array mover direction array->cache.  Also because open files cannot be moved you should have the Docker service disabled while moving these appdata files. Only after that has completed can you remove the secondary entry to revert to the 'only' setting.

Do NOT do this unless you are happy to lose the current contents as format is never part of a data recovery process.  Instead you should be using the documented process for handling unexpected Unmountable disks.

Depends on what you want to do 😊

shutdown —help
to see options
shutdown -h now
to do equivalent to ‘powerdown’ command
shutdown -r now
to do equivalent of ‘reboot’ command

That probably means it is failing then.

It looks like the ‘system’ share still has files on the array.
 
Mover will never overwrite existing files so if any are duplicates this needs tidying manually and you need to decide which copy to keep (normally the newest).    If not then mover should transfer them as long as you have the Docker and VM services disabled under settings while this is taking place.

The only way I could see to easily do that would be to plug the drive in via an external USB SATA adapter/dock and then run Preclear on it.

I would wait for someone else to confirm but I think this would lead to data loss.  Changing the setting for the disks to be included will only apply to new files - not existing ones.  You are always told to never mix User Shares and physical drives in the same command in the way you are trying as it can lead to data loss by the system (the Linux level is not aware of User Shares)  and ends up trying to copy a file to itself resulting in files being truncated to zero size.
 
If you are on the latest Unraid (7.1.2) then mover can also be used to empty a disk.
 
Regarding upgrading the server to 14TB parity drive, then yes you can do them at the same time but you would be unprotected until the parity rebuild completes.  If you did them one at a time you would maintain protection.  You cannot, however add the new 14TB drives as data drives until both parity drives are updated.

At some point you are going to have to shrink the array as from what you say you want to end up with less drives than you currently have.
 
you might be better off upgrading both parity drives as the first step.  You could do both at the same time and as long as you keep the old parity drives intact you have a fallback position if a data drive fails while doing this.

No it will not.    
 
If the point for a sector has already been passed in the parity check then it is doing a normal update.   If the point for a sector has not been passed then it will update the data disk and parity disk assuming the data disk is correct, and later if they do not match flag up an error.