JonathanM

It's not the RAM speed rating that matters, it's the motherboard / CPU memory controller that matters. Are you running the RAM at the approved speed for your CPU? It's likely several steps lower than the RAM rating.

In your plex settings, under library, what is "allow media deletion" set to?

You would need to set up the wireguard VPN, or use a VM over the built in NoVNC instance, or set up a reverse proxy with SWAG or something similar.

100% agree. Being proficient in database management is a very useful skill.

It's highly recommended to keep docker containers and their operating appdata on SSD based pools, for many reasons, including this.

Doesn't matter where the container comes from, the docker engine manages the layers by checksum. When you get updates, watch as the different pieces get pulled, only the changed layers get updated, and if you have 2 copies of the same container with different names, updating the first instance will update all the pieces of the second, as they are the same.

For less experienced users, I recommend multiple database containers each with their own app connected. Since the docker engine shares image layers, the extra storage is extremely minimal, a few KB for the config files. The advantages of being able to blow away a single database without affecting the others while not needing to know database management commands is helpful.

User shares are just a combined view of same name root folders on all the array disks and pools. You can enable disk shares and move the appropriate root folders to the disks or pools you want. When working with the disks and pools directly, do NOT use the user share paths, as they are simply a different named path for the same files, and mixing the synthetic user shares and the direct disk paths in file operations can result in data loss.

https://forums.unraid.net/topic/117190-file-system-audit-to-detect-file-deletion/?do=findComment&comment=1071101

It depends on the platter density. There are some 7200 RPM drives that have less throughput than some 5400 RPM drives. IIRC, what was said was that the RPM is only one factor, you can't determine performance solely by spin speed. If you have 2 identically sized drive models with the same number of platters and heads, then yes, RPM is the determining factor. If you have a 4TB drive with 2 platters at 5400RPM vs a 4TB 5 platter at 7200RPM, the 5400 will have a better throughput number and much better power and heat dissipation. Since drive manufactures generally don't publish platter and head counts, you must look at real benchmarks to determine performance. You can't just look at RPM.

Are the episodes already watched? Check the show profiles to see if remove after watching is set.

https://forums.unraid.net/topic/51703-vm-faq/?tab=comments#comment-557606

Click compute all, wait for it to finish, refresh the page if necessary, then post the results.

Update BIOS?

https://empyriononline.com/threads/dedicated-server-for-linux.10355/

If I had to guess, I'd say your UDM is "helpfully" attacking your server.

Not easily. Since you aren't concerned about rebuilding a drive, it would be easiest just to make your best guess and build parity fresh. If you are interested in the nitty gritty details, the short answer is that parity1 is valid as long as all data drives are present, parity2 is a different much more complex set of equations that is valid if all data drives are present AND in their proper slot numbers.

Tools, New config. DON'T accidentally put a data drive in the parity slot. Parity slots will be erased. If parity was previously valid, you can tell Unraid that, and just do a check to be sure, but the drives must be in the same slot numbers for parity to remain valid.

Multiple Unraid servers.

USB 2.0?

Many of the extra features that Unraid is so good at require internet, so in that sense it's designed to have internet. On the flip side, it's perfectly capable of basic functioning without internet, but you will have hurdles to overcome for each additional service you want to add. What functionality are you trying to get going?

What exactly does that mean? No POST, no video, flashing cursor, etc... There are many different flavors of no boot, most hardware related.

Curious as to your reasons for that. I have a low power bare metal pf box that I keep updated periodically, but my daily pf is a VM in Unraid, much faster VPN and just overall performance. When the Unraid needs to go down for maintenance, the bare metal box is fired up to keep everyone connected, but for day to day use, it seems like a waste NOT to use the VM.

There's a second step to change from macvlan to ipvlan, I believe it's in the docker settings after you get the upgrade running.

What you saw, while definitely not desirable, was predictable based on your settings. 1. Cache prefer means send new data written to the share to the cache drive, and when the cache drive is full (more on that in a sec) start using the array. When the mover is run, attempt to put any overflow that went to the array back on the cache. Basically, that share is set to prefer to live on the cache drive exclusively, and only go to the array when the cache doesn't have any room left. 2. Unraid determines where to write new data based on a bunch of settings, and when a target drive or pool gets close to filled, it relies on the minimum free setting, which needs to be set larger than the single largest file you intend to write to that share, so any particular drive doesn't get completely filled. Unraid can't know how large any specific file will be until it's fully written, so it's up to you to set a free space margin that makes sense for your use case. Combine cache prefer with a floor of zero free space, and when the mover ran it filled the pool, and crashed the user share system. Filling any filesystem completely and then attempting to write more data can have unpredictable results, especially when the filesystem is layered like Unraid's user share system. Good news is that the files on each specific drive are fine, it's just the user share system that lost the plot. Rebooting should bring that back. To fix the issue, you need to set the share in question to cache:yes and run the mover, so it cleans out the cache drive to the array, then when that is complete set it to cache:no so further writes go straight to the array. There is no point in using the cache for initial data transfer, as you will inevitably fill it up and then have to wait for the mover. It's faster to write directly to the array so each piece of data only gets transferred once. You also need to set minimum free space for the shares and pools to a reasonable figure so Unraid can appropriately allocate between disks and pools and not run completely out of space on any single volume. Such is the downside of individual filesystems that allow differential spindowns and isolated drive recovery as opposed to traditional RAID. I recommend turning on the help in the Unraid GUI with the question mark, that will expand out the help text that explains share settings in more detail.