JonathanM

Do you have the disk location plugin installed?

640K blah blah blah 🤣

So, the parity check completed, then the server locked up and you replaced the drive? I'm confused. If something got lost in translation, I was asking when the last error free parity check happened prior to the drive change. You can't assign a smaller drive to a slot. Once you removed the old drive and replaced it with a larger one it expanded the partition to fill the larger drive. The parity emulated bits that were on the old drive were written to the new drive. The reason I'm asking about the last parity check is if parity was NOT valid when the drive was removed, what was written to the new drive is corrupted. What you can do is operate on the old drive using the Unassigned Devices plugin, see if it mounts, and if not, run the file system check there.

When was the last parity check with zero reported errors?

Try running the file system repair in the GUI on the rebuilt drive. Can't hurt at this point.

Couple issues that I need to work through. I'd like to make a little something from my hours of design work, however, it's using registered trademarks, so I'm not comfortable asking for money, or even releasing it without Limetech's ok. The Limetech team is super busy with way more important stuff, so I haven't even had the discussion with anyone that has the authority to discuss it. I don't want to add more distractions to the mix, it's bad enough that they are dealing with the premature announcement of the license restructuring.

This is all answered on the page linked in the pinned post at the top of this thread. https://unraid.net/blog/pricing-change

No. Each disk in the parity array is an independent filesystem, the user shares are a merged directory tree across same named root folders on all participating disks. Technically the answer to your thread title is yes, you can create vdisk's larger than the available space because they are created sparse, and only occupy the space actually written inside the image. However, as you found out, when the containing disk runs out of space, the vdisk doesn't have anywhere to put the data, so the virtual filesystem doesn't work correctly. Instead of using the parity array, you can assign multiple disks to a pool, which can use either BTRFS or ZFS RAID levels to create a single filesystem spanning multiple physical disks.

Most motherboards have 6 or more SATA ports, if you need more drives than that,

That will work fine.

If you have a different IP assigned to the container that's not host mode. A unique IP can open any and all ports without conflict. Host mode uses the Unraid main IP and can conflict with Unraid's native services. Bridge mode is more like giving the containers their own router and setting up port forwarding where needed.

If you are talking about changing the format of the drive when you switched them, you erased the data. Unraid's parity doesn't hold files, it emulates the whole drive, format included, so the only thing it can rebuild is the original format. When you reformatted, you told Unraid to put a new blank filesystem on the drive. Try attaching the old drive to Unraid and see if the Unassigned Devices plugin can mount it. If so, you should be able to copy the files back to the new drive. BTW, this is an old thread, I'd recommend starting a new one in the general support area.

It shows bridge mode allocations. Host mode containers open a whole can of worms, they have free reign to use whatever ports they want. Don't use host if you can at all help it. Do whatever it takes to figure out what ports are needed and use bridge mode.

Is fast boot disabled? Can you select the USB drive in the hard drive boot section? Some motherboards put the USB sticks in the hard drive list as well as the USB list.

As long as you can format it to FAT32 it should work. IIRC windows won't do FAT32 larger than 32G, but third party programs and non-brain dead OS's can as well. Use the manual install method, I'm not sure if the USB creator program can deal with it either. RUFUS is a good option for formatting.

Have you reformatted to FAT32 using RUFUS?

Look through the support thread specifically for tdarr on Unraid. If you can't find the answer there, the first post in that thread has a link to a discord, or ask in that thread.

Crappy print quality, but it shows the basic form.

Try recreating the .ovpn file from your expressvpn account.

Once you have your largest disk completely copied elsewhere, change the desired format in that disk's properties page, when you start the array it will show unmountable and ask you to format it. As long as that particular drive is the only one showing unmountable, go ahead and format. Then copy the entire content of your next largest disk to the newly formatted disk, verify the copy was completed accurately with file comparisons or whatever, change the source disk format, lather, rinse, repeat.

Do you have enough free space on your array to empty your largest data disk?

As long as you stay out of the /mnt/user tree, MC will be fine. DFM has built in safeguards to keep you from corrupting data by mixing user and disk paths. I recommend copying vs. moving, that way your old disks remain intact as a backup, plus it's much faster because the parity drive doesn't get thrashed writing to both data disks each operation.

Probably, but the file manager would most likely be better.