itimpi

Many USB enclosures do not transparently pass through the drive so yes.

SSD’s have always supported Trim and have relied on it to keep performance maximised. The issue has been that Unraid never does a Trim of SSDs that are used in the main array. The rational for this was that this could lead to silent corruption of parity unless the SSD supports Deterministic Trim.

This is a setting in the Mover Tuning plugin, so set it if you want this behaviour. However I do not know if it ever has applied to other array operations although you suggest it did. You should ask in this plugins support thread if you think it has changed. This is not new behaviour - it is just that some bugs in the Parity Check Tuning plugin that could stop this behaviour working properly have been corrected. It is controlled by a a setting in the Parity Check Tuning plugin so if you do not want this behaviour then you can switch it off in the plugin’s settings. In most cases it is more efficient to pause the Parity Check while mover is running as the two processes both badly adversely affect each others performance. It is obviously only relevant if mover DOES start while a parity check is already running which is outside the control of this plugin. I thought the Parity Check Tuning plugin should also apply this behaviour if set for all array type operations so I need to work out why it has not done so in your case.

You should try the procedures detailed in 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 which covers handling drives reported as unmountable. The results of that will determine on what advice you get as the best way to proceed.

If you use the Linux mv command you would get the effect described in the link I mentioned as that by-passes the user Share system. If you used a copy/delete strategy then you would be OK. Using Dynamix File Manager would be another way that would work correctly.

No. When you selected the option to format it would have warned you that doing so would update parity to say the disk would then have an empty formatted disk and it was NOT the way to proceed if you wanted to keep the data. As I said your only chance is to use specialist disk recovery software such as UFS Explorer or something similar.

Other than the fact is unlikely to be any time Soon™ I do not think we have any idea. The major thing planned for 6.13 is rumoured to be making the main array a new pool type and allowing for any mix of pool types. The only way I could see a quick 6.13 release is if this functionality was pushed back (e.g to 6.14) and the 6.13 release became instead about improving ZFS support.

How are you placing the files into the Media share? If it is via a docker container then you may be encountering the behaviour described here in 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. you are correct in the the terminology changed in the 12.0 release (although the functionality has not). The new terminology is described in some detail in those release notes.

Multi drive pools have to be in btrfs or ZFS format - you cannot have them in xfs format.

If you formatted a drive then the only chance of recovering data is data recovery software such as UFS Explorer. Formatting a drive that contains data is not the correct way to handle drives that suddenly gets reported as unmountable. The correct way to proceed is covered here in 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.

All the drives in a given pool are the same file system, but different pools can have alternative file systems.

stop array unassign drive start array at that point Unraid will be emulating the drive. See if the ‘emulated’ drive shows as mounted and the contents look correct. Replacing/Rebuilding drives is cover here in 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.

Have you followed the instructions in the Release Motes regarding this?

Looking at the SMART report the last Extended SMART test failed. I would suggest re-running it to see if the same thing happens, and if it does the drive should be replaced. At the moment has the drive been disabled (red 'x') which indicates a write to it has failed? You should consider posting your system's diagnostics zip file to get more informed feedback.

There is definitely something wrong as the mount command you used suggests there is no partition on the drive. I would expect you would have to have used /dev/sdt1 You should post your system's diagnostics zip file so we can get a better idea of what is going on.

You should post your system's diagnostics zip file so we can check what is going on.

I would think the 'data' share should be Use Cache=Yes, while the others look OK. The help built into the GUI explains the options and how they interact with mover.

I would definitely be suspicious of the power supply as starting up a parity check is likely to be a time there is maximum current draw on the power supply. It could also happen at that time if the PSU is OK, but there is anything wrong with the cabling to it such as too many drives on one cable, or too many splitter cables to get the required number of drive connections.

Yes That way if by any chance there a dive fails when building the new parity1 disk you have the old one available for recovery purposes.

Parity2 is not interchangeable with parity1 as they use different algorithms to calculate their content. if you want the 8TB drive to end up as parity1 then you should do that from the outset. Just keep the current parity1 drive intact until you have completed building parity2 on the 8TB drive just in case problems are encountered. BTW: the /dev/sdX identifiers are irrelevant to Unraid - it tracks disks by their serial number, not by where they are connected.

All the .cfg and the .ini files in the config folder on the flash drive should be human readable text files. The disk.cfg file is in the diagnostics and is certainly corrupt as it is not plain text. Do you have a backup of your flash drive? It is possible that the flash drive is failing and needs replacing.

I seem to remember reading somewhere that it took a reboot to get the extra space made available but no more than that. Not tested it myself recently to be sure.

From a number of other posts in the forum that seem to have done what looks like sensible testing. I have seen no properly structured formal testing though but I hope that will happen some time soon. If you use your server primarily for storing media then you may not get much gain from ZFS compression as most media formats are already compressed.

This is inherent in the way Samba operates. The SMB protocol is case insensitive whereas Linux is not. If two files/folders exist with the same spelling but different case then Samba will pick up one of them snd ignore the other. I do not know how you can tell which one it will pick up. The only thing I think Unraid can do is somehow warn you about this. I ‘think’ it will stop you creating shares like this via the GUI, but not when you do it under the covers.

This is the process that supports the User Share capability so you would expect it to always be running.