itimpi

Yes, as long as the flash is formatted FAT32. In practise you can also create a new flash drive and simply copy across the 'config' folder from the backup as the 'config' folder contains all your settings and licence. If this flash drive is new then make sure the flash is labelled UNRAID and then run the make_bootable.bat file from the flash in Administrator mode. Yes - it is part of the 'config' folder. If it is a new flash drive then Unraid will take you through the Licence transfer process on next boot.

Did you try copying the files or moving them? I am asking because you can get strange results using move where the file remains on the same drive but in the new directory (this is a by-product of the way Linux implements move and the fact that Linux does not understand User Shares). You have to do a copy followed by a delete of the original to avoid this effect.

Yes

Not sure what you mean? Are you saying that a xfs_repair is not working?

It might be sufficient to simply have the backup run overnight directly to the array avoiding the need to occupy the space for the backup share on a SSD pool?

Have you isolated the GPU so that containers cannot use it? Sounds like you may have containers and the VM trying to use the GPU at the same time which is a no-go scenario if you are using GPU pass-through to a VM.

That is expected. All top level folders on any drive are automatically considered as User Shares, and in this case will have default settings.

Why bother to upgrade your flash - it will not make UnRaid run any faster as after initial load UnRaid runs from RAM. Practical experience has also shown that USB3 drives are far more prone to failure than USB2 ones.

Because USB2 seems to be far more reliable, and Unraid gains no significant performance advantage as after initial load UnRaid runs from RAM.

Your mistake was to format the drive despite the warning that this would wipe the contents and upgrade parity accordingly, and that format is not part of a data recovery process. Without that your data should have been there. As you found it is always a good idea to keep the original drive intact until the rebuild has completed successfully. it is possible software like UFS Explorer on Windows might be able to recover data off the drive since a format does not actually clear the file sectors - merely rewrites the file system control structures.

I could not see any shares with the Use Cache=Yes setting. This is what you should use for shares where you initially want them written to the array and later moved to the array when mover runs. The Prefer setting is for shares where you would like the files to be on the cache, but if they do not fit write them to the array, and if later space becomes available mover moves them back to the cache. Otherwise I did not spot anything that looks to obviously be wrong, and even the points mentioned are only observations as I am not certain what behaviour you want.

The current guide on multi-language support describes how to pick up translations from .php files that are started from a web page and I am doing this successfully. However it does not seem to cover the case where the .php script is started from a cron job (or the CLI). Is there any guidance on what do in such cases. I am currently working on trying to do some reverse engineering on how the translations are loaded for web pages, but thought I should ask in case there is already something I can look at for the cron/CLI cases.

If you want us to look at your share settings you should post your system’s diagnostics zip file (obtained via Tools->Diagnostics) attached to your next post. By default mover only runs overnight which is probably why you had to run it manually. The Mover Tuning plugin gives finer grained control. However if things stopped working when your cache dtive filled up that suggests you do not have sensible values for the Minimum Free Space setting to make it automatically start by-passing the cache if it is gull.

Force it using the power button. Since the flash drive has dropped offline UnRaid will not be able to update it to say you successfully stopped the array so it is likely to start an automatic parity check on next array start.

It is also worth pointing out that is perfectly acceptable to plugin drives AFTER the array is started even though they would exceed the licence limit.

Yes,, you can manually move files between pools. unraid will never automatically move files between pools. the ‘mover’ app will also not move files to/from the array if they already exist on the target.

You should post your system’s diagnostics zip file (obtained via Tools -> Diagnostics) attached to your next post to get better informed feedback.

Perhaps it could be made slightly clearer by adding ‘CPU’ after the % value?

I would expect problems with that restrictive a Split Level setting. In Krusader what access mode has been allowed for the Access to the Unraid shares? I believe that you want it to be R/W slave (although I do not see how that being wrong can cause your symptoms).

Cannot download the diagnostics file Commonest mistake is not understanding the Use Cache setting for a share. Turning on the GUI help gives a good summary of what the settings do or read the online documentation that can be accessed via the Manual link at the bottom of the Unraid GUI. You want it to be 'Yes" to get files moved to the array.

I think that is expected behaviour when you use mv on a User Share. The Linux implementation of mv first tries a rename and only if that fails does a copy/delete. In this case that works so the file remains on the drive (Linux does not understand User Shares). You need to do an explicit copy/delete to get the file onto another dtive.

UnRaid never moves files between array drives - if the file will not fit after a drive is selected you get an out-of-space error. what is important is that the Minimum Free Space value is larger than your biggest file so that any single file is guaranteed to fit. When the free space drops below this value then the NEXT file will go to another drive.

What this means is that the Split Level setting can cause the Minimum Free Space setting to be ignored if they would cause different drives to be selected. In other words the Split Level setting can force UnRaid to use a particular drive despite the fact there is not enough room, and so subsequently the transfer fails. If you are using the fill-up allocation level you almost certainly want the Split Level setting to say directories can always be split.

No easier way than rebuilding parity for the disks you want to keep. The problem is that even though you ‘think’ there is nothing on the disk as far as UnRaid is concerned this not true as there are still the file system level entries that define an empty file system and these have been included when calculating parity. The moment you remove a disk which does not have all sectors set to zeroes you are invalidating parity.

You are likely to get better informed feedback if you attach your systems diagnostics zip file (obtained via Tools->Diagnostics) to your NEXT post.