trurl

Looks OK to me. Are you having any problems now?

Post diagnostics. Then disable mover logging so you don't fill log again. I didn't really intend for you to start mover again until we had a look and probably changed some things. Mover can't move open files, which means it won't be able to move anything associated with your dockers and VMs while they are going. And it won't overwrite existing files, so the duplicates will have to be taken care of separately.

reboot

Your disks assignments are different than I understood from your original post. I thought you had put the 4TB in the parity2 slot and parity was a 2TB disk. But looks like the assignments were changed more than once in the syslog. It might save me a little time pouring over your syslog if you would post a screenshot of Main - Array Operation.

You can get all these changes at once but before I tell you how, go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post, so we will have some more concrete information to put into the instructions.

Diagnostics includes SMART for all connected disks, so just post the diagnostics. Do you have SMART warnings for any of your disks on the Dashboard?

The full log is just a trivial side effect of the fact that you have problems with multiple disks. Messages about those are what has filled your log. Likely a result of the disk changes you made. Shutdown, double check all connections, power and SATA, both ends, including any power splitters. When you reboot the log will be gone, that minor problem solved for now. I didn't dig much deeper into your diagnostics so maybe you have other things that are less than ideal but let's deal with these major issues first.

I don't see this as a case of shrinking the array at all, since that is about winding up with fewer data disks and not really about changing anything about parity assignments. I would just remove the 4TB parity2 disk and use it to replace the 2TB parity1 disk. Then you can just use the normal methods to add any disk up to 4TB as a data disk, including that original 2TB parity disk. Technically you could just run with no parity1 and 4TB parity2 and add any disk up to 4TB as a data disk, but my OCD doesn't like having parity2 with no parity1. Do you have plans to have a parity2 in the end?

Even better if you could get us diagnostics when this happens.

Might save a few questions if you just posted diagnostics.

Not enough information to understand your problem, but many of us are using Unraid successfully with Windows. There is a sticky thread pinned near the top of this same subforum about Windows issues. You might take a look there.

Unraid will spin up all disks when it tries to shutdown. Not sure what you mean by insta shut down. Probably you mean to set it up so Unraid shuts down soon after power loss so the battery doesn't run down. That is the way you should do it regardless of how big the battery is.

Do you mean it appears to work normally for that short period, or is it not even working?

Might as well turn off Mover logging since it isn't telling us anything useful. You might delete some old logs, var/log/syslog.1, syslog.2, etc. and get that space back but not sure if it would help since the error has already occurred. I have this in my go file, but it is commented out: mount -o remount,size=384m /var/log

Single cache drive has no redundancy. You need a cache pool with more than one disk. Default raid1 is the usual way, best if 2nd drive is same or nearly same size since the mirror will only have the capacity of the smaller of the drives.

Might be simpler and save time to just reboot, if you can do so cleanly from the webUI.

Fix in 6.8.1.rc1: https://forums.unraid.net/topic/87053-unraid-os-version-681-rc1-available/

yes

It has another port for attaching to the server. You can see it near the power cord in some photos. I have that one but it isn't enough for my server + PC so I use another one on Unraid and just use that one to keep my network up.

You have duplicates as expected. You really need to have your appdata and system share completely on cache and set to stay on cache. That will require several steps. We can get to that. Let it go for a while and see if it gets to the end. Keep checking syslog to see that it is making progress. As long as you don't run out of log space.

Make sure you are booting from a USB2 port.

Install HeidiSQL on your PC and use it to access the database on your server: https://www.heidisql.com/

Preferably a USB2 port.

Mover ignores cache-no and cache-only shares. Do all that again with share set to cache-prefer. Syslog snippets are seldom sufficient. I am merging have merged this thread with the other one. Please don't start multiple threads for the same issue. If you don't think you are getting attention, just "bump" the original thread by making a new post in it so it will show up as unread.

No