JonathanM

Pure speculation, but most likely it's updates to the base OS that the container uses. Think of containers like miniature virtual machines, they have an OS layer as well as the application or whatever script it's running.

The diagnostics say that whatever is at the OTHER end of the cable is most likely the issue.

Then something is wrong, it normally starts them from top to bottom, and you can insert a delay after each one if you wish. To change the order you click the green padlock to unlock sorting, to set delays you toggle advanced view. The delay for a container is AFTER that container is started, not before, so there is no way to delay the start of the first container.

Was that after a reboot?

Wireless seldom achieves rated speeds in real world environments. Too much ambient radio noise and attenuation. If you are doing speed testing with wireless, best to be in the same room within a few feet of the access point.

Depends on the USB implementation of both the motherboard and the drive. Some seem to be stable, others flake out and disconnect on a whim. No way I know of to tell the difference without trying it. It's not recommended simply because it's unstable more often than not, and there are other issues with USB in the array itself, which you aren't doing, so if it works for you in this specific instance, great. I wouldn't expect a whole lot of speed though.

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?