trurl

Disks 1 and 3 are encrypted and look mostly empty. Disk2 is about half full. Your Movies share is on all three drives. I am still unclear what you did and why. Looks like you must have rebooted after whatever you did so can't see any of that in syslog. Did you format a disk in the parity array and then attempt to rebuild its contents? When you format a disk in the parity array, parity is updated and so agrees that the disk is now empty, and rebuilding it will just result in an empty disk.

How much RAM do you have? Do the windows clients need to be able to modify the contents of /tmp?

Without parity, you can't rebuild a replacement. if you remove a disk and put another in its place, the new disk won't have any contents, and the contents of the disk you are removing will not be in your system anymore.

How exactly did you get it to rebuild parity? Did you do New Config? Or did you make it think you had replaced parity? Or do you really mean you just did a parity check rather than a parity build?

Frankly I can't make sense of what you said you did but maybe the diagnostics would clarify.

So are you talking about the path /tmp in the Unraid host, or about the path /tmp within the container?

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

Why does anything need to access transcoding except the application using it?

Disks needing filesystem repair, and disks that are disabled, are independent conditions with independent solutions. A disk that is disabled needs to be rebuilt from parity, a disk needing filesystem repair needs to have the repair tool used. A disk can be corrupt, even so corrupt that its filesystem won't mount. Filesystem repair it the way to deal with that. A disk can be disabled, rebuilding from parity is the way to deal with that. A disk can be both corrupt and disabled. Usually we recommend repairing the emulated disk, then if that is successful, rebuilding. Filesystem repair won't fix a disabled disk, and rebuilding won't fix a corrupt filesystem.

The User Shares are in /mnt/user. If you have a User Share named Music, it is at /mnt/user/Music. There are also the disk paths, /mnt/disk1, /mnt/disk2, ..., /mnt/cache, and possibly others if you have other "pools" in 6.9+. And there are the /mnt/disks and /mnt/remotes created by Unassigned Devices. The User Shares are simply the aggregate of all top level folders on the array and pools. A folder named for the share is created at the top level of the disks as needed according to the settings for the share. Conversely, any folder at the top level is automatically a share named for the folder, whether or not you created it as a User Share in the webUI. Any share you haven't made settings for will have default settings. Since the user shares are just another view of the disks, you must not mix disks and user shares when moving / copying, because Linux doesn't know that the source and the destination might be the same file and it will try to overwrite what it is trying to read.

Usually this is done with the Unassigned Devices plugin

So are you saying that it successfully boots to Unraid when you "select the USB stick in the BIOS", but when you reboot it doesn't boot Unraid? What exactly do you mean by "select the USB stick in the BIOS"? BIOS will let you choose what device to boot from before it tries to boot anything. It will also let you configure it try to boot from a specific device. You have to configure it to boot from flash.

Doesn't look like you have given NFS access to any users.

Still don't know what you are are talking about. When you said NFS, did you mean you had created a share on Unraid accessible with NFS? If so, what does that have to do with formatting a disk? Or did you really mean you were trying to format a disk to the NTFS filesystem? Maybe your questions are more related to that system instead of to Unraid.

The traditional answer on the forum for these types of questions is Soon™

Nobody suggested you do that and I don't see how it would help since the limetech repositories don't have templates for that docker, and docker hub doesn't even have templates. Do this:

Are you booting UEFI or legacy?

You must not have been paying attention to the forums for long. The progress has been fast and furious compared to what it was in pre-V6 days.

For example, OP was likely a different version of Unraid and maybe a different kernel since it was 2 years ago.

It isn't really clear that whatever problem others on this old thread were having was even the same problem, even though everyone starts by saying "same problem". Have you tried booting in SAFE mode?

Can you get diagnostics before the crash?

Does your question have anything to do with Unraid?

So you mean you did this (New Config)? Cause it still sounds like you really meant you rebuilt the data disk, not that you rebuilt parity.

The space in docker.img is mostly just the downloaded executables for each of the containers, so if they are installed it doesn't really matter how many are currently running they are still taking space.

yes