JonathanM

Unclear on what you are asking about CPU, Unraid uses linux standard KVM virtual machine stuff, CPU passthrough exposes features of the host CPU and limits usage to the assigned cores, you can also limit the hosts ability to access cores to keep them exclusively for use by VM's. The VM's motherboard is always emulated, you can pass through select PCIe or USB devices, which excludes them from use by the host.
 
Unraid is a single payment up front, no ongoing payments for the OS license. Licenses purchased 10 years ago are still valid for current releases.

Each pool is a single entity with regards to file system, so hardlinks don't know or care about the individual disks in a pool.
 
RAID0 with 2 members will give you double the space of the smallest member. Single profile will add the 2 members together. Either will cause a total loss of data on the pool if either member fails.
 
New versions of Unraid allow ZFS as well as BTRFS for multi member pools. ZFS may be more reliable than BTRFS, I haven't had very good luck with BTRFS.
 
Any file system change to the pool requires backing up any content as the format will erase all data. Changes in BTRFS profiles may be able to be done without reformatting, but backups are still recommended.

Since you seem to be able to trigger the issue, it should be fairly straightforward. Assuming multiple sticks of RAM, remove half, run test, remove other half and replace with prior removed sticks, repeat test.
 
Passing doesn't mean the RAM is good, it means the test didn't trigger an error. Only a failed test is fully conclusive.
 
Also, since the CPU is more directly involved with the RAM sticks on newer builds, loading up the CPU can uncover RAM issues.
 
If it's not clear from my approach, I suspect your issue is certainly within the RAM's chain of custody of the data. Random(ish) corruption is almost always RAM related.

Does that answer your question?

Not that I can think of, but you can certainly start a container from a script. Disable the auto start for that container on the docker page and script the startup separately.
schedule at array start
sleep however long you want to wait
docker start containername
run the rest of your commands.

You could...
 
relax the affected share split levels and disk exclusions and verify your minimum free space settings
 
manually move files from disk to disk to free up the space needed
 
upgrade disk to larger model
 
add disk
 
You are going to keep fighting with this until you add more space or delete unwanted items to free up space. Converting h264 media to h265 can free up loads of space as well.
I recommend reading through the help tips on the share page in the GUI, it might help you figure out specifically what is the immediate issue, as well as give you tools to manage it on an ongoing basis. You are running out of space, you will need to actively manage your share allocations until you get more space.

to mount a share you must use a valid user, not root
to connect to the console, you must use root, not one of the users
use that path as the rsync destination, assuming it mounted correctly and you see the contents of the unraid share at that local path.

What address and port are you trying in guac? I know a plain VNC client works fine for me using the server ip and the normal 5900, 5901, 5902, etc depending on what order the VM's were started. The VMS tab graphics column shows the port.

Here is a link to a post with some of the parts you need. I use it to start a VM after my gateway IP is pingable.
https://forums.unraid.net/topic/78454-boot-orderpriority-for-vms-and-dockers/?do=findComment&comment=727416
 
You could reuse some of the code to stop and start containers with the docker pause and unpause or stop and start.
 
It would need a major rewrite to accomplish exactly what you want cleanly, but I think all the parts are there.

The new config tool will allow assigning (and unassigning) whichever disks you want, any disk assigned to the parity slot(s) will be overwritten with a fresh parity build using only the assigned disks when the array is started.

I'm not familiar with the exact commands required, but I'm sure a Truenas pool doesn't import automatically YET. Something to do with the partition structure on Truenas using the second partition instead of the first. You should be able to import using the command line after each reboot, and importing automatically should be handled sometime in the nearish future.

Only if you had the syslog server already set up to mirror to the usb.

There should be a previous folder on the flash drive that contains the files that were replaced in the root. Either copy them back, or if you can't find a previous folder, download the 6.11.5 zip and get the root files from there. Don't overwrite anything in the config folder.

It will show an error count if there are any differences in what is read from the parity disk and what is calculated from the data drives. The messaging is currently the same whether those errors are simply noted, or corrected.
Correct. Parity is kept up to date in realtime as writes are done. As long as the drive internal caches have finished their writes before power is lost, there should be no sync errors.
 
If there are writes in progress, the data drives are higher priority, so it's entirely possible that a write can be successfully completed on the data drive but the parity write has yet to be fully committed, causing a sync error, a correcting parity check will complete that process. It's also possible for a power cut to corrupt a data drive if a write in progress gets cut off at just the wrong moment. In that case parity can't help, because it will have even older data. Most of the time the file system checks can at least get back to a readable state, at the expense of a corrupted file or several.

Unclear what you mean. The drives will remain accessible after you enter the passphrase until the server is shut down. When you start the server again the encrypted drives will be unavailable until the passphrase is entered.

Move the vdisk from the array to the pool using dynamix file manager or mc at the console or whatever your favorite file manager is, then change the VM XML to point to the new location.
 
Or, to make it even simpler, assign the pool as the primary location for the domains share, assuming the vdisk is in the domains share, and the array as the secondary location with the mover set to move from the array to the pool. This assumes your pool is big enough for all the content of the domains share.

Flipping the switch on the PSU kills power to the motherboard, then you need to press the normal power switch to drain the residual power in the capacitors in the PSU and on the motherboard. No need to leave it off for long, just so the motherboard has no more power to maintain the failed state, and has to reinitialize from a known state.

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/#comment-511923
 

Port mapping only applies to bridge mode. When a container has a different IP address than the host, mapping is not used or needed, all ports are open and the listening port(s) are directly controlled by the application(s) in the container.

Definitely not.
While some hardware may work, it's not a universal thing. Hotswap has to be supported by the HBA and the drive cage, so it's safer to power down when unplugging and plugging drives.
 
The only quibble I have with your summary and the original is the last step, I'm not sure why it's there to be honest. Formatting would erase the pool, so don't do that unless you don't need the data on it.
@JorgeB, could you check that to see if I misread something?

That should be fine.

Was that after a restart without touching the interface with Firefox at all?

No.
 
That may change with future versions that don't require any disks in the parity array to start Unraid, but I'm just speculating on that.

The issue seems to be with Unraid still thinking the disk has a valid filesystem, if you stop the array and start it again so the disk shows unmountable, the write speed will increase dramatically. The only issue there is that the script won't work on an unmountable drive, so you must use the manual command line. If you mess up the command line, you can permanently erase a drive you didn't want to. If you are careful and match the md? correctly you will be ok.

Is the default format type still encrypted?