primeval_god

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)

If this is the case then you are doing something very wrong. I have been using the same flash drive for 5+ years without issue. On a normal unRAID system the flash drive incurs minimal reads and writes as the os is run completely from ram. The only writes should be one the occasion that settings are changed or plugins or OS is updated.

Logs (specifically anything that mentions swapfile) and the specifics of your settings would be helpful. Also the actual unRAID Version as i am not certain what the last 2 minor releases were.

This thread is not really the right place to ask about issues with specific compose stacks, unless the problem is with the compose manager plugin rather than the stack itself. Having lots of people post whole compose files in this thread makes it harder for others to find info about the plugin itself. I am not really an expert on compose files in general and i dont use that specific application so i dont know how much help I can be. On general observation is that you should remove the version: "3.8" at the top of the file. Compose no longer requires it and actually recommends against calling out a specific compose version in compose files to better support mixing and matching syntax from various version of the compose spec.

I think what you are looking for is the label "net.unraid.docker.webui". You can apply this label to a container created by Portainer (or any other container creation method) and set its value to the url of your container and unRAID will show a WebUi button for the container. There is also a "net.unraid.docker.icon" for setting an icon (url to the icon) and "net.unraid.docker.shell" for setting the shell option (bash for example). Important to note there is a bit of buggy behavior with these labels in that unRAID caches the value and subsequent changes are not reflected in the ui. So essentially you get one shot at setting these things, make sure they are correct before spinning up a container with one (it is possible to wipe the cached value but its not as simple as a page refresh).

Several plugins that include editors are based on https://ace.c9.io/

unRAID has always been a purely home solution and i would never recommend it for business purposes.