JonathanM

It is an issue, usage doesn't matter, any RAM allocated is denied to the host completely. Try setting the windows to 8GB and the linux to 4GB and see how they perform.

You can do it simultaneously but it will be excruciatingly slow. Why not just remove the disks all at once and rebuild parity one time with the final complement of disks?

Maybe when you finalize your directions to yourself, use Slot instead of Disk when referring to the logical positions, and fill out the last 4 of the drive serial numbers so you keep it straight in your head and can cross check things. For example, select slot 1 and assign disk A54E or something like that. Also, I suggest actually committing a document to print after verifying all your steps, then physically cross things off the list as you do them.

Why? If you are retiring the disk, why not just leave slot 9 blank, and NOT check "parity is already valid" so it calculates parity from the disks you wish to use? The only other gotcha I see is if files are added or modified while the copy process is running you may not have the full up to date copy. You can either stop all the things that could write to the disk, or use rsync to verify the copy and list differences until the verify is perfect. It's not a bad idea to verify the copy anyway, but not the end of the world since you are keeping the old disk(s) intact as you go.

Download the latest and overwrite everything EXCEPT the config folder.

Attach diagnostics to your next post. syslog is included in diagnostics.

Yes, you can't use parity to rebuild to a smaller disk. You will have to set a new config in tools, then recalculate parity after switching the disks.

So you have the license *.key file that was issued for the broken stick? All you need to do is copy that file into the config folder of the new stick and delete the trial.key, then the registration wizard will step you through blacklisting the old key and getting a new one to match the current stick.

Familiarity, greater control, etc. Mostly just personal preference and fear of learning new stuff.

Why? There are good reasons to let all the new writes go to the new disk. Usually newly added data is going to be accessed most frequently, and disks are much faster on the first bit compared to when they are almost full. User shares have no issues combining all the data seamlessly.

Short answer, no, there is currently no way to add limited access GUI users. Since docker start stop and restarts are easy on the command line, you can do scripting that looks at a user accessible share location for input. Updates are probably possible, but I have no experience doing updates from the CLI. The script would watch for and act on the existence of a specifically formatted file to show up or change in a user share location. The user would connect to the SMB share that has permissions for that user to create or modify files, and manipulate the file(s) the script is watching for. As a quick example, you could look for the existence of a file named restart.txt, when found the script would restart the container and delete the restart.txt file.

Set up a new VM, get it running to your satisfaction, then add the corrupt vdisk as a second disk to that new VM.

Blue link "manual" in the bottom right of the Unraid GUI

diagnostics will contain that info

https://forums.unraid.net/topic/38582-plug-in-community-applications/?do=findComment&comment=1397593

You need to run another check after this one completes to make sure there are zero parity errors.

Are you sure you selected the box to "Write corrections to parity"?

You forgot steps 7 and 8. That is the legacy site anyway, here is the new document. https://docs.unraid.net/unraid-os/manual/storage-management/#removing-data-disks

Deleting files doesn't clear the drive. The entire drive must have zeroes written to it, so when it is removed the parity is still valid. Preclear DOES write all zeroes, but you can't preclear a drive while it's in the array. There is a script that does clear the drive while it's in the array so you can remove it without recalculating parity, but the script doesn't work well for many people, it's very slow. I think you need to stop the array, unassign the parity drive, start the array so it forgets it, stop the array, assign the parity drive so it will recalculate from scratch. A clear drive in Unraid terms is all zeroes. A drive with all the files deleted, or formatted, even if it shows an empty filesystem still has a whole mess of ones and zeroes on it, some from the deleted files, some from the filesystem itself.

Apparently the drive to be removed was not fully cleared. Generally writing all zeroes to a drive takes many many hours, even days sometimes. How long did that step take for you?

Maybe you accidentally checked "Parity is valid" after you did the new config?

In theory this will work, but just because a disk is disabled it doesn't mean it's bad. I can't look at the diagnostics right now, but depending on the health of all the disks it may not be the best option. A disabled disk means a write to it failed, which could be cabling or other issues besides outright disk failure.

Yes, for the disk share writing to /mnt/diskX/Sharename would be viewed in /mnt/user/Sharename If you wish to write to /mnt/user/Media/Movies you would need to use /mnt/diskX/Media/Movies, not /mnt/diskX/movies Linux is case sensitive, so make sure you stay aware what paths you use.

The main parity array doesn't stripe data, so writes are limited to single drive speed. Turbo write only affects parity involved operations, so without parity turbo write doesn't change anything. It's possible you may get better speeds if you write directly to the disk shares instead of user shares, bypassing the fuse system, also you could manually target writes to multiple disks simultaneously.