JonathanM

https://unix.stackexchange.com/questions/445652/how-to-mount-and-de-encrypt-a-luks-encrypted-partition-to-recover-files google mounting luks volume Unraid uses a standard encryption type, so it's pretty easy as long as you have the encryption credentials or token.

What is your domains share cache setting?

Base OS packages, update frequency, support location, support responsiveness.

Try nomachine.

Is this not working for you? Post in that thread with diagnostics if it's not.

Most likely cause is that the path you are attempting to write to, is not the disk you think it is, rather a placeholder put there to keep people from crashing their machine by copying large files directly in to RAM. Can you see the current contents of the path you are trying to write to? Does it match what should be on that disk? Side note, since Unraid supports multiple pools, you probably should be assigning the disk to a new pool instead of using UD if you are planning to run the VM from there.

Put the old CPU back in, if that solves the issue then you know where to start troubleshooting.

Once you start the array with the disk unassigned, you can stop the array and assign the same disk back to the slot and let it rebuild. You just have to make Unraid see the drive as a replacement.

The built in memtest will still somewhat exercise the ECC, but doesn't bypass the ECC functionality, so you have to look in the BIOS for memory error logging to see if the ECC registered a correctable bit error. The way ECC is supposed to work is if the memory error is correctable, it corrects and logs the the error, similar to the way Unraid corrects for a read error on a hard drive. If the error can't be corrected, it hard locks the machine to keep silent errors from multiplying and corrupting things, similar to how Unraid drops a hard drive when it gets a write error. I agree more could be done to educate about the limitations of the built in memtest, it's many years old at this point.

Temporarily remove the USB connection from the UPS, and see how it acts. That should isolate whether it's a load issue, or a monitoring issue.

Most games use protocols other than http or https, so an SSL cert is not really relevant. A domain name pointing to your WAN IP, and forwarding the correct ports through your firewall is typically what you need. If your WAN IP is not directly routable, or your ISP has firewalls in place that you can't open, then hosting a game server may not be possible.

Either add more RAM limit the amount of RAM your containers are allowed to use quit using the containers that use too much RAM set up a swap file on a pool disk (not officially supported, but has worked for some in the past) Keep in mind that the OS unpacks into, and runs entirely from, a RAM disk, so killing processes that are consuming excessive RAM is the only defense against total crashes. It's also possible that you have something writing to RAM, since all the typical OS locations are in RAM instead of on a hard drive. If a file is being written to a location not mounted to one of your array or pool disks, it's writing to RAM. Without you taking the steps to figure out which container(s) are causing the overflow it's tough to help. The VM reserves as much as it's assigned, and that chunk is untouchable to the OS, so even if the VM has free RAM the OS can't use it. Best to reduce the VM RAM to the smallest possible amount, and let the OS manage the rest.

From the "cache.cfg" file in your diagnostics diskFsType="btrfs" diskComment="" diskWarning="" diskCritical="" diskUUID="807aadb9-984a-4d8e-a384-34e2c8b9fc7c" diskShareEnabled="yes" diskShareFloor="0" diskExport="e" diskFruit="no" diskSecurity="public" diskReadList="" diskWriteList="" diskVolsizelimit="" diskCaseSensitive="auto" diskExportNFS="-" diskExportNFSFsid="0" diskSecurityNFS="public" diskHostListNFS="" diskId="Samsung_SSD_840_Series_S14GNEBCC22846E" diskId.1="Samsung_SSD_850_EVO_250GB_S21NNXCGA64390W" diskIdSlot="Samsung_SSD_840_Series_S14GNEBCC22846E" diskIdSlot.1="Samsung_SSD_850_EVO_250GB_S21NNXCGA64390W" diskType="Cache" diskType.1="Cache" diskSpindownDelay="-1" diskSpindownDelay.1="-1" diskSpinupGroup="" diskSpinupGroup.1=""

Depends. Some combos work, some seem to be problematic. Only way to know for sure is install a trial and see. If it boots and allows you to register the trial, it will work.

Change /Media to /data in the first one, or /data to /Media in the second, doesn't matter a whole lot which one you change, but the whole line must match for all containers that share the download location.

We still see sob stories here about people losing files, so obviously not everyone already knows, or if they know they don't do backups, so we repeat it every time someone is in a position that could result in file loss if things don't go perfectly. Parity only helps when a single (or double if 2 parity) drive fails. There are many more common ways to lose data, accidental or malicious deletion, corruption, bad RAM, PSU failure or connection with incorrect modular wires that destroys whole bunches of drives at a time, etc. It's something that needs to be kept at the forefront of data discussions, especially when people erroneously think the biggest risk to their data is something that parity can recover. If you want drive redundancy in place for the faster SSD pool as well as the main parity array, you can add a second SSD of the same size to your pool and convert it to RAID1.

The screenshot he showed is definitely from Radarr, it says so in the yellow explanation text. Here is mine from sonarr, I have 755 but the setting is disabled on both Sonarr and Radarr and it works like it is, so I'm not inclined to monkey with it.

post the docker run command that triggers it.

Think of the hard drive as an empty room. You could just throw stacks of papers in the room when you want to store info, but finding any specific piece of paper would be a nightmare. Now fill the room with filing cabinets and folders, with a dedicated area just to record the title of each piece of paper, and which drawer and folder to find it in. That filing system definitely takes up space, and the more info is kept on each paper, along with possible multiple copies of the table of contents with cross checking just in case one gets messed up, and you can see why there is so much space taken up on an "empty" hard drive. The file system type, XFS, BTRFS, NTFS, FAT32, each one keeps up with all that info in a different way, and each has strengths and weaknesses. When a drive becomes unmountable, it means the filing system that keeps up with the location and extra info like name and location on the drive is messed up in some way. If you format the drive, you tell the system to clean out the table of contents, forget about anything that was ever stored, and start over with a fresh blank slate. It doesn't actually throw away the virtual pieces of paper, just overwrites them as the space is called for.

Add more RAM

Which should find and correct all the errors, then run a non-correcting check.

No, but google did modify the procedure, you must set up 2FA and provision a new app password. Previous passwords probably won't work. Already discussed here.

Probably. Revert the changes and reboot, monitor.

If the data missing from the shares that is now in lost and found is irreplaceable, you will need to manually sort through it to find what you need.

Most likely explanation is that the help text is wrong, and 0 is being used as the value. Does it work properly if you set that to something other than 0?