JonathanM

Probably cache-dirs plugin.

Try a different browsers, try incognito mode, see if there is something blocking the page from loading.

See if this helps explain things. https://wiki.unraid.net/Manual/Overview#User_Shares

Click "Prereleases" at the bottom of this screen in the navigation bar, then click on the rc2 thread.

Yes.

Does this help? https://wiki.unraid.net/Manual/Storage_Management#Moving_files_between_a_Pool_and_the_array Mover has many jobs, it can put files ON the cache as well as take them off.

Might want to keep in mind the power on hours and writes to the backup make it theoretically more susceptible to failure than if you keep it a cold backup. I'm not saying this isn't worth the risk for most people wanting to keep a hot spare, just something to be aware of and possibly mention in the write up. The big advantage is in the event of a failure, the automated license replacement procedure can be done on the failed drive when it's convenient with no time pressure, and then the new replacement can go back in as the hot spare.

One way would be a user script monitoring the containers and issuing docker stop and docker start commands. Specifics would depend on the containers in question.

enable hairpinning / loopback in your router or set a hosts entry

I'm a little hesitant to post recommendations publicly, but I've successfully used easydns for many years to do exactly what you are asking. I have multiple static IP's, but apparently they support dynamic IP's as well, I've never needed to try.

Each parity drive (up to 2 for the forseeable future) can rebuild 1 missing data drive, providing all the other data drives are working properly. Unless you only have parity1 and a single data disk, they aren't going to be mirrored. Redundancy is for high availability, it allows you to keep using the storage when a single drive fails as well as during the rebuild process. Redundancy IS NOT BACKUP. It can't recover corrupted files or deleted files, or restore older versions. For data that is important to you, keeping a copy (or 2 or more) physically separate from your server is needed. Most people don't back up 100% of what they keep on the server, only the files that are difficult or impossible to recreate. You get to decide how important your files are.

No. Try disabling spin down and try again.

Tools, new config, preserve all, apply, go to main tab, make sure assignments are correct, start array and build parity.

Check filesystem on disk 1.

Is there any data on the emulated disk?

Try removing the <boot order='1'/> line completely. <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source dev='/dev/disk/by-id/ata-CT1000BX500SSD1_2020E2A2DEBF-part6'/> <target dev='hdc' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk>

No. Trial keys require internet to start the array, so you are in a catch 22. Your steps to set up a licensed key look correct to me. The only caution I have for you is being diligent about keeping the backup key current. There are some doomsday scenarios where you could lose a bunch of data. One I can think of off the top of my head is if you reuse a drive assigned to parity as a data drive, and accidentally boot from a backup copy that still has that drive assigned to parity. As an aside, I run my network with a pfSense VM on one of my Unraid servers, but I keep an old PC loaded with pfSense ready to fire up when needed. You really should have an alternative routing solution ready to step in at a moments notice, hardware does sometimes fail spectacularly, and it would suck to deal with lack of internet while trying to fix your broke hardware.

Short answer, copy the files elsewhere, format to XFS or BTRFS, copy files back. There is NO way to switch file systems in Unraid without losing the data that is on the drive. Take a look at the sticky thread in the general support area for some strategies, my favorite is either a new additional drive as large or larger than any existing data drive, or if you have enough cumulative free space to empty your largest data drive by copying files to other drives. Either way, copying is much faster than moving for a bunch of reasons, plus you can verify the copy is good before formatting the ReiserFS source drive. It's possible you could get away with copying the data from the read only disk2 to another disk if you have enough space, then reformat that disk after the data on that disk is safely copied.

Check the mount points with the ARCH media. Unraid doesn't run ANY of the OS from the USB stick, because it uses the USB as the license media, and read write activity is kept to an absolute minimum. I'm fairly sure the ARCH media will be mounted and used as part of the OS. The Unraid USB is mounted as /boot, and the entire OS with all libraries is extracted into RAM from the bz* files.

Pedant alert. The term rail is typically used as a design element, where a single rail PSU is capable of providing all the rated amperage into any and all of the connectors. A multi-rail supply subdivides the capacity arbitrarily, so that perhaps half of the rated power would be available on a specific set of connectors, the other half exclusively to another set. What you are referring to, the bundles of cables coming from the body of the PSU, are typically all tied to one "rail" inside the box. Multi rail PSU's typically reserve a chunk of power for the video and motherboard leads, which can cause issues if you are expecting the full advertised power to be available for the drives, which is why a single rail was more desirable for a drive heavy server in the past. Nowadays the higher end PSU's tend to manage that sort of thing better, so it's less of a concern as long as it's a decent design. </pedant>

What generated those files? I suspect they may be left over from ancient plugin versions of those programs, I suggest opening them and see what they contain, also see what date they show. I'm guessing you should just delete them.

Post your XML with both drives added.

Temper your expectations, but not to the extent of valve. Unraid time is it's ready when it's ready, stop asking. However, things do move ahead, just not fast enough to please everyone.

@SpencerJ?

Maybe this was mentioned earlier or in a different place, but I apparently didn't see it. When SSL/TLS is set to NO, port 443 still answers with a self signed certificate and a 404 error. This was a breaking change for me from RC2, as my NGINX server container set to use 443 failed to start with a very unhelpful server execution error with no code. Expected behaviour would be for 443 to be available as long as SSL/TLS is set to NO for management access. Please either revert the behaviour to RC2, where the settings work as expected, or provide help text to indicate the new behaviour. I spent way too much time troubleshooting an error starting a container with no indication in the logs or an error message that told me where to start investigating.