primeval_god

This kind of issue is why docker is the recommended way to add services to unRAID. Is there not a dockerized version of borg?

Under the DockerSetting page in unRAID make sure the "Preserve user defined networks" option is set to yes. After that docker networks created on the command line with "docker network create" will be persistent. A google search should show you how to create an ipvlan type docker network.

How many home users actually have 10G or greater capable networks though?

@Kilrah's answer here is still sounds correct to me. Compose stacks dont seem to work correctly with the brx networks that unRAID provides because they are not persistent. Custom persistent docker networks are recommended. Interesting, are these images off of docker hub or locally built images?

Not a bug but rather misleading documentation. Isolation is for VMs. Pinning if for dockers.

How are you measuring how much memory it is using? Is the number you are seeing purely RAM or RAM+SWAP? Just as I am not clear on why swap limits dont work, I am also not clear on how docker containers interact with swap when limits are not settable. It is possible that even with a memory limit set a container has access to unlimited (except by the amount available on the system) swap space. Another possibility, based on how memory limits without swap limits work when swap limiting is available, is that the container has access to as much swap as its configured memory limit (meaning in your case the container would be able to use 8G RAM + 8G SWAP).

No problem I did not mean to imply offense in my response, just trying to be specific as to where the issue is. The source for this plugin is here https://github.com/dcflachs/swapfile_plugin

I am almost certain that it does, in that the only thing this plugin does is allow the management of a swapfile and enable swap in unraid. Correct, unRAID 6.12 moved to cgroupv2 and for some reason docker is unable to set swap limits using it. I dont know if it is a configuration issue with docker or cgroups, a limitation of the docker version used, or something else. So far as I can tell its not a bug in this plugin. Its also unlikely to be considered a bug in unRAID as support for swap has never been an official feature. If someone knows or can figure out what needs to be changed to restore swap limit support for docker in unRAID 6.12 we can likely get limetech to make a fix. Cgroup stuff however is way above my head.

To my knowledge swapfiles are not supported on the zfs filesystem.

While i still dont have any way to resolve the messages, i think I was wrong about cgroupv2 not having a way to limit swap. I think I misread something saying that I only has global controls for swappiness. That said the issue is still something to do with how docker and cgroupv2 are interacting.

So far as i know swap works just fine on 6.12, the issue is whether or not docker supports limiting swap access to containers. See my answer here.

After startup check your log for messages of the format "Starting compose stack: ${name}". The compose autostart script should log that message for each stack it tries to autostart.

The composeman autostart runs a compose up on each stack. There should be no difference between the Compose Up button and autostart. Regardless i would bet that your diagnosis of the overall problem is correct. My guess is that as @Kilrah is correct that the issue is the br1 network is recreated thus when compose tries to start the existing containers it fails, regardless whether it is via the button or autostart. If i understand your posts above you are doing compose down first then compose up to restart the stack. This makes sense as compose down followed by compose up removes all containers and then recreates them whereas compose up alone would just start existing containers.

The why is that unRAID 6.12.0 uses cgroups v2 which, if i understand correctly, does not have a controller for limiting swap. The memory limit flag trys to limit both available memory and swap space. What I havent been able to decipher is what the resolution should be, whether a version of docker or option in docker resolves it, or if there is something that can be configured in the kernel, or even if there is a resolution at the moment. For the moment I think we have to just ignore it and accept that docker memory limits dont apply to swap (assuming you even have swap enabled on you unRAID host).

Cond is a condition to evaluate to determine if the page should be displayed. Really the only relevant part of my example is the <?php include ?> line. You should be able to include one or more php files regardless of what the header portion of your .page files looks like (header being everything down to the ---).

Also note that your page files need not contain the bulk of your actual plugin code. You can implement the functionality in a php file and include it in one or more page files. Author="dcflachs" Title="Compose" Type="php" Menu="Docker:2" Cond="(pgrep('dockerd')!==false)" --- <?php include '/usr/local/emhttp/plugins/compose.manager/php/compose_manager_main.php';?>

Its close though the use of Syncthing for your offsite is not ideal. Ideally your onsite and offsite backups would be independently versioned. Syncthing will propagate your backup but in the general configuration it will propagate deletes as soon as they happen, meaning if a backup is accidentally deleted from your onsite it will also be deleted from your offsite. Syncthing does have its own basic versioning and deletion protection schemes, but since you indicate you will be backing up a Duplicacy storage there may be some weird overlap in their versioning. Its been a while since i looked at a Duplicacy, but cant it be configured to backup to multiple locations to handle both your onsite and offsite?

The compose interface is already in a tab. You just have to change the "Page View" setting to tabbed in the unRAID display settings.

I am glad it is working for you. I am however not the one to thank. I did not actually write this plugin, I just to over when it was abandoned.

Per BTRFS documentation https://btrfs.readthedocs.io/en/latest/Swapfile.html

I have never used secrets before with docker compose so I doubt i can be of much help. Just in general though I recommend against putting any additional files in the "/boot/config/plugins/compose.manager/projects/*" directories. I recommend putting any additional files for your compose stack somewhere under appdata (though it looks like you call your appdata folder "Docker"). If you must have something placed relative to the compose file, or really want to keep everything together, there is an advanced option when creating a stack that lets you specify the folder location in which to place the compose stack files. Again the recommendation would be under appdata. I dont know if this would have effect on your secrets issue, though maybe it is a permissions issue as the flash drive is fat32 formatted.

I am not sure what you are asking here. Do you mean the path to the compose.manager project folder where the .yml file is? If so it depends on whether or not you specified a non-default directory when creating the stack. If it is the default directory its on the boot drive, but i recommend against placing custom files there. Better to have all your app specific files under your appdata folder and use absolute paths to resources in your compose file. If you are asking about some other path you will have to be more specific.

I also like the second better, but either one looks great!

For autoupdates i would recommend something like Watchtower. Should already be possible by adding cpuset into your compose file.

@ich777 I know this is a fairly trivial complaint but would you consider changing the menu bar button to an icon instead of just text? The current looks like of out of place in the Azure theme.