itimpi

If you want to force it to cache then you can change it to /mnt/cache instead of /mnt/user as an alternative to doing it via the share settings. Which way you go is up to you, but using /mnt/cache is slightly more efficient as it avoids overheads introduced via the User Share sub-system. The only caveat is that if you ever remove the cache then the location /mnt/cache will end up in RAM

Don’t worry - it is easy to miss as it is not that prominent or have an icon that makes its purpose immediately obvious.

Unraid tracks drive by serial number so make sure you have a screenshot available of the Main tab that shows the current good drive. have you power cycled the server? Sometimes this is necessary to make a drive that has dropped offline visible again. If the drive is not visible after a power cycle I would say it is almost certainly dead (unless a cable for power/SATA to the drive has come loose). have you made sure that you have Notifications enabled as if so you should have got an email telling you about the problems with the parity drive?

Have you made sure the EFI folder on the flash drive does not have a trailing ~ character so the Unraid flash drive is capable of UEFI boot?

There is a toggle at top right of Main tab for to switch read/write columns between totals and speed.

A suggestion is to delete the config/network.cfg from the flash drive and then reboot to create a new one using default settings.

It normally destroys nothing. If anything does get lost it will only be related to the file that was being written at the time the corruption occurred.

It is easier than that stop array click on drive and change format to the encrypted variant you want start array - disk will now show as unmountable use the option to format unmountable disks.

If you copy the config folder across to the new flash this should bring across all settings. Remove the old licence key that is in that folder on the new flash drive after copying. All disk assignments will be wrong so there are two approaches: remove the super.dat file from the Config folder on the new flash and the system will start with no drives assigned. use Tools >> New Config after booting on the new flash to reset the array.

You need to give the full path (one starting with a /) for the config path inside the container as otherwise docker does not know how to do the mapping. I would also expect you to want read-write access rather then read-only so the container can update config information but that depends on the container requirements. I would also update the description to be the path inside the container rather than the UnRAID level path although strictly speaking that is purely a cosmetic change.

When swapping motherboards as long as you are using standard HBA or onboard SATA ports in principle it should ‘just work’. As you mentioned the caveat is VMs using pass-through as the hardware IDs will change and settings adjusted appropriately. regarding the license question UnRAID counts the devices plugged in at the point of starting the array against the licence limit. Plugging in removable devices later is fine.

It is now done via the Management Access settings

How are the SSDs connected? The error messages suggest that the ones contains the docker.img and libvirt.img files are connected to a controller that does not support the trim operation, but that is just a guess. if you provide your system diagnostics zip file (obtained via Tools >> Diagnostics) attached to your NEXT post then we should be able to provide a more definitive answer.

If you have disk shares enabled (under Settings >> Global Share Settings) then you can see each drive across the network just like any other share. You can then use whatever tool you like on the PC/Mac to move the files (e.g. Windows Explorer/Finder). This tends to be slower than doing it locally on the Unraid server but many people are more comfortable doing it that way. One important rule to follow however you decide to do it is to do the copy/move diskX to diskY, and not diskX to User Share. Mixing disk shares and User shares in the same copy/move command can lead to data loss.

Not quite sure what your problem is at the moment but some observations: You do NOT have a share called ‘downloads’. There is one that may be called ‘Downloads’ but I am not sure because of the anonymisation of the diagnostics. Path/file names are case significant under Linux so check you do not have a case mismatch some where. You seem to be trying to mount and share unassigned disks (in NTFS) using the same share names as on the main array (e.g. TV). This could get things very confused. What the diagnostics do not contain is any of the volume mapping you are using in your docker containers. A screenshot of the Dockers page with the mappings visible might help with understanding how you have the paths inside docker containers mapped to Unraid host paths.

Have you looked at the Mover Tuning plugin? If I understand what you want the plugin should do the job.

You are happy with the CLI then you can use the mc (Midnight Commander) command that is built into Unraid. You san also do it over the network from a PC/Mac.

The part that reads SMART Extended Self-test Log Version: 1 (1 sectors) Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 90% 8515 22306624 # 2 Extended offline Completed: read failure 90% 8515 22306624 # 3 Short offline Completed without error 00% 8515 - # 4 Short offline Completed without error 00% 8460 - shows that the disk is failing the extended SMART test and should probably be replaced.

Correct. You can have any mix of the supported file systems in the array and Unraid will function just fine.

You really need to provide the diagnostics zip file (obtained via Tools >> Diagnostics) if you want to get anything other than guesses. That file includes the syslog but also a lot more about your system setup and current state. The error message sounds as if you have something trying to write to a cache drive (a docker perhaps) without you actually having a cache drive so it is writing to RAM (which gets lost on a reboot).

The FSCK files will get created when corruption is detected on the flash drive. If they keep appearing then the flash drive is probably on the way out and will need replacing.

One option would be to manually create the A folder on another drive, and Unraid would then apply the allocation method in deciding which disk with an A folder to use so in this case would start using the second one as the first one is full. I personally use a similar naming scheme but use a Split Level of 0 so I always need to manually create the letter level to control what disks each letter is allowed to use, but as a result I always know exactly which disks any particular letter can occur on. You can also manually move the B, C folders to another drive. There a wide variety of tools for doing this depending on what your comfort level is. When moving files make sure you move disk to disk and NOT disk to User share as the latter can potentially lead to data loss.

Nothing I can think of. Are you sure it was zero before you started the upgrade? Unraid v6 is rather better at informing you about monitored SMART values changing so you would get a warning about the reallocated sectors being non-zero. You can acknowledge the current warning by clicking on the orange icon against the drive on the dashboard, and you will then only get told again if the value changes. since technically reallocated sectors are a perfectly valid thing to have on a drive there is no reason the parity check should have failed because of them. You certainly do not want them, however, to be continually increasing as that is a sign of impending trouble with a drive. Doing another parity check to make sure the value does not change is not a bad idea, if only for your peace of mind. Make it a non-correcting check as that is always the best variant to use unless you are expecting there to be parity errors that need correcting (e.g. after an unclean shutdown) as it minimises the chances of corrupting a perfectly good parity if an array data drive is acting up.

Stop the array assign the old 4TB in place of disk1 start the array and UnRAID will start rebuilding disk1 by writing the contents of the emulated disk to the physical drive,

No. The system should be emulating it and be able to show its contents just as if it was present using the combination of parity plus the other data drives. If that is not the case then let us know.