itimpi

You are better off investigating using the Dynamix File Manager that is integrated into Unraid. Using Krusader adds a level of potential confusion as we do not know what mappings you have set up for that container.

If you have no backup then you should be able to get a copy of your licence file reset to you if you contact support. You say you have a paid for 'expired' licence so by that I assume that you are on the new licence model and your free year of upgrades has expired? If so any licence file that support sends you will only be valid for the release that was the stable release at the point the expiry happened - you would have to pay for another year of upgrades if you want to move onto a later Unraid release.

It might be worth disabling bonding and see if that makes a difference? Also Jumbo frames if you have them enabled on your network - they often cause problems.

You are likely to get better informed feedback if you attach your system’s diagnostics (with everything in the one 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.

I think many people have a ‘preferred’ supplier while others could not care. I think any strong preference is often arising from some past experience with a particular supplier. I for instance like Seagate drives and find them amongst best value for money and they have proved reliable for me.. Others have stated they have had problems with Seagate drives and thus avoid them.

I would think that the biggest similar criteria is not to buy multiple identical drives at the same time as then if one is faulty there is an increased likelihood of the others being from the same batch and also faulty,

That would be true unless you have a restrictive Split Level setting that forces files to a particular drive regardless of Allocation Method or Minimum Free Space settings.

Mover does not pre-allocate space - it just checks that the free space is not already below the minimum specified before deciding a drive dan be selected as the target. There must therefore be more Free Space than the size of the file to be moved or the move will fail. That is why the standard recommendation is to set the Minimum Free Space to at least the size of the file to be moved, and preferably a bit higher to give margin for error.

Yes - you end up with a zip file locally on your PC/Mac that can be used to recreate the flash drive if necessary. For a long time this was the standard way to make a backup of the flash drive before the online option via Unraid Connect existed.

Jumbo frames were worth having when NICs were less intelligent and the CPU had to do more of the work handling the network connection. With modern NICs more is handled within the NIC itself thus the performance gain tends to be relatively negligible and not worth the complexities that using Jumbo frames introduce.

That is to be expected if parity is valid so it can be emulated perfectly. It is not clear from your earlier answers that you realise if a disk fails then Unraid can emulate it using the combination of parity plus other data disks (if any) and act as though the disk is still present.

On modern systems Jumbo frames gain virtually nothing from a performance perspective, and can cause all sorts of networking issues. I would recommend avoiding the problem in the first place by not trying to use Jumbo frames.

As long as you do it maintenance mode (so no data writes happen) you could change both parity disks in the same step. Just keep the old parity1 intact until parity is rebuilt in case a data drive fails while building parity as that leaves a recovery option available. Your current step 4 involves rebuilding parity again as you are removing a drive so maybe omit step 4 at this point and leave current disk4 in place until you are ready to replace it?

You should set a Minimum Free Space value on the ‘cache’ pool to avoid it filling up in the first place

The easiest way is to run Unraid in a VM. The online documentation covers how to set this up. A key point is that you need a second licence to be used by the copy of Unraid running in the VM.

You will need to move onto a new version but it should be possible to bring up your old configuration once you have a valid key file and put that into the ‘config’ folder on the flash drive. Note that any plugins will not be compatible as old Unraid versions were 32 bit whereas ever since Unraid v6 it has been 64 bit. The current drives will be in ReiserFS format which is now deprecated although current Unraid versions will still support existing drives in that format. At some point you would want to look at migrating the drives to a newer file system type.

I have never been able to reproduce this. There should be an entry in the syslog at the time the notification occurs giving details about the notification - if I have that information I may be able to track down why it occurs for some people. I am about to push out a plugin update. Basic functionality has not changed although there are significant changes to the GUI Settings screen to make it more user friendly and to conform to Unraid 7.2 guidelines as well as some bug fixes around edge cases. Be interesting to see if the problem soon still occurs for those who have encountered it.

20GB is enough for the vast majority of users unless you have a lot of containers, and 100GB is almost certainly more than is needed. The commonest reason for running out of space is that there is a container writing to a path internal to the container that should really be mapped to an external location on the host.

If you do not mind ending up with parity2 and no parity1 then the easiest would be. assign WD red as parity2, and then start array to build parity2. When that completes successfully stop array Unassign parity1 Start array to commit change At thi s point you can use the old WD Blue as a data drive.

Not quite that simple, but if you encounter a failure at any point then ask here describing how things failed and we can guide you through the recovery steps. The important thing is to keep the old drives intact until the step to replace them has completed successfully.

Forgot that there used to ve a free licence 😊. Did v4 have any licence levels other then Pro one?

Your old licence will still be valid so you may not even need to upgrade as old (legacy) licences do not expire and are valid for all Unraid releases. You do not mention which version you have (Basic, Plus or Pro)? Pro is functionally equivalent to the current Unleashed Lifetime licence. The Basic and Plus legacy licences can be upgraded to Plus/Pro legacy licences.

A point to note is that Unraid recognises disks by their serial number - not by how they are connected so (as long as you are not using a RAID disk controller). You can reply them to different physical connectors without affecting your Unraid configuration. A much faster process to achieve what you describe would be: stop array and replace both iTB parity disks with the 10TB drives you plan to use to replace them. Start array in Maintenance mode to rebuild both parity disks in parallel. Keep the old parity disks intact at this point to give you a recovery scenario if one of the data drives fails before parity is rebuilt. Stop the array and unassign 2 of the the 6TB drives you want to replace. Start the array and confirm that Unraid mounts the ‘missing’ drives by emulating them using the remaining drives + the new parity drives. Check the contents look OK. Stop the array and assign the old 8TB parity drives in their place. Start the array in Maintenance mode to rebuild their contents onto the 8TB drives. No need to clear these drives first as the rebuild overwrites every sector anyway. Keep the old 6TB drives intact for now Stop the array and Unassign the remaining 6TB drive. Start the array to check it is being correctly emulated. Stop the array. Assign another 10TB drive in place of the just removed 6TB drive. Start the array to rebuild the contents of the old 6TB drive onto the 10TB drive You can then follow the standard process for adding the last 10TB drive as a new data drives. BTW: the documentation has not been removed - it has just been reorganised. Array operations are covered here

Not at all clear as to why you should get the symptoms you experienced. When supplying the diagnostics trurl has requested please also mention the name of the share you were using. Perhaps the rsync command you used might also be a good idea. Yes - and thus the confusion.

As far as I can tell looking at the diagnostics you have no shares that are configured to move files from cache to array that actually have files on the ‘cache’ pool. Perhaps you should give the name of a share that you think should have files being moved by mover and for which this is not happening.