JonathanM

I can't remember if there is a guide, but here it is in a nutshell.
 
1. Shut down the Windows 10 VM fully, hold down the shift key while clicking the Shut Down item.
2. On the VM page, click on the name text of the VM, it will drop down a list of the attached disks.
3. Click on the 70GB text in the capacity column, and change it to 90.
4. Boot the VM back up, go to disk management, and expand the partition to fit the new vdisk.

After a reboot, yes.

mirror is NOT backup.
 
Backups can be restored to fix things like file corruption and accidental deletion.
 
Mirror keeps the files identical in realtime, so if a file is deleted, it's gone everywhere.
 
mirror is NOT backup.
 
mirrors perform best with identical drives, but can be forced to use vastly different capacities and speeds, typically you will be restricted to the limits of the slower and smaller of the disparate drives.

👍

This.
You can attach as many additional drives as you want after the array has started, but the array will NOT start if the number of license limit devices are exceeded. Virtual devices don't count.
 
Why? All you really need to get started is the USB stick to set up a trial Unraid install, and a single drive that can be erased and used as Disk1 in the array. As long as you don't assign any of your current drives to Unraid, it won't touch them.

You can just remove the section of xml that you pictured.
 
Read this thread for more discussion.
 

Enable bridging in the main network settings.

Since appdata is cache pool only instead of cache pool prefer, it can't overflow to the array when it runs up against the pool minimum free space. Click on the pool name "Cache" in your screenshot to see the minimum free space setting.

If the two drives were EVER assigned to the same pool, even briefly, they "permanently" remember that status because BTRFS keeps a record of pool members totally separate of Unraid's pool definition. To remove them from the BTRFS pool can require extra steps, @JorgeB is the resident expert on what is required. Theoretically if the drive is removed from Unraid's pool correctly, the status is updated and things work as intended. If you physically remove the drive, I believe it may still have the BTRFS headers on it that make it a member of the pool, I think you have to leave the drive installed and remove it from Unraid's pool definition, then the pool is rebalanced to remove it.
 
I'm a little fuzzy on the exact procedure, but what you experienced is a symptom of both drives being assigned to a single pool at some point in the past, and not being properly BTRFS balanced to separate drives.

edit the container, top right, toggle basic view to advanced view

1. Unraid tracks drives by serial, not physical location, so you can freely move drives around physically to different ports, Unraid won't change how they are assigned to their logical slots, so put the drives in any physical slot that makes sense to you.
 
2. Since Disk4 (E) has no data AND you are building a new parity drive, nothing particularly fancy needed for this.
   Take a screenshot or some other record of which serial numbers are in which logical slots.
   Power down, physically remove the old parity drive and and the 1TB drive, install the new parity drive, rearrange the drives the way you want in the case, power back up.
   Tools, new config, preserve current assignments ALL, apply, go to main page, drop down the parity slot, VERIFY the serial number of the new parity drive, CHECK IT AGAIN. B and C can stay where they are, since D is empty I'd leave it out as well as E, you can add D back later if you really need the space, better to leave it out, less power and less risk.
   Verify you have the correct serial numbers for the new parity, disk1 and disk2, at this point it should be new drive in parity, B in disk1 and C in disk2. Start the array and build parity. After parity builds, do a non-correcting parity check. If you have zero errors, you can proceed.
 
Stop the array, power down. Replace the 2TB disk with the old 4TB parity disk, power up, select the correct disk for the disk2 slot, and rebuild. Do a non-correcting check.
 
At this point, you should have your new 4TB parity drive, the original 4TB disk1, and the old parity drive as disk2 with all your data, and 2+TB free space on disk2. If you need the space NOW, then add back the 2TB you designated D, and optionally the 2TB you just replaced with the 4TB as well. Keep in mind that each extra spinning drive is a possible point of failure, since parity requires ALL remaining data drives to be read perfectly end to end to rebuild a single failed drive, even if some of those data drives don't have any data yet.
 
You would be better off not putting those older drive back in the array if you can help it.

The screenshot you posted for sonarr shows
 
Container Path : /data
Host Path : /mnt/user/appdata/data/
 
If the full pair of paths don't match between the applications, they can't find the files.

Create a share for each category.

Unclear from your title and description what is actually happening.
 
Did you accidentally assign a data drive to the parity slot?
 
When you removed a drive, parity was no longer valid, unless you wrote zeroes to the entire drive to be removed. Empty implies a formatted filesystem, which is part of parity, and probably deleted files, which are also part of parity.
 
Your title implies you put the wrong disk in the parity slot, but the body of your message sounds like everything is working correctly, you just need to unassign the parity drive, reassign it, and rebuild parity based on the remaining drives.
 
 

Perfectly normal. Check the box that acknowledges "Yes, I want to do this" and it will become available.
 
We make it a multi step process to format drives because too often if someone has file system corruption the first thing they want to do is format the drive to make it mountable and then they think parity will restore their files, when the correct thing to do is a file system check. Formatting replaces the table of contents with a blank version, and it effects the parity drive as well, so it makes recovering data much harder or impossible.
 
In your case, you genuinely DON'T have a valid filesystem yet, so check the box and apply the format.

Yeah, restore from backup is the only real option. XFS recovery is bad enough, add encryption to the mix and I'm not sure I would even know a good path forward. Encryption complicates data recovery immensely, pretty much on purpose. If you use encryption a comprehensive backup strategy is essential.
 
WAY different. XFS recovery isn't exactly easy and the tools aren't free AFAIK. It's assumed if you are advanced enough to use XFS with encryption, you know enough to keep good backups.

No, totally wrong.
 
Format is part of parity, so if you remove a drive and format it, Unraid will rebuild it with whatever format was on it prior to removal. If you set a new config and rebuild parity that would work, but you are unnecessarily risking a drive failure.
 
Simply click on the target drive in the main GUI with the array stopped, change the file system type to XFS, and when you start the array it should offer to format that drive, and ONLY that drive. Make sure the target drive is the only one in the list to be formatted.

try a different browser / incognito mode

Not a simple question. Short answer, yes, it's supposed to stop the array.
 
Long answer, it may not stop the array cleanly if something is holding it up. If stopping then shutdown works quickly 100% of the time for you, then it should do a clean shutdown.
 
I personally always stop the array first, because I want to monitor the entire process to make sure things are working properly. I've had many instances where something was keeping a file open that I would have to chase down and manually kill before the array would stop cleanly.

Which should find and correct all the errors, then run a non-correcting check.

/mnt/user

Is this not working for you? Post in that thread with diagnostics if it's not.
 

6.10.3 includes the fix for this, so as long as you upgrade directly there you will be fine.

The official plex container doesn't have a support thread on this forum, they have their own support at https://forums.plex.tv/
 
There are several plex containers that are supported here, maybe try one of those if you can't get the official one to work?

Maybe, depends on the enclosure. USB is not recommended for Unraid's main array for many reasons.
 
I recommend watching a few youtube videos on Unraid, so you can get a feel for what it is and isn't.
 
Also, https://wiki.unraid.net/Manual/Overview
 
The way Unraid's main array works means all the disks must be accessed simultaneously for parity building and recovery operations, and USB is bad at that type of I/O, some enclosures and USB controllers also have a bad habit of resetting connections which can cause a drive to get kicked from the array.
 
Some have managed to get USB to work somewhat, but it's definitely not ideal.