trurl

The user shares are simply the top level folders on all disks. If the same top level folder is on multiple disks they are part of the same user share. If any files have exactly the same path and name on multiple disks only one of those will be seen in the user share but will still exist on the disks.

Don't know if this is relevant or not, scroll down into the post for ACPI messages part:

Tools - Diagnostics, attach complete ZIP file to your NEXT post in this thread.

Not obvious to me from that one line to suspect flash drive, did you have more context than that?

Can you elaborate?

Post new diagnostics

Looks like you rebooted after that since that message is earlier than the syslog in your diagnostics. Also looks like your data drives are probably newly formatted. Is that unexpected? And I see you were playing with building your own unraid just before you started this thread: Your initial post here in this thread is very lacking in details. Can you provide more?

The name you give the container is the name the template is stored under on your flash. If you reused that name then your previous configuration was overwritten.

Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

Works for me. root@unSERVER:~# which netstat /bin/netstat root@unSERVER:~#

Off-topic discussion split here:

Latest beta supports multiple pools so each of these could be a pool managed by Unraid instead of Unassigned Devices plugin. I have my dockers on a separate pool from my general use cache pool.

Just starting the array with the disk unassigned will disable it. Just be aware that emulating the disk requires reading all of the other disks. Parity alone doesn't have any data.

Syslog suggests a connection issue with that disk. Check connections, SATA and power, both ends, including any splitters.

I assume by that you mean you rebuilt the drive to itself.

2TB disk2 has pending sectors, so it might make sense to replace it. But Are you having any trouble using your server with that disk? If not I don't see any reason to remove it until ready to replace. If Unraid decides to disable it, then it will be "kicked out" and you will still be able to access the data for that disk by reading ALL remaining disks to calculate its data.

Do you mean you rebuilt the drive to itself? Or do you mean something else?

Changing split level won't have any effect on existing files, and even the use cache setting won't help since mover can't move open files. Let's proceed with getting things like I mentioned and then we can take a look at whether or not you still have a problem. Go to Settings - Docker, disable dockers then from that same page delete the docker image. Leave dockers disabled until we are finished getting appdata and system moved to cache. Go to User Shares Click on the appdata share to get to its settings. Change it to Use cache: Prefer. Click on the system share to get to its settings. Change it to Use cache: Prefer. Go to Main - Array Operation and click the Move button. Wait for Mover to finish then post new diagnostics.

Let me know if you want further advice on how to configure docker like I have suggested. It will take several steps to get those moved to cache since you (and mover) can't move open files.

I think your split level is causing your problem, but you really shouldn't be trying to do it this way anyway. You really want to keep appdata and system shares on cache. They are cache-prefer by default but you have changed them to cache-yes, with the result that they have files on the array. With these on the array, your docker performance will be impacted by the slower parity writes, and your dockers will keep array disks spinning since there will be open files on the array. And it looks like you have plenty of cache to work with, so no good reason to put these on the array. You can backup appdata with the CA Backup plugin. Also, your docker image is currently 64G (though it is set as 16G in docker.cfg). 20G is the usual recommendation and should be more than enough unless you have something misconfigured. And, generally, I don't recommend Most-Free allocation method. This can also perform badly since it might force Unraid to spin up disks as it tries to keep them at the same amount free. The default allocation method of High-Water is default for good reason. It is a compromise between using all disks (eventually) while not constantly switching disks just because one disk temporarily has more free space than another.

It is more important that it successfully shuts down when power goes out than that it successfully runs for any period of time before initiating shutdown. The main goal is a clean shutdown, not continuing to run on battery.

Assuming you are referencing appdata as a user share and not as a folder on a specific disk, and you move that folder from one disk to another, then the container shouldn't know the difference. For more detailed advice, post your diagnostics and the docker run command for that container.

And to add to this point, if another disk failed and you still had this disk in the array, you might not be able to recover either. In order to reliably rebuild every bit of a missing disk, all bits of parity PLUS all bits of all remaining disks must be reliably read.

Since you don't have parity nothing to resync when you remove a disk. Of course you don't have any parity protection, but each data disk in Unraid is independent. Each disk can be read independently without the others.