primeval_god

unRAID is designed for consumer (home) use not commercial use. I would not recommend it for business cases. Not saying rootless containers wouldnt be nice to have though.

No reboot should be necessary but you do have to run Compose Up after making any changes for them to take effect. I dont think it is required but have you tried running Compose Down and then Compose Up to recreate the stack?

The display elements you are referring to are not part of the compose plugin, I dont really know how they work. The "Compose" vs "3rd Party" tag is controlled by the `net.unraid.docker.managed=composeman` label on each container, which should be applied as part of the compose.override.yml file. You can use docker inspect from the cli to check what labels are applied to each container. Can you verify that the compse.override.yml (for each stack) file has the above label set for each container? This is likely something from Docker or Docker Compose (the program not the plugin).

A better option is to use docker, I use a command something like this to extract archives on the unraid command line. This command works in place of 7z x I use docker run --rm --workdir /data -it -v $PWD:/data crazymax/7zip 7z x

This is normal, the reason has been discussed previously in this thread.

Ok that makes sense. Then you really would have to remove and re-add from the saved template.

Recreating a container is easy enough though. Just click the edit button, make and remove a small change (I add and remove a space at the end of the name) so that Dockerman thinks there is something to update, then click apply. Dockerman removes and recreates the container and everything should be correct.

You should not need to remove the template as far as i understand. Just recreate the container using the existing template. Dockerman should apply the correct label on container creation or update. As far as i know its not part of the template just a flag dockerman adds on creation. The issue seems to be that people have containers that have not been recreated or updated since before upgrading.

Interesting, that seems to suggest that its the Dockerman tab that is hanging rather than the compose tab specifically. Does bringing the stack down change the behavior at all? Side note I was not aware that the setting link in CA was wrong. It should lead to the compose plugin setting page rather than the compose page.

Since the introduction of Docker in v6 the recommended way of installing things has been Docker > VM > Plugin. Since the addition of the LXC plugin i would suggest Docker > LXC > VM > Plugin.

Yes i believe this is the issue (I actually mentioned it on another persons post about the same issue). This label is added by dockerman when it creates the container (at least in recent versions). The absence of that label tells dockerman that the container is "Third Party", which mean not managed by Dockerman. Since you updated from 6.9.x your container were likely deployed before dockerman was adding these labels. This could also occur for people who updated from a more recent version if they have a container that has not been redeployed or updated in a very long time (sounds strange but it happens).

Could you provide some screenshots or something? I am not really sure what you are describing, particularly this part " I figured out that I can access the buttons from the tool's own settings page"

If there is not an option to edit them, and no option to update or force update them, then you would need to remove the container and recreate it from its template. I would check that the template exists before removing the container by clicking "Add Container" on the docker screen and looking for the template in the dropdown under user templates. If the template is there it should have all your settings still intact. You should be able to remove the container and then recreate it via "Add Container" and selecting the template.

If there is not an option to edit them, and no option to update or force update them, then you would need to remove the container and recreate it from its template. I would check that the template exists before removing the container by clicking "Add Container" on the docker screen and looking for the template in the dropdown under user templates. If the template is there it should have all your settings still intact. You should be able to remove the container and then recreate it via "Add Container" and selecting the template.

If you are seeing this for containers created via Dockerman/CA that have not been updated or recreated in a long time try recreating the container. The simplest way is to edit the container make a minor change like adding and removing a character in the name and then clicking the apply button. Dockerman now uses a container label which it applies to all the containers it creates to indicate that they are managed by Dockerman and not a third party tool. If your containers have not been recreated in a while they will be missing this label.

The "3rd Party" tag is meant to indicate that a container was created by something other than Dockerman/CA. If these containers havent been recreated in a long time they may be missing the label that Dockerman applies to indicate that it manages them. To fix this try recreating the containers. The easiest way is to, edit the container, make a minor change like adding and then removing a character in the container name, then click apply.

Yes assuming that v7 is released during your 1 year of updates period (which at this point seems extremely likely). See the FAQ section on this page https://unraid.net/pricing for specifics of how the update period works.

Potentially yes. Typically each cable (or connector) on a PSU represents a separate power "rail". While the power supply may total 850w, each rail has a lower limit. Often times the label on the side of the supply will have information of the distribution of power between the rails. I typically spread my drives out between as many drive cables as my psu has available.

Far from it, I dont know exactly but my understanding is that docker uses a subvolume/snapshot per layer for a docker image. Additionally there is at least one writeable subvol created per container instance, plus potentially more if volumes are used.

This is an unfair characterization. unRAID does offer a UI for scrub and balancing, which are the primary btrfs maintaince operations. Snapshots are simply not yet a feature that unraid supports, for any filesystem. At last check this plugin is also the primary method of supporting snapshots for ZFS on unraid as well.

I would prefer to see a way to set a default dashboard layout that could be overridden per browser by cookies.

The script is most likely telling the truth while Qdirstat is not. On btrfs docker uses subvolumes to store the various image layers and container layers (as well as volumes and build cache). What you and others seem to not understand is that subvolumes can share data such that on disk they take up less space than is reported by the sum of the size of the subvolumes. The problem is that tools like Qdirstat, and du dont understand this thus they report total used space as the sum of the size of each subvolume which is greater than the actual used space. One thing you can do to expore this effect is compare the output of the 'du' command to the 'btrfs filesystem du' command.

It looks like you are trying to access compose files from the compose plugin in some other application. This is not recommended. You really should not mess with the files in the compose plugins project directory. If you must access compose files from something else the compose plugin has an option, when creating stacks, to choose a directory in which to store the compose file, that allows you to place it on the array or in a pool rather than on the boot drive. This also separates the compose file itself from the files compose manager uses to manage the stack.

To expand on this a bit for anyone who is new, installing additional packages on the unraid host (regardless of the method) is not recommended. Functionality not built into unraid is meant to be achieved in Docker or a VM, leaving the host os unmodified. While it may feel like added complexity for those used to linux, it serves the purpose of insulating unraids stable core functionality from user applications.