itimpi

Have you tried disabling the docker and VM services and seeing if you still have the problem? You might want to also boot in Safe mode to disable any plugins running. That would allow you to at least identify if it is a problem with the base Unraid system, and if they then do not spin up it would give you a starting point for gradually enabling these options to see which one causes the spin ups.

Are you running any docker containers - they can keep drives spun up. Also I notice the the appdata share used by Docker containers has files on disk1 - not all on the cache.

In which case you are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread so we can see more about your setup.

Read access to files in a User Share will find the files on all drives if they exist with the right path regardless of the User Share settings. If a file exists on more than one drive then the first found is shown (the search order is pools in alphabetical order followed by array drives in ascending disk# order). It is write access for new files that are controlled by the various settings for a User Share that can control placement.

That should not have filled your RAM - it would have resulted in the transcode file(s) being written internally to the container rather than the mapped /tmp location that IS in RAM.

It is very strange as the error message when you try to add it says it is already in the array Cannot think what might be causing this, but I expect it will be something easily fixed if we could only track it down.

Do you have Settings->SMB->Hide "dot" files set to Yes?

can you give the output of fdisk -l again so we can check that the partition has been deleted

The thing I could see causing that is a plugin that installs something into a folder along that path and has been built slightly incorrectly so is over-riding the Unraid default ones You could check this by booting in Safe Mode (which suppresses loading plugins) to see if it occurs then. If so it is going to be a case of identifying the culprit.

That change will only affect new files for the share. Existing files will be left where they are and still show up when trying to read from the share.

Still no sign of the problem drive. That suggests it really has failed and needs replacing. if your parity is valid then at this point Unraid should show that it is ‘emulating’ the missing drive (using the combination of the other drives plus the parity drive) and acting as if the disk were still present. At the moment the array is in an unprotected state but if/when you get a replacement drive then Unraid will be able to rebuild the contents of the ‘emulated’ drive onto it and get the array back into a protected state. Do you have notifications enabled so that Unraid can let you know immediately any problem is spotted?

You should post new diagnostics to see if it now shows up in the SMART reports. If Not then it is likely the drive has failed.

It appears to be offline in those diagnostics as there is no SMART report for it. You should probably try power-cycling the server to see if then comes back online.

In which case exactly what command did you use? the symptoms are not unusual if you get the command slightly wrong.

You should never get errors on a memory test if you want the system to be stable.

I believe it the /dev/sdd Toshiba drive. Looks like it is a 3TB drive but has an existing 2TB DOS partition allocated. I would guess that deleting that partition would solve the issue.

Have you installed the base Unassigned Disks plugin? This is needed before you can install the Preclear add on.

A split level of 2 is highly likely to cause problems - you want it set to split as needed if you are using the Fill-Up allocation method. Was the 50GB Minimum Free Space setting always there or was that added when you started encountering problems? Are any of the files you are trying to copy larger than 50GB - if so you need to increase the value for this setting. You might want to check the "Full" disk to see if there are any incomplete files there from a previously failed attempt to copy files - if so they should be deleted as they would stop the allocation method being used as existing files are always over-written in-situ. It might be a good idea at this point to manually move files to another drive to free up space on the full drive and see if things then start behaving better. Since you are on a 6.10.x release the Dynamix File Manager plugin is the best way to do this.

In which case it will be your Split Level setting as that over-rides Allocation method if they contend for which drive to use.

Anything other than 0 errors is a problem

in which case I would try a different USB port in case it is that acting up

What do you have set for Minimum Free Space for the share? That tells Unraid when to consider another disk. It should be larger than the biggest file you expect to send to the share - normally twice as big is the recommended value.

That error indicates a problem reading a file from the USB stick (typically one of the bz* type files). Making a backup and then rewriting the stick with contents from the backup frequently fixes this issue.

You do not want to attempt a preclear with a parity check running as they will BADLY affect each others performance.

I saw in the syslog the message Aug 19 22:33:48 Unraid emhttpd: Error: disk8: already assigned Since the disk is not a new one maybe there is something that is confusing Unraid? Not sure what is causing this but have you deleted any existing partitions, or running a preclear on it?