itimpi

Yes

In my experience that is only true if you have them on a RAM location (which is where /tmp is located). If you have them on physical media they do not seem to get cleared out.

You will first have to upgrade the parity drive to 8TB and have parity built on it before you can add the other 8TB drive as a data drive.

Unfortunately not. You have to have at least 1 disk in the array. You do NOT have to use parity with the array unless you want to.

If you have a web terminal (or ssh/console) session open where the current directory is on a mounted device this will stop it being unmounted.

Unfortunately I do not see any language other than English being likely in the near future. The GUI is not engineered with multi-language support in mind so that the text can be stored in language specific files independently of the core GUI. That means that an alternative language is an all-or-nothing option and requires someone who understands both English and the target language to do the work required for the initial version and to keep it up-to-date for new releases. i would really like to see a move towards proper multi-language support so that over time users can provide the text later for their own native languages. However I would expect that would be a multi-year project (if it ever even happens at all).

I would not recommend going with 3) as this is not an officially supported configuration; depending on the model of SSD might not play well with parity; and performance (writing) will be limited by the speed of the parity drive. regarding the other options how important is to you to have data on the SSDs protected? This might help decide between the other options.

These two statements imply hat you do not understand how the Use Cache settings work and whether data ends up protected or not. As was recommended I suggest you read up on how this setting operates and whether this results in data being protected.

When you are asked for diagnostics it means please post the system diagnostics zip file (obtained via Tools -> Diagnostics) attached to your NEXT post.

I do not see any reason why you should not take such an approach for this particular case. It might be preferable to having to develop your own customised solution.

As was said you should go for level 2. If you think of the Split Level as the depth that can occur on multiple disks you realise that you only want the share and year to be on multiple disks. Once a day folder is created you want that folder and it’s contents to be constrained to the drive where the day folder is first created.

No - a file is only ever stored in one place. Redundancy against hardware failure (in particular disk failures) is a separate topic and functions independently of individual files.

I thought you could just assign a new disk in its place with the array stopped and start the array to built parity on the new drive? if that is not the case then you can definitely do: stop the array unassign the parity disk start the array to commit the change stop the array assign the new parity drive Start the array to build parity

According to those diagnostics the SMART report for the parity disk shows that it is about to fail so should be replaced ASAP. The SMART reports for the other disks look OK.

I run a copy of UnRAID in a VM (for development purposes) and I had to use a different model of USB drive for the VM’s copy of Unraid. If I did not it would not show up on the list of USB devices I could assign to the VM.

The plugin update was to stop the plugin overwriting the sensors-detect file with a version that is older than the version now shipping as standard with UnRAID.

As long as you are not using RAID controllers on the machines it should just be plug-and-go as UnRAID is largely hardware agnostic.

The diagnostics show that the parity disk is currently offline so SMART information is not available so we can check it’s health. You may have to power cycle the server to get the drive back online. It is probably worth doing so and then posting new diagnostics.

Linux assigns the sdX designations dynamically as it sees drives so you can never rely on them staying the same. UnRAID cannot handle an array drive momentarily disconnecting and then re-connecting (as USB drives are prone to do) and getting assigned a different sdX type designation.

You are getting lots of resets on the drive and then eventually a write failure. More often than not these are a connection issue and not a problem with the disk itself so check the cabling to the drive. you should provide the diagnostics zip file (obtained via Tools>Diagnostics) attached to you NEXT post so we can get a better idea of what is going on.

Limetech have at least committed to making the source for the part of Unraid that is currently closed source freely available if they ever stop supporting Unraid.

The 6.8 release tightened the permissions on the flash drive to improve security and the user cannot change them. As you raid this means that no files on the flash can have execute permission. The options are now: precede the script name with the command used to run the script (e.g. bash) copy the script to somewhere where you can change the permissions and then do so (e.g. /usr/local/bin). This will, however, not survive a reboot unless you take the steps required to repeat this on every boot. Run the script via the User Scripts plugin. This script could be the actions from the previous option with a script set to run on first array start.

Your report will get noticed here FYI: As long as you have installed it via Community Applications you can easily get to the support thread for any particular plugin by going to the Plugins tab and then clicking on the Support option listed for each plugin. Alternatively find WireGuard on the Apps tab and click the support icon shown for it there to get to the same point.

It is not normal for that file to survive a reboot as the ‘root location is in RAM. Are you sure you have not added an entry to the ‘go’ file or User Scripts Plugin to copy that file to that location.

… and the 6.9 rc1 release (which should be soon) will switch back to a 5.x series kernel.