trurl

As mentioned, Parity Swap may be the way forward. Maybe even if the disk isn't really bad since that is a way to go just so you can begin to increase capacity. Doesn't really get you any more capacity immediately since it gives you 8TB parity and 4TB parity replaces 4TB disk4, but with 8TB parity you can later replace disks with disks up to 8TB. I see you already found the wiki on Parity Swap, but before recommending you go ahead with that, it might be useful to check other things to see if there is anything that could cause problems while doing that. Diagnostics might tell.

@winglam I merged your threads. Not sure if you posted both times in the FAQ thread or not. Possibly the first was already moved from there. You should only post in the FAQ thread when you are giving the ANSWER to a Frequently Asked Question. If instead you made one of these posts in a different thread than the FAQ thread, then don't post the same question in multiple threads.

What exactly are you trying to do? Whatever it is you probably shouldn't be trying to do it at the command line.

/dev/md1 is disk1 in the parity array. How do you have that "original disk2" mounted? Assigned to slot1 (probably not) in the parity array, or as an Unassigned Device, or what?

So which is it? "disks" or "disk"? /mnt/disks/nvme would be something Unassigned Devices would create. But it is possible that you accidentally specified /mnt/disk/nvme in a path somewhere such as docker mappings.

Still would like to see diagnostics

Not possible with only 4TB parity. Parity Swap may be the way forward if the disk is really bad but that remains to be seen.

What do you mean? Connection problems are much more common than disk problems. Go to Tools-Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

No that isn't at all what happens with a replacement. It rebuilds the data from the parity calculation, no zeroing or anything else. It has to rebuild the whole disk all the way to the end, even if the original was smaller. All of the replacement disk must be in sync with parity. Just replace each disk and let it rebuild.

CA Backup plugin will let you make backups of appdata, libvirt, and flash

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

Have you tried any of the recovery options mentioned?

Assuming all 8TB data disks, default allocation of highwater for user shares would go to first disk until it is half full. There is no reason to redistribute.

Nov 8 01:16:44 STUDIO-X emhttpd: unclean shutdown detected ... Nov 8 01:17:07 STUDIO-X kernel: mdcmd (40): check nocorrect Nov 8 01:17:07 STUDIO-X kernel: md: recovery thread: check P ... As you can see it started parity check immediately after starting due to unclean shutdown but I guess you didn't notice until after you had started using unBALANCE. You really need to let the parity check complete. Since it was an unclean shutdown it is not unlikely that you have a few sync errors. Exactly zero sync errors is the only acceptable result and until you get there you still have work to do. I guess you can wait a while to see if it crashes again before bothering to fix parity though.

Based on the information presented so far don't see any reason to increase. Have you actually been filling it? Making it larger won't fix that, it will only make it take longer to fill.

Seems kinda confused to have a mapping to a subfolder of another mapping.

And if you do want a general purpose linux OS on Unraid, create a VM.

You can download a zipped copy of flash at Main - Boot Device - Flash - Flash Backup

Unraid must format any disk it will use in the array or cache. If you intend to reuse those disks in the array or cache then you will have to put their data elsewhere if you need to keep it. Unraid can access disks with NTFS and several other filesystems outside the array using the Unassigned Devices plugin. Are you thinking of running these under a Windows VM? People usually run these apps as dockers on Unraid. There are many hundreds of dockers available for Unraid.

Not sure why you would have asked about rebooting in that case, since you should not be doing that at all under power. If you are mucking about under power, then that might explain why you think There is really nothing you can do as far as moving or replacing disks while powered up. Even if you have hot-swappable hardware. If you unplug a disk with the array started, for example, it will likely get disabled and have to be rebuilt, even if you don't actually break anything. And there is no point in trying to replace a disk under power either, since Unraid won't do anything with the new disk until you assign it, which can't be done with the array started. It will just disable the disk you removed. So,

It won't actually let you start the array if the disk assignments are changed, unless you first go to Tools - New Config, which tells it you are resetting the assignments.

/mnt/user is where the user shares are located, but to start writing to the drives, you create user shares in the webUI and write to them over the network. It really seems like you don't have much of an idea of how Unraid is intended to be used. In the webUI, there is a link in lower right corner to the manual.

Why are you trying to work with Unraid at the linux command line anyway? You should be using the webUI to manage storage and access to that storage over the network, and to manage dockers and VMs. Accessing that storage (read/write) would normally be done over the network (Unraid IS a NAS, after all), or by dockers and VMs. Don't expect it to act like a general purpose linux OS, it isn't. For example, root is the only user for the command line and webUI. The other "users" configured in the webUI are strictly for network access of storage. Very occasionally it might be useful to work at the command line, but until you know how it is all supposed to work under the hood probably better to get familiar with the "normal" way of using Unraid, through its webUI and as NAS.

When you reboot syslog resets, so nothing in those diagnostics about those errors. When do you have mover scheduled? It looks like cache isn't mounting for some reason. Have you formatted it? Are you planning to add parity?

Writing files permanently is the way things work normally if you are using Unraid normally. Where exactly are you writing? How exactly are you writing? Are you writing to shares over the network or are you perhaps trying to work at the command line and testing things with paths that don't correspond to actual persistent storage? Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.