JonathanM

Seconded, that's the first suggestion that felt like it fit without being clumsy.

Will BI record to a network share?

What is "it all."?

Hopefully @iXNyNe will jump in and correct me if I'm wrong, but I assume you need to change the tag to an older version, then run the updater.phar command in the container console repeating the upgrade action until you get "current" with that image, then you can use later images to automatically update the nextcloud application version. This is described in detail in the info article you linked.

You need to whitelist the remote address you are connecting from. The allowed addresses need to be put into the LAN_NETWORK value of the container.

It's your baby, name it whatever you want. 😁

Since unfolding is a verb, unfolders sounds like the thing doing the unfolding. Not the worst suggestion I've seen so far, but it doesn't jump out and grab me. UnCategories? I don't like that any better than Unfolders though. UnCategorizer?

20GB of RAM is a strange number, it would imply either a pair of 8's or a single 16 and a single 4 or a pair of 2's. Are you sure all the RAM is actually working as intended? What physical sticks are plugged in to which slots?

Removing a drive slot completely will always entail copying the data off the drive to be removed, then either rebuilding parity without the drive, or forcing the drive to be removed to be filled with all zeroes so it doesn't effect parity when it's removed. Rebuilding parity is safer, the steps to wipe a data drive with zeroes are inherently dangerous as accidentally specifying the wrong drive to zero will always result in irreversible data loss on whichever drive is zeroed. Are all your drives perfectly healthy?

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.

Sort of, but it sounds like you are thinking the parity disk is more important than it actually is. Rebuilding a disk requires all the other drives to be healthy, so if disk 1 isn't healthy, the rebuild of both disks will have corrupt areas where disk 1 was unable to be read correctly. This very likely will result in unmountable file systems on both disks, which may or may not be recoverable depending on where the corruption is. Unraid will fail the rebuild of disk4 as soon as it encounters an unreadable sector on disk1. So, the only way forward with any chance of success that I can think of is to use ddrescue to clone disk1 to a healthy drive of the same exact size. This will allow Unraid to read all the sectors, even if the data there isn't accurate, so at least the rebuild of disk4 can complete, albeit with data corruption in the areas that failed the read during the clone process. It would be much better to simply recover the data from your backups.

That screenshot shows "Replaceable: Anytime" so it doesn't appear to be a too soon issue. Have you tried installing and connecting the "Unraid Connect" plugin? I seem to remember something about key management being moved there.

Are you planning on keeping up with this project? If so (please?) I think it would be best if you start a new thread, since the first 30 pages of this thread will be totally irrelevant to your code. On the plus side, if this plugin becomes essential and used by enough people it's possible Limetech would roll it into the main project. I think a rename would be welcome as well, since this is no longer just containers, it's also VM's. Dunno what to call it though, maybe throw out some suggestions?

Definitely agree, but it's hard to fix the issue when you can't consistently recreate it. Thousands of Unraid setups go many years without any USB boot stick errors.

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.

What location are you downloading to inside deluge, and where is that location mapped on the server? Post the docker run and a screenshot of the deluge path settings if you are unclear.

Edit the container and set the options you want. https://github.com/ytdl-org/youtube-dl/blob/master/README.md#output-template

Are you sure the slot you are using has enough lanes available? Can you try different slots?

That's because you didn't elevate the command prompt. Right click the command prompt icon and run as administrator

There are other ways of scripting this kind of thing if you need it. Basic outline for one method is... look for existence of specific file or content in public share if content exists, start VM and delete said content That way, user can touch file in public share to start VM.

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.

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.

contact support to get help with this error.

This has been extensively discussed in the support thread for linuxserver nextcloud. The link for container support is in the left click dropdown of the container icon on the dashboard or docker page of the Unraid GUI.

Set up the syslog server to keep a copy of the log after the crash, collect it and post in a reply.