itimpi

Not clear from your description if the /tmp in the nzbget container was mapped to anything at the Unraid level? If it was mapped what was the location on the Unraid side?

If the same file exists in the same place on more than one drive then Unraid will use the one it finds on the first pool (alphabetically) or lowest number array drive. Ideally you want to avoid such duplicates as they waste space and can cause unexpected behaviour (e.g. you delete a file and it does not appear to work as Unraid now finds another copy on another drive).

You may find this section of the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page as it covers exactly this scenario. The Unraid OS->Manual section in particular covers most features of the current Unraid release.

Unraid requires usb sticks that have a unique GUID that is built into the hardware during manufacture and that is what the licence is tied to. This GUID will remain unchanged even if you reformat the drive.

That still seems far more frequently than necessary. I would not check more than once a day, or possibly even less frequently.

I would try to copy (not move) as much of the data off that drive as you can, and it will then need replacing as it appears to be failing if it cannot complete the SMART test.. You seem to have been a bit unlucky with your SSDs because Samsung are one of the top brands and one does not expect their SSDs to fail early. There should be no setting needed in Unraid to prevent this - it is a hardware issue.

As long as you put back the licence .key file that is in the 'config' folder on the flash drive your licence will remain in place as it is tied to the GUID of the flash drive. The hardware is irrelevant - as an example if you move the flash drive to different hardware the licence travels with the flash drive.

If you have a docker.img file that is also btrfs internally by default. I think the libvirt.img file is also btrfs. Where do you have them located? Not sure it is - I think it might be some sort of btrfs id. @JorgeB is likely to know for certain.

You do need to see if the drive in question can complete an extended SMART test without error. If necessary disable spindown on the drive before starting the test and make sure you do not try to access it while the test is running. If it cannot complete the Extended SMART test without error then the drive needs replacing (the test is entirely internal to the drive and not affected by cabling issues).

In principle that should be fine - with Molex you can normally go to 4xSATA. However beware of those splitters where the cable goes vertically into a moulded connector at the SATA end - I have seen them being reported as a potential fire risk as the connectors can accidentally touch if badly manufactured.

It appears to be new to the 6.12.8 release. What change causes it I have no idea but I expect it will be fixed for the next release.

What type of splitters and how many way? Voltage sag to a drive can cause these symptoms.

Those errors cause retries, and you will only get an error reported if all retries fail. That is expected as the continual retries are slowing everything down. Personally I would not bother checking until you can get to the bottom of why you keep getting these retries. You are not by any chance using power splitters on the cabling to the drive?

This is a known issue for systems where the CPU has 128 cores. The current workaround is to increase the size of /var/run. I do not have the URL to hand that gives the command to do this but you should be able to find it from a forum search.

OK. I was just checking as if you do it from the command line depending on the device name used it is possible to start invalidating parity. From the GUI this will not happen.

That tells you which drive is generating those errors.

I believe this is normal if the array is stopped.

Not sure if it can do it directly unless the server was shutting itself off unexpectedly due to the CPU overheating. However it could definitely cause cables to start working themselves loose.

Were you doing this via the GUI or the command line? If the command line what device name were you using?

The diagnostics show you are getting continual resets on whatever device is ata3. This will be badly slowing down performance. The diagnostics do not go back far enough for me to see which device that is, but you should be able to easily find out by clicking on the icon at the beginning of the Identification column on each drive. You should carefully check the cabling (both power and SAT) to the drive as it looks like the sort of error we see if a SATA cable is not properly seated or there are issues getting sufficient power to the drive.

Wait until you run another check - and then look at the Parity History - it will be obvious in the new entry.

You definitely want to get to the bottom of this! It might be indicative of an underlying issue. Are these checks correcting or non-correcting? Have you had any unclean shutdowns? You should post your system's diagnostics zip file in your next post in this thread to get more informed feedback. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs. BTW: You might want to consider installing the Parity Check Tuning plugin. Even if you do not make use of its other features the Parity History entries will start being enhanced to give more information about the check such as whether it was correcting or not.

You can continue to use macvlan as long as you make sure bridging is disabled on eth0.

A lot of people run with a single drive in the cache pool that holds the appdata share and then install the Appdata Backup plugin to make regular scheduled backups to the main array.

Have you set Minimum Free Space for the cache pool or for the User Share in question? You should post your system's diagnostics zip file in your next post in this thread to get more informed feedback. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs.