trurl

Can you be more specific? What is the behavior or other evidence that it isn't working?

I've never had a lockup from RDP BOINC, but it will take a lot of your CPU if you let it. Here is what I have set: Use at most 50 % of the CPUs Use at most 50 % of CPU time Suspend when non-BOINC CPU usage is above 25 % I am sure that is conservative. I have a pretty simple setup though, only 4 cores. No VMs, 10 or so dockers, nothing pinned.

Be sure to use the Previous Apps feature on the Apps page so it will reinstall your dockers just as they were without having to set them up again.

Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post. I will split this into its own thread if it seems unrelated to Krusader.

Not random. As suggested, possibly you have allowed your server to be hacked. Is your server directly on the internet? Or have you forwarded any ports to it?

Which parity was it? They are not interchangeable.

That disk has disconnected. Check connections and post new diagnostics.

Your docker image is a little smaller than I usually recommend. Unlike many who make it very large because they have some container misconfigured and they keep filling it. Do you ever get close to filling docker image?

That was definitely not the default. I think that was 3 zeros too many. The Minimum Free for cache is similar but different from Minimum for each user share. Each user share has a Minimum Free. If an array disk has less than Minimum when Unraid decides which disk to write a file to, it will choose a different array disk. You should set Minimum Free for each user share to larger than the largest file you expect to write to that user share. Once Unraid has chosen a disk to write the file it will try to write the whole file to that disk even if it runs out of space. For Cache Minimum Free, if a user share is cache-yes or cache-prefer, then if cache has less than minimum when Unraid decides which disk to write a file to, it will choose an array disk instead of cache. This is sometimes called "overflowing to the array". Note that a cache-only user share will not overflow (and a cache-no user share will not write to cache anyway). Similarly, you should set Minimum Free for cache (in Global Share Settings) to larger than the largest file you expect to write to cache.

https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui

Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post. I may split this into its own thread since it likely has nothing to do with this plugin.

You can rebuild to the same disk. But formatting before doing that would still be pointless. I suspect you don't know what "format" does. Format just writes an empty filesystem to a disk. Whether or not you format a disk will have no effect on the rebuild, since it will be completely overwritten by the rebuild, and it won't matter whether or not it has an empty filesystem on it before it is rebuilt. This was all hypothetical in your original post, which is why I thought you were just getting a parity check. Now you say you did pulled it out and formatted it. You don't even say what filesystem you formatted it in, which makes me think you don't understand format as I said. In any case, unless you had actually started the array without the drive assigned, and then reassigned the drive, then it wasn't rebuilding to that same disk. It probably was just an unclean shutdown parity check. It should have told you in the Array Operation section whether it was rebuilding/syncing or just doing a parity check. If it was disabled, there would have been a red X beside the drive instead of the green or white ball that normally appears there. The best thing you can do in the future if you have a problem is to ask for help before doing anything. The right thing to do will depend on the specifics of the situation. If you have filesystem corruption and you rebuild, it will most likely result in that same filesystem corruption. If you have a disabled disk but the filesystem is OK, then rebuilding will result in a good filesystem. If you have filesystem corruption and the disk is disabled, we will usually suggest repairing the filesystem of the emulated disk before attempting the rebuild. And if you can rebuild to another disk and keep the original as it was, you get another chance to try to get files from that original if there is a problem with the rebuild. Syslog resets on reboot, so there isn't any way to tell what happened or what you did. You can setup Syslog Server so the syslog is saved somewhere you can get it after reboot. Possibly the drive itself didn't fail. You said it had passed some tests. You have a lot of disks and you haven't said which disk it was. Do any of the disks give SMART warnings on the Dashboard? Give me the last 4 characters of the serial number of the disk and I will take a look at its SMART report in your diagnostics. Unraid keeps track of which disk is assigned to which slot by the disk serial number. It won't matter where they are plugged in. The only thing that sometimes causes an issue with this is if a controller doesn't pass the actual disk serial number to Unraid. You don't seem to have this problem.

Probably disturbed other connections. You are having problems communicating with multiple disks. Check all connections, power and SATA, both ends, including power splitters.

I have split your post into its own thread.

Totally pointless. If the idea is to rebuild the disk then formatting it outside Unraid accomplishes nothing at all. Many people have only a vague understanding of the word "format". It doesn't apply here. If a disk is disabled then it is emulated. Sounds like instead you have (or had) filesystem corruption. Parity typically can't help with filesystem corruption. This is unclear and probably missing important details. If you didn't shutdown from the webUI then what you got from restarting it was a parity check for unclean shutdown. Simply restarting without doing anything else will not result in a parity-sync/data-rebuild. You can see the data on a disabled/emulated disk even before you begin rebuilding it as well as while it is being rebuilt. As mentioned it doesn't sound as if you had a disabled/emulated disk. As mentioned, doesn't sound as if emulation was ever involved. If you had filesystem corruption then possibly it can be repaired if you haven't done anything else. If it was showing no filesystem then that almost certainly indicates filesystem corruption. I suggest not making any hardware changes until you get your other problems fixed (as well as they can be). Do you have backups of anything important and irreplaceable? You should.

Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post. Don't do anything without further advice.

That folder named test isn't right, but I assume you created it from the root account. The others look OK as I said. Your diagnostics thinks the shares have files on various disks. What do you get with this? ls -lah /boot

Do you have any details about what exactly they did? That looks normal to me. Have you tried stopping and starting the array?

Post a screenshot of Settings - Global Share Settings - Cache Settings

USB3 ports seem to give unreliable connections for some systems. There is no advantage to the greater speed for this use, so best to stick with the greater reliability of USB2 ports. Unraid doesn't need fast access to flash. The OS is loaded from the archives on flash at boot time into RAM, and it runs completely in RAM. Think of it as firmware except easier to work with. Other than that access at boot time, it also stores settings you make in the webUI, but speed is not needed for anything, neither is capacity beyond about 2GB.

Yes, that is it exactly. Currently you don't allow disk 8 for any user shares. Best to not select any disks so it will allow all.

Just be aware that if you change the filesystem on any disk, it will be formatted, so don't do that without moving the data off first. Since you didn't answer this: I think the most likely explanation is this:

Was this a new disk in a new slot? Why would you format anything new as ReiserFS? I wouldn't even consider using that flash drive as cache. Not only will it be unreliable, but it is too small to bother with. Where exactly are you looking that makes you think the shares don't have enough space? The screenshot you gave doesn't have anything to do with your shares, and the total storage displayed there is the correct sum of all data disks in the array. Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post.

Post your docker run command as explained here: https://forums.unraid.net/topic/57181-temporary-docker-faq/#comment-564345

Sounds like your USB is disconnecting. Try another port, preferably USB2.