itimpi

He disks are not being seen at the SMART level in the diagnostics. is there anything the disk having the problem share? If so that may well be the cause of the issue.

That is only the case if they are badly manufactured - and in my experience this this tends to be more common with SATA->SATA splitters. A point is that the SATA->SATA splitters can rarely handle more than a 1->2 split due to limitations on the current that can flow across the host end SATA connector without getting voltage sag. With Molex->SATA connectors you can normally use 1->4 splitters without current draw issues as the Molex connector uses much larger pins capable of taking more current.

What is the size of partition 1 which UD thinks is not formatted? It may be taking up most of the space on the drive.

There were no obvious indications I could see that the drive in question is dying - just that there was file system corruption on the drive. Drive can have many alternate names - md5 refers to disk5 in the parity protected array once it has been started. You should run a check filesystem on disk5 to correct the file system errors. If you do this from the GUI then you do not have to worry what name to use for the drive as the GUI takes care of this for you. If you simply replace the drive then the replacement will be rebuilt with exactly the same file system errors so you normally want to get this corrected before the rebuild (assuming you even want to go ahead with the replacement once the file system is corrected).

The red cross indicates that writes to the drive failed and the drive was therefore disabled.

You do need to enable Exclusive Access option under Settings->Global Share settings to get this option enabled for user shares which meet the criteria.

Are you basing this assumption on the latest posts to this thread or simply looking at the whole history since it was introduced? I would think it was the least likely to cause issues!

You normally want array->Cache as you get better performance if the files are on the cache.

The first line in your screenshot refers to /mnt/user/appdata/Nextcoud22 while the others seem to be referring to /mnt/user/appdata/Nextcloud22 which is not the same as there is an extra ‘l’ in the name.

It might be worth checking the power to all the drives. Avoid using power splitters if you can, but if you have to then Molex->SATA ones are far more reliable than SATA->SATA ones.

If you must use a splitter then Molex->Sata splitters are far more reliable.

I think the problem is all the disks are now showing: Formatted with type 2 protection I do not know if this can be removed and keep the data on the drives.

Safe Mode stops all plugins from installing/running. Other functionality is not affected.

All transfers to/from /mnt/ locations will be parity safe. The only thing one needs to be careful of is that you never reference a User Share and a disk share in the same copy/move command as that can lead to data loss. If in doubt use the Dynamix File Manager to carry out the operation as it protects you against such scenarios.

This often seems to happen if you have the Mover Tuning plugin installed

Have you made sure that you have the latest version available via the Apps tab? I know at one point it was forked so you may have an older version than the currently maintained one.

It is a while since I last ran UFS Explorer, but if I remember correctly it runs in read-only mode so both options should be safe. If it will run against just the partition that seems enough although it probably makes little difference as the partition is set to fill as much of the disk as possible,

It might be worth running a check filesystem on all your drives to see if file system corruption is behind your issues and correct any that report errors?

Your diagnostics show you are getting continual resets on the drive connected as 'ata2'. I could not see which drive that was but hopefully you can find out from the Unraid GUI. Fixing this will probably solve your speed issue. It is quite likely to be just a cabling issue (power or sata) rather than a problem with the drive itself.

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.

Unraid only has the 'root' user for running administrative tasks so you cannot do what you want. Other users within Unraid are only for controlling access to network shares. It is worth pointing out that the Dynamix File Manager has the ability to edit files although you may need to add entries to /boot/config/editor.cfg to handle file extensions not currently on the list to get them recognized as text files.

As long as the check is non-correcting it should not cause a new problem. However with the hardware currently appearing to be unreliable I would be reluctant to run such a check as there is a good chance it would not finish. Not sure what is causing your crashes. You might get a bit more information if you enable the syslog server (with the mirror to flash option set) and post the syslog that generates the next time you crash so we can see what (if anything) it shows leading up to the crash. Other preventative actions it might be worth taking would be to run memcheck for several passes to check the RAM, and check filesystem on you drives to check for file system level corruption.

Your diagnostics show you have 64GB of memory installed. If it is more than that then it is likely that you motherboard BIOS is mis-reporting the amount.

If you get this then you almost certainly have at least one docker container with the volume mapper wrong/insufficient so that it is writing temporary files internally to the image file rather than to external storage on the Unraid host. The fact that you have an image file anywhere near that size suggests you increased it in the past to try and avoid such a problem - the default of 20GB is enough for the vast majority of people if they have all their docker containers correctly configured to not write internally to the image file. You may find this video from SpaceInvader One of use in identifying the culprit(s)

If you want to move the files to the main array this needs to be set to cache_ssd->array. Your current setting is what you would use later to move the file back to the cache.