itimpi

Just a check - did the parity check actually start? It is always possible that the Parity Tuning plugin incorrectly detected an unclean shutdown and the notification is misleading. The plugin does not start the check itself - it just assumed unRaid is going to do so after an unclean shutdown and puts up the notification to indicate why.

I must admit that I can not think of any reason that should be the case. Not sure why you would want imagebackups on the cache in the first place I was thinking that a share anonymised as M....a might be a Media share that was having these problems?

There was no mover logging in the last diagnostics posted - not sure if the plugin interferes with that and without that it is hard to guess what might be going wrong. The last diagnostics show mover logging NOT enabled so you might want to check that as well. Might have to wait to see if anyone else has any idea

The diagnostic's show that the Mover Tuning plugin IS installed and other posts suggest it seems to be causing a lot of people problems I would suggest uninstalling the plugin, recreating the issue; and posting new diagnostics.

This is not a problem - in fact it is one of the purposes of the 'prefer' setting. Note that open files cannot be moved so you may need to temporarily disable the docker and/or VM services if they are holding open files you want to be moved. You are likely to get better informed feedback if you attach your systems diagnostics zip file (obtained via Tools->Diagnostics) to your NEXT post. You could also try enabling mover logging to see if that giver a clue.

You have to decide if it is worth the expense to protect against losing that data while it is on the cache.. If the Project data is in a share which has Use Cache=Yes set then it will end up protected when mover later transfers the data onto the array but you are correct in that without redundancy in the cache/pool there is a window of exposure.

There does not appear to be any attempt to move files in the diagnostics. I notice that you have the Mover Tuning plugin installed. Have you tried removing that to see if that helps. There have been some reports of this helping some users.

your data should all be intact if you can get the latest unRaid release running. You mention the system is old - is it 64-bit capable (as this is requirement for v6 of unRaid). The last version that ran on 32-bit systems was v5.0.6. as to getting hold of such an old version as 4.4.2 I have no idea where you might get hold of it.

Common ways are: from the command line using Midnight Commander (‘mc’ command) or some other tool such as rsync. This is probably the fastest. from a docker container such as Krusader. Gives good graphical interface. over the network from your favorite Client OS.

you can create the share either via the GUI (which will then create the folder to hold share data) or manually by copying explicitly to a disk using the folder name which you want the share to have. when you later rest the array to use the 14TB drive as parity any data on the remaining array data drives will be left intact.

Not quite sure what you mean here? I agree that you need an additional USB stick containing a valid licence for that USB stick but once you have that running unRaid in a VM is comparatively trivial to set up.

As was mentioned if you simply create a top level folder on one of the array drives you intend to keep in the array that will automatically be treated as a User Share with the same name as the folder.

Why bother to even assign the 14TB drive to the unRaid array? You could simply use it as an Unassigned Device (mounted using the UD plugin) as it is only a temporary home for files.

Since the total space on your current QNAP NAS is 36TB and you say there is only 23TB of data on them you might be able to minimise the amount of copying involved by looking at the free space on each drive and working out if you can get the drives into unRaid in an order that means only some of the data needs to go via the 14TB drive.

Yes in principle You probably want to carefully read the help built into the GUI for the Use Cache setting on shares - it is frequently misunderstood. There is also a good write-up here in the online documentation that can be accessed via the Manual link at the bottom of the unRaid GUI. Note how the various settings control where files are initially placed and (potentially) later interact with the 'mover' application for moving to another location.. In your case I think you want all the 'work' folders to be on cache/pool for performance and the final storage on the array.

Where have you set the unrar to be written to and what are you using to do the unrzar? If the destination is not explicitly on the cache or to a share set to Use Cache=Yes then this would be expected. You are likely to get better informed feedback if you attach your systems diagnostics zip file (obtained via Tools->Diagnostics) to your NEXT post.

strange that you get a problem on reboot then as it the shutdown/reboot first issues an array stop and then only if the timeouts for dockers and/or VMs are reached does it start trying to force them down. You might want to check the timeouts for dockers and VMs under the settings for the respective services (may need to be in advanced view to see these timeouts) and try increasing them slightly to see if that helps.

The problem is that the logic for selecting a drive to use is at a much lower level in unRaid than that at which mover runs so the file size is not known at the level that selects the target drive. I agree it would be nice if the size WAS taken into account before even attempting to move a file but I suspect that the changes required to achieve this may be non-trivial. Still worth asking for in case someone at Limetech has a brainwave on an easy way to implement this.

The reboot after an upgrade is meant to be a ‘clean’ shutdown of the array. There has been some indication that the values for timeouts in Settings for closing Docker containers and VMs may not be getting honoured (or lost) after the upgrade (which would be a bug) and resetting them can help. Before rebooting it might be worth seeing if you can first successfully Stop the array - and if not try and find out why before rebooting as if you cannot successfully Stop the array you will always get an unclean shutdown/reboot.

Not quite as the licence is tied to the GUID of a particular drive. the easy way to do what you want is to get a new “Pro” licence linked to a new USB drive. You then copy the ‘config’ folder off the current USB drive to transfer all your current settings to the new USB drive. You can then use the existing drive with the Plus licence for the secondary server. You can set up the old drive as if it were a new flash if you want, but if doing so make sure you first copy the licence file off the existing drive so you can then put it back after recreating the drive to keep it licence.

are you saying that the ‘?’ Icon at the top right of the GUI is not working to switch the help on/off? If this is the case then the state of the help display is stored in a cookie so clearing the browser cookies could fix this.

If you simply issue the Stop option then if the array stops successfully it was clean. If it does not stop you can then investigate what is stopping it from stopping.

You should see if you can successfully stop the array even when not issuing a shutdown. If that does not stop cleanly then that might be a bit easier to investigate why as the system is still running.

Looks like it is working correctly My guess you are not clear on how high water works There is a good explanation here in the online documentation that can be accessed via the Manual link at the bottom of the unraid GUI. Since your largest data disk is 12TB the first point for selecting another disk is 6TB. At that point disks are used in turn until there is 6TB free. The next cutover is 3TB so disks are used in turn until each only has 3TB free. etc

You should use EITHER Include OR Exclude - not both. Files that belong in a share should still be found for read purposes even on disks that are not on the include list. By definition all shares are in a folder as the top level of a share is a folder corresponding to the Share name.