itimpi

Larger drives being limited to 2.2TB is a standard symptom of older disk controllers. As was said unless there is a firmware upgrade the controller is not suitable for modern large drives.

I have no idea I am afraid. I only have a single drive for cache so use XFS rather than btrfs.

You have to enable that option in the Settings, then when you search there will be an option to also search dockerhub. Note that when you get a docker that way there is no standard template so you have to work out the appropriate settings for mounts, etc from the information (hopefully) posted on dockerhub for the container in question.

That would be normal. If your cache consists of more than one disk then only btrf is available.

The easiest way to go to a specific release is to download the zip file for that release from the Limetech site and then extract all the bz* type files from the zip to the root of the flash drive (overwriting any already there).

The flash drive is NOT a Linux file system - it is FAT32 which is a Windows file system! Windows understands this far better than any Linux system does. Since Windows ran a repair there may well be corrupt files on the USB stick making the boot still fail. I would recommend reformatting the drive to FAT32 in Windows and then run the Limetech tool for creating a USB drive as you would for a new system. When that completes you can copy the ‘config’ folder from the backup you made overwriting the contents put there by the Limetech tool. That will bring across all your settings and your license key. With any luck everything will now boot up fine.

That is because you do not have a parity to check at the moment! It comes back when you have rebuilt valid parity. To do this you stop the array; unassign the parity disk; start the array to ‘forget’ the current parity assignment; stop the array; assign the parity disk; start the array to build new parity based on the current assigned data disks. it certainly makes sense to change the new disk to XFS before you put any data on it. To do this with the array stopped click on the disk and you can change the file system to be XFS. When you start the array you will see the disk is unmountable and there is a checkbox to format unmountable disks. Check it is the correct disk and then go ahead with the format (it only takes a minute or so).

That unfortunately looks like you really have a hardware failure on the drive. If that is the case getting any data off it is unlikely unless you are prepared to pay for professional data recovery services (which are not cheap_.

If you are running the VM from a vdisk then it can share the use of the cache (assuming the vdisk is smaller than the size of the cache).

If that is the case then you want to try from the Unraid command line running reiserfsck /dev/sdX1 where 'X' is the value for the drive in question. If reiserfsck now suggests to use --rebuild-tree rerun reiserfsck with the --rebuild-tree option added to the command go ahead and do that. Note that the reiserfack command can take some time to run so do not close the console window while it is running. If reiserfack completes without a fatal error the drive should then be mountable. If you get some other response from reiserfsck then post what happens for further ideas.

It might be worth putting the USB drive into a PC/Mac and running a check on it in case there is some corruption. Do you have a backup pf its contents? If not I would suggest making one while it is plugged into the PC/Mac.

Quite possibly unfortunately. Mount not being offered means that the plugin is not recognising the disk format. The other possibility is that the disk is not faulty but that there is file system level corruption that is stopping the disk being mounted. In that case running the appropriate file system recovery tool may make the disk usable. What format is the drive meant to be in?

You do not normally want VM files to be on the main array as the limited write speed to the array can badly affect performance of a VM. If not using the cache for such files then an Unassigned Device is typically used instead.

It WILL stop Unraid placing NEW files on the cache that are being written to a User Share. It will NOT stop you manually placing files there or an application (e.g. a docker container) that is bypassing the share system from placing files on the cache. The Mover application only takes action on a share whose Use Cache setting is set to Yes (cache to array or Prefer (array to cache)

Do you have the Unassigned Devices plugin installed? If so does the ‘mount’ option work for the drive?

That seems a sensible usage of those drives.

You need to have the Use Cache setting set to ‘yes’ for any share where you want mover to move files from cache to array. You should read the help for this setting built into the GUI to understand how the options for this setting affects where new files are placed and what action (if any) mover takes.

If parity is showing as disabled then a write to it failed for some reason! Have you confirmed that you can mount the old drive as an Unassigned device? If so then, yes, I would recommend getting the array back into an error free protected state before copying the data back from the UD mounted drive. .

I would not be trying to get the old data disk into the array, but instead try to mount it as an unassigned device. If it mounts that way you will be able to copy data off it back to the array.

If there are a lot of files it might be worth running it one drive at a time and let it complete for that drive before moving onto the next one. Also you probably do not want to run it on the cache drive as it may mess up permissions required by docker containers. If you have the ‘Fix Common Problems’ plugin installed then you will find you also have a ‘Docker Safe New Permissions’ tool that can be run against the cache drive without the risk of messing up docker container permissions.

Should not be a problem! Just for interest why do you want to reformat the flash drive? You could just put the Pro key onto it, reboot, and be up and running with your current configuration you are using with the trial key. However if the new server is going to have different dirk configuration then your approach is easiest.

You should not have to do a New Config. It should just be a case of plugging in the drives and USB stick. This presumes that the disk controller(s) on the new system report the disk serial numbers in the same format as the old one.

It is worth pointing out that you can easily make a backup of the flash drive by clicking on it in the Main tab. It is good practise to do this any time you make a significant configuration changes as it makes recovering from any issues with the USB drive much simpler.

Just to check - can you see the data as expected on the emulated disk as rebuilding will give you exactly what the emulated disk shows. Some people assume it will magically recover files that are not being seen on the emulated disk but this is not the case. BTW: The diagnostics suggest that disk2 has dropped offline as there is no SMART information for it - is this the problematic disk? If so it might be worth posting new diagnostics after a reboot if you want any feedback on the SMART status of that drive.

I think that is deliberate so that the normal Unraid containers do not get buried amongst all the others. having said that I do not see why you have to even enable that option in the settings.