itimpi

The settings you mention on apply to where Unraid attempts to place new files - it does not affect the placement of existing files. there are a number of choices for manually moving files: use the linux command line if you are familiar with Linux commands use the ‘mc’ command from the Linux command line for an easier to use interface install and use a docker container such a Krusader if you want a graphical interface enable disk shares under Settings->Global Share settings and use your preferred file manager on Windows/MacOS to do it over the network. This can be more convenient but will be slower than doing internally within the Unraid server. one thing to be aware of whatever option you use is to make sure all operations are either disk-to-disk or share-to-share. You should never mix disk and shares in the same command (I.e. disk-to-share or share-to-disk) as this can lead to data loss.

At what level was that error message being generated? If it was at the container level then the file has to exist at the correct location inside the container itself.

If you want a UEFI version of memtest you need to download it off the memtest site and use it to create a bootable USB drive.

Easiest thing might be to download the zip file for the release you want and extract the the bz* type files overwriting the ones on the flash drive. This is a mechanism that always works to switch releases and by-passes any GUI involvement.

You could run the upgrade again so that if you do reboot you get the release you want, but what you will not be able to do (as far as I know) is get rid of the message stating that a reboot is required.

What. Brand of USB stick is giving this error? Some manufacturers save on manufacturing cost of their USB sticks by re-using GUIDs so are not suitable for being licenced for a Unraid use.

I am confused - Unraid will not automatically move files between array disks - this is a manual operation. Have I misunderstood what you actually did? Maybe posting your system’s diagnostics zip file (obtained via Tools -> Diagnostics might help with. working out. What. Is actually happening.

If shares are set to not use the cache then /mnt/user and /mnt/user0 will have exactly the same contents for such shares. it is also worth pointing out that Limetech have already said that use of /mnt/user0 is deprecated and it may be removed in a future Unraid release.

Quite likely to be due to the Marvel controller. They are known for dropping drives for no obvious reason.

The CA Backup plugin can automate backing up the appdata share.

Unraid identifies drives by their serial number (and it checks the size has not changed). This should be unique for each drive and set during manufacture. Many USB docks do not pass this number through to Unraid but generate their own version of a serial. The true serial should be visible in the SMART report for the dtive.

Why is that question related to Unraid?

It would be interesting to know what data you think falls into that category as it is meant to be anonymised.

I see that miniDNLA is listed under the v6 Apps option. Not tried it myself but it does appear it would not be an obstacle to upgrading. You can always make a backup of your v6 Flash drive before attempting the upgrade so you can easily revert if needed.

Unraid requires each array disk to have a unique ‘serial number’ to identify it. It looks like for the first four drives you may have used a 4-bay dock that has generated pseudo serial numbers rather than passing through the drives true serial number. How have you attached the 5th drive? If it another bay of the same type then it may be generating a pseudo serial number that is identical to one of the existing drives and if so this will not work.

There seems to be a missing step 3.5 where after changing the format of the array disk to XFS and restarting the array you carried out the format step to create an empty XFS file system on disk1 before copying the data back to it. I assume this happened? -Rez-clear is never REQUIRED with Unraid, only use it if you intend to stress test a drive. if you want to empty the external disk again ready for the next array drive you can format the external drive again (fastest) or simply delete all files/folders on it.

You may find this section of the online documentation on CRC errors to be of interest.

Yes. Until it gets to the point at which you restarted the array it will simply be over-writing the existing data with the same content (since Unraid will have forgotten you had already started the parity check), and past that point writing the parity information not previously written for the remainder of the drive.

As far as I know Unraid simply goes by what the BIOS reports for IOMMU.

I thought that the section on rebuilding a disk onto itself covered what you wanted? Maybe I have misunderstood?

You may find this section of the online documentation to be of use in resolving this?

I could not spot anything that was obviously wrong in the diagnostics. Whatever is wrong you should not be network limited - even standard gigabit Ethernet should give over 100MBps throughput.

I can only see 2 18TB disks being seen by the system, so something strange is going on as according to you there should be 3. It might be worth power-cycling the server to see if all 3 18TB droves then appear.

I think they have said it is a potential roadmap item, but no sign of it in the current 6.9.0 beta releases. The 6.9.0 release DOES support multiple cache pools.

You probably do not need to power down, but Unraid is not hot-swap aware and it will not let you change any Disk assignments with the array started.