primeval_god

Having Docker containers and VMs that access the internet (but are not accessible from the internet) is generally fine, they are isolated from the host os to varying degrees. As for remote access the recommended way for unRAID is using a VPN into your home network as that is the most secure. Some people expose services in VMs and containers using a secured reverse proxy, which can be ok if you know what you are doing and are not exposing the unRAID host OS itself.

Personally I achieve this with the user.scripts plugin. I have scripts that run on a schedule that execute docker pause and resume commands.

Keep in mind that the "Apps Page" is actually a third party plugin called community applications (though it is developed more closely with Limetech than most). It acts as a convenient way to discover and install containers and plugins but it is not the only way to do so. Also speaking from personal experience I have in the past typically not run the latest version of unRAID (I usually stay a version back). The lack of security updates for older versions (which was how it used to work before the licensing change) was rarely something that concerned me. unRAID is designed to run from within a home network, with minimal exposure to the outside world.

This is a NAS appliance OS security has never been a priority. Ok thats not entirely true (said mostly for effect) but the fact is that the unRAID OS has always been slow to get security updates (except for the occasional critical issue), has a fairly lax security model, and is intended to run on a home network with no exposure to the outside internet. unRAID is a consumer product only with no enterprise level.

The term "Array" is old nomenclature that refers to the singular required drive pool that uses the unRAID's proprietary unRAID scheme. The "Array" pool can contain mixed drive sizes and types (though mixing SSDs and HDDs in not recommended), as well as up to 2 parity drives to maintain redundancy for the pool. unRAID also supports optional secondary drive pools (previously called cache, but weren't a cache in a typically sense of the word). These secondary pools can be single disks or have redundancy via ZFS or BTRFS software raid levels. These secondary pools are separate from the "Array" pools in terms of redundancy. In terms of file access unRAID has user shares which preset a combined view of folders from all the various drive pools. There are options to set which pool data gets written to when writing to a user share and when and if data gets moved between pools. One common usage of this is to direct all writes to an SSD pool and then have unRAID move the files onto the Array pool later. Finally to the point above, the general recommendation is to have an SSD based pool to store appdata on, separate from the Array. Whether or not the pool used to store appdata has redundancy is up to you but it does not effect the configuration of the "Array" pool.

Yes send and receive work on subvolumes only (snapshots are just a type of subvolume). Yes the other filesystem has to be BTRFS for send and receive to work, the send subvolume becomes a subvolume on the receiving filesystem. I am not entirely sure about the capabilities of this plugin with regards to scheduling. BTRFS send and receive does a sort of differential send when subvolume/snapshot is based on subvolume/snapshot that is present in both filesystems (assuming you use the option to specify the parent). This reduces the amount of data sent for subsequent snapshots of the same subvolume. I am not sure if this plugin actually makes that option available though as I do my snapshot sending via the command line.

You will want to stop any Docker containers that have a mapping to or within the share you are operating on while you make changes, aside from that though you dont need to make any changes since you are creating the subvolume with the original path. Likewise you shouldnt need to make any changes to share settings since so far as unRAID is concerned the new subvolume (which has the same path as the original user share) is the existing user share. Where you store snapshots doesnt really matter, they can be anywhere within the same pool (they dont have to be within a subvolume). Snapshots themselves are just subvolumes anyway. This is not entirely true but it requires some explanation. When you snapshot a subvolume the snapshot must be made somewhere on the same filesystem (pool) as it is a CoW copy of the subvolume (and a new subvolume itself). You can however send subvolumes from one BTRFS filesystem to another using btrfs send and receive (which are available in this plugin). Doing this copies the subvolume to the other filesystem and thus it is no longer CoW copy but a full copy taking up space on the other filesystem. Once a subvolume is sent to the other filesystem there is a way to send subsequent snapshots of that subvolume between the two filesystems in a way that maintains the CoW relationship between the subvolume and its snapshots.

The issue is with unRAID not this plugin. Last I was aware there was an open PR fixing the issue.

Is there a question here? I dont really understand the post.

The changes you are making are likely not taking effect. There is a long standing issue with how dockerman handles the webui and icon labels. Basically it caches them the first time a container is seen and subsequent changes dont have an effect. Try restarting your server, that may fix the webui label issues.

That is a Dockerman question. The compose plugin only assigns the labels to the containers. Unraid's builtin Dockerman is what actually reads the label and caches/displays the icon.

Did you get any response on your support ticket?

Still having that flash drives fail with that frequency is not normal. It suggests some sort of hardware or configuration problem. Do you notice continual writes to your flash?

Is this a container run via unRAID's built in Dockerman interface or by some other method?

Other options for installing things are via virtual machines, or LXC containers (using the lxc plugin)