trurl

Also, your appdata, domains, system shares have files on the array instead of all on cache. Just wanted to get this noted as a reminder for after we get your more important problem fixed.

Disk 1 has SMART issues. You should be able to see these on the Dashboard. Do you have Notifications setup to alert you immediately by email or other agent when a problem is detected? Do you have another copy of anything important and irreplaceable? Do you have a replacement disk? Rebuilding to a new disk won't fix the unmountable. Maybe best approach would be to unassign it, repair the emulated disk, then rebuild to a new disk.

The inner "cylinders" have less data in them (shorter in circumference) but the rotation rate is the same. It starts with the outer (longer, more data) and works towards the inner (shorter, less data). So the data rate will be less as it works through the whole disk.

You can drill down into each individual array disk in the same way you did for cache.

Is it a duplicate of files already on the array? If so, you need to decide which to keep and delete the other.

You don't want to rebuild parity with a bad data disk in the array. Do not replace parity first. Yes, this is definitely what you should do. Do it all in the same process.

If you reinstalled/restarted your dockers on a formatted cache then they would have created new appdata folders.

Tell us more about your networking configuration.

Yes you can add disks and it won't do anything to the existing data on other disks. The disks can even be different sizes, but each data disk can be no larger than the parity disk. You can also get more capacity by replacing a disk with a larger disk and Unraid will rebuild the data of the replaced disk onto that larger disk.

We usually recommend not having automatic corrections to parity for the scheduled parity checks or the parity checks you get from an unclean shutdown. Whether or not you correct parity when running it manually depends. Ultimately, you must correct parity, or in some cases when it seems appropriate, rebuild the specific data disk you suspect has caused parity to be out of sync. Or it may be that you have some other issues such as bad connections that when fixed will show you didn't actually have parity errors after all. Exactly zero parity errors is the only acceptable result, and you must work on it until you get that result. After running a correcting parity check, we usually recommend following that with a non-correcting parity check to make sure you actually have exactly zero parity errors remaining, or you still have some sort of problems you need to work on. You have set system share to cache-only. Mover ignores cache-only shares. Set it back to cache-prefer and run Mover. It wasn't able to move it to cache before because you had Docker and VM services enabled, and mover can't move open files. You apparently missed a lot of my posts. You should go to Settings - Docker, disable (already disabled currently) then delete docker image. Later, after you get your problems resolved and are ready to resume using dockers, change it to the recommended 20G and enable again. It will be recreated, and you can add your dockers back exactly as they were using the Previous Apps feature on the Apps page. If your docker image is growing, you have something misconfigured. The working data for your dockers should be in the appdata. Docker image is just for the executables. Your syslog looks better, let it run a while. But Fix Common Problems has a number of lines that indicate your server can't reach the internet. Any idea what that is about?

And no point even trying it with the array started, because you have to stop the array to assign the replacement disk anyway. On the other hand, I sort of "hot swap" Unassigned Devices all the time from a separate eSATA enclosure, but I power it down to do the swap.

apcupsd is included in Unraid, but its code is not maintained by Limetech, so if your UPS doesn't work with it try the NUT plugin as suggested earlier, or get a different UPS.

Main - Cache Devices, click on the folder icon at far right under View

These are the virtual disks for docker and libvirt images. Some of your system share is on disk1 though, so that could be where your 20GB docker image is. Some of your shares are cache-yes, so maybe those got moved to the array. You can see how much of each disk each user share is using by going to Shares - User Shares and clicking Compute All. Didn't see anything obviously wrong in that docker template. Can't vouch for the docker itself though. I see the author says it is beta, and CA shows that in its listing. Are you sure you didn't reformat cache? That seems the most likely explanation.

https://xkcd.com/936/

Post latest diagnostics

Is it just Nextcloud or do you have other containers that also have this problem?

You should use "Docker Safe New Perms" or run New Permissions on individual shares so you don't screw with the permissions the containers setup for themselves in appdata. Unlikely to cause a crash though.

If you want help you should start your own thread and post your diagnostics.

A number of things I see in your share and other settings. First of all, if you or anything else is currently writing anything at all to your server, stop it until you get things moved off of cache. Why do you have 60G allocated to docker image (currently disabled)? Unlikely you would need more than 20G unless you have something misconfigured. And I suspect you do have something misconfigured there because you have a duplicate .cfg file in the shares folder of your diagnostics. Possibly there are some things that have lead to your current situation, and that may be just one of those things. Your "appdata", which you have named "docker" instead of the usual "appdata", is all on the array and configured to not use cache. Just as well right now since cache is full, but you really want that all on cache eventually. You have some of your user shares set to cache-no, but they have data on cache. Probably you set them to cache-no because you filled cache, but cache-no won't get moved to the array so those are stuck on cache. In Main - Cache Devices, click on the folder icon at far right under View and post a screenshot.

FTFY

Still getting these Mar 6 00:29:01 MediaMonsterv3 crond[2678]: failed parsing crontab for user root: /usr/local/emhttp/plugins/ca.turbo/scripts/turboSchedule.php enable 180 > /dev/null 2>&1

He did put them in a new post but they were overlooked because of the way the forum formatted his screenshot. Probably best if there is some blank space included before attaching, but I'm not going to explain that every time I ask for Diagnostics.

Fix your server time.

On mobile now so can't look at Diagnostics. Can your server reach the internet?