JonathanM

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.

Some quick googling reveals that in order to get port forwarding to work with Metronet fiber, you must purchase a static IP for an extra fee each month.

Sure, I recommend setting up a utility VM to work with other VM disks. Once you have the utility VM running, you temporarily add the target vdisk as a secondary disk to the utility VM, boot it up and run gparted or partition magic or whatever your favorite partition manager program is, do your manipulation, shut down the utility VM and remove the secondary disk. The utility VM can be very small, just a minimal Ubuntu or whatever you are comfortable with.
 
Exactly the same type of thing you would do with a physical machine, only it's easier because you don't have to fool with finding a spare USB drive and setting up a bootable partition manager.

I do, and as long as you leave them in the same place in the user share, they will run from either location without moving if you want. I use this to keep seldom used or low demand VM's from taking up precious SSD space and writes.
 
/mnt/disk1/domains/VM1/vdisk1.img can be moved to /mnt/cache/domains/VM1/vdisk1.img and it stays available at /mnt/user/domains/VM1/vdisk1.img
 
You must set the domains share to be cache no or only so the mover won't interfere. If you set cache no, then new VM's saved to /mnt/user/domains will be created on /mnt/disk1/domains, or whichever array disk is a valid location based on the other share settings. If you set cache only, new VM's will be created on /mnt/cache/domains
 
You can freely move them to array or cache locations in the domains folders and they will appear in /mnt/user/domains
 
If you don't understand how or why this works, don't experiment until you do understand, as there is a risk of irretrievable data loss if you mix /mnt/user and /mnt/diskX /mnt/cache paths in file moves, as the same file appears in both paths but the OS doesn't know it's the same file and can overwrite it with itself, resulting in a zero byte file.
 
If you stay out of /mnt/user completely for file moves you are safe.

https://wiki.unraid.net/The_parity_swap_procedure

VM's are functionally the same as standalone computers from the user standpoint. What you are asking is a function of joining the machine to a windows server domain controller, so that is how you would need to do it with VM's as well.

Did you apply the new config and select the disks again in the main GUI?

This.
It's the number of drives physically connected when you hit the start button.
You could always connect the drive after you start the array if you want to use it as an Unassigned Device, and make sure it's unplugged if you need to restart.

Assuming you assigned the drives accurately, yes. You still need to do a parity check to be sure things are synced up, but there should be few if any errors.
 
If you are at all unsure about which drive is parity, don't proceed until you are absolutely positive, as the drive assigned to the parity slot will be overwritten. Drives in the data slots will be left as is.

Yes.
Yes.

Short answer, no.
 
Long answer, you can allocate space (vdisk) on an array drive or pool that can be seen as a physical drive to the VM, but the content won't be accessible through Unraid. 

If for some reason the USB Flash Creator tool cannot be used, or your USB flash device is not detected, it is possible to manually format and prepare a bootable USB flash device. Note: this method only works for devices 32GB and smaller.
Plug the USB flash device into your Mac or PC.
Format the device using the FAT32 file system. It must not be ex-FAT or NTFS.
Set the ‘volume label’ to UNRAID (case-sensitive, use all caps).
Go to the downloads page. to get the zip file for the release you want to use.
Choose a version and download it to a temporary location on your computer (e.g. a “downloads” folder).
Extract the contents of the newly downloaded ZIP file onto your USB flash device.
Browse to the USB flash device to see the newly extracted contents from your Mac or PC.
If you need to enable UEFI boot, rename the EFI- directory to EFI
Run the make bootable script appropriate to the OS you are using:Windows XP
double-click the make_bootable file.
Windows 7 or later
right-click the make_bootable file and select Run as Administrator.
Mac
double-click the file make_bootable_mac file and enter your admin password when prompted.
Linux:
copy make_bootable_linux file to hard drive
unmount (not eject) USB drive
run the following command from wherever you unpacked it to on your Linux system:
sudo bash ./make_bootable_linux
NOTE: during the process of running this script, the flash device may seem to disappear and reappear on your workstation a few times – this is expected behavior.

Preclear is NEVER required. It's purely a means to thoroughly test a drive, and optionally speed up the process if you are adding the drive to a NEW (not replacement) data slot in an already valid parity array. Unraid will automatically clear (not preclear) a drive assigned to an additional data slot, but if a valid preclear signature is found on the drive, Unraid will skip the clearing phase and immediately offer to format the new drive slot, saving several hours.
 
Rebuilding a drive always writes the emulated image to the entire capacity of the drive, regardless of the content of the drive, cleared or otherwise.
 
Reallocated sectors are not necessarily fatal, but depending on how many and if they are increasing it may be a sign of impending failure. A small number that doesn't increase over time is probably fine.

No.
 
There is no "installation" as Unraid runs in RAM, so it's loaded from the license USB stick into RAM on every boot.
 
Here is the forum section on running Unraid as a VM. While not officially supported by Limetech, it has been done successfully on several hypervisors. Since Unraid boots from a USB, runs in RAM, and itself hosts VM's, running it as a VM can be rather complicated.
 
https://forums.unraid.net/forum/46-virtualizing-unraid/

Skip the preclear, just replace the drive, build parity, do a parity check, do a long smart test on the drive.
 
Preclear is not productive for your situation, you want to get valid parity back in place ASAP. If you had a new drive in anticipation of replacing a drive that was still functioning, then preclear might be of some value, but only as a stress test to weed out infant mortality. You will get that same level of testing by rebuilding the drive and checking parity, and the bonus is you will be protected that much sooner. If the new drive fails during the process, you aren't in any worse shape, just back to needing another drive.
 
If you were getting a new drive to ADD to a NEW data slot, not replacing a drive, then preclear could save some time as well as give you a confidence check in the drive before trusting it in the array. This does not apply to your situation.

What is your split level?

Have you masked off or disabled the 3.3V reset pins on the drives?