I have it all:

 

services:
  pihole:
    container_name: pihole
    networks:
      br0:
        ipv4_address: 192.168.x.x
 #   dns:
 #    - 192.168.x.x
    image: pihole/pihole:latest
    environment:
      TZ: Europe/Berlin
      PIHOLE_UID: 99
      PIHOLE_GID: 100
    volumes:
      - /xxx:/etc/pihole
    cap_add:
      # Required if you are using Pi-hole as your DHCP server, else not needed
      - NET_ADMIN
    restart: unless-stopped
networks:
  br0:
    external: true

 

 

The error still occurs. Only when I activate/deactivate the DNS entry in the config, for example, is the container started.

52 minutes ago, kleiner-onliner said:

I have it all:

 

services:
  pihole:
    container_name: pihole
    networks:
      br0:
        ipv4_address: 192.168.x.x
 #   dns:
 #    - 192.168.x.x
    image: pihole/pihole:latest
    environment:
      TZ: Europe/Berlin
      PIHOLE_UID: 99
      PIHOLE_GID: 100
    volumes:
      - /xxx:/etc/pihole
    cap_add:
      # Required if you are using Pi-hole as your DHCP server, else not needed
      - NET_ADMIN
    restart: unless-stopped
networks:
  br0:
    external: true

 

 

The error still occurs. Only when I activate/deactivate the DNS entry in the config, for example, is the container started.

whats your docekr settings, unraid network settings... and what does a docker tempate say your network is?

network settings:

Docker settings:

 

Docker template settings:

 

as you may be using bond not br0 or, you may be using eth0
...

what is the output of
 

docker network ls

Quote

root@Docker:~# docker network ls
NETWORK ID     NAME      DRIVER    SCOPE
b89bb41f3b5e   br0       macvlan   local
e1e8ac828c93   bridge    bridge    local
510d58fd7962   host      host      local
400b7aa1f2f6   none      null      local
root@Docker:~# 
 

Note the name br0 that is the name of the docker network I need to call in the compose file... not enouth info to assist...

1 hour ago, kleiner-onliner said:

The error still occurs. Only when I activate/deactivate the DNS entry in the config, for example, is the container started.

On each boot Unraid creates a new br0 so it'll have a different ID. The existing container still references the old one so won't start without doing a compose down/compose up to associate the new network with the same name.

 

There's a trick to create your own macvlan/ipvlan network instead of using the system-provided one and to set Docker to preserve custom networks, should be somewhere in this thread.

9 minutes ago, Kilrah said:

On each boot Unraid creates a new br0 so it'll have a different ID. The existing container still references the old one so won't start without doing a compose down/compose up to associate the new network with the same name.

 

There's a trick to create your own macvlan/ipvlan network instead of using the system-provided one and to set Docker to preserve custom networks, should be somewhere in this thread.

ids don't matter I reboot all the time and don't have a issue you need to call it by the docker name...

The problem actually only occurs after restarting the Docker service. I am currently using Unraid 7.1.0-beta.2.
I have already tested it with eth0 instead of br0. I get the same error message here too. I have also tested various network and docker settings. Here is the latest version:

 

 

 

 

 

I don't use Docker templates because I only use my own compose files.

 

Creating my own macvlan seems to be the only solution, unfortunately.

9 hours ago, Kilrah said:

On each boot Unraid creates a new br0 so it'll have a different ID. The existing container still references the old one so won't start without doing a compose down/compose up to associate the new network with the same name.

 

There's a trick to create your own macvlan/ipvlan network instead of using the system-provided one and to set Docker to preserve custom networks, should be somewhere in this thread.

 

But the compse file does not contain any information about an ID. It only contains the name of the network... Where is the information stored?

42 minutes ago, kleiner-onliner said:

 

But the compse file does not contain any information about an ID. It only contains the name of the network... Where is the information stored?

Within the Docker system, when the container is created Docker looks up the name you gave to find the network ID and that's what it stores as the container network. But when the service is stopped/restarted the default br0 is recreated as a new network so the ID changes.

 

Try turning on "Preserve user-defined networks" for a start but IIRC that's not enough.

Edited March 31, 20251 yr by Kilrah

Found it:

 

 

Thanks Kilrah, it works perfectly now. Thanks for the quick help and the search in the thread.

I have a woodpecker stack consisting of two containers. autostart=false, yet one of the containers - the agent - is started on unraid startup.
 

# cat woodpecker/autostart
false

# cat woodpecker/docker-compose.yml
services:
  woodpecker-server:
    container_name: woodpecker-server
    image: woodpeckerci/woodpecker-server:v3
    ports:
      - 8003:8000
    volumes:
      - /mnt/user/appdata/woodpecker/server:/var/lib/woodpecker/
    environment:
      - WOODPECKER_HOST=https://woodpecker.myserver.eu
      // other app env vars...
    networks:
      - main1

  woodpecker-agent:
    container_name: woodpecker-agent
    image: woodpeckerci/woodpecker-agent:v3
    command: agent
    restart: always
    depends_on:
      - woodpecker-server
    volumes:
      - /mnt/user/appdata/woodpecker/agent:/etc/woodpecker
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - WOODPECKER_SERVER=woodpecker-server:9000
      // other app env vars...
    networks:
      - main1

networks:
  main1:
    name: main
    external: true  # use pre-existing network

 

docker confirms there was no attempt to start the server:

# docker ps --all | grep woodp
5f943419146d   .../woodpecker-agent:v3  ...  30 hours ago    Up 7 seconds (health: starting)
bf936cadc804   .../woodpecker-server:v3  ... 30 hours ago    Exited (0) 4 hours ago

 

---

Why does the plugin try to start the agent?

Edited April 4, 20251 yr by tuxbass

5 hours ago, tuxbass said:

I have a woodpecker stack consisting of two containers. autostart=false, yet one of the containers - the agent - is started on unraid startup.
 

# cat woodpecker/autostart
false

# cat woodpecker/docker-compose.yml
services:
  woodpecker-server:
    container_name: woodpecker-server
    image: woodpeckerci/woodpecker-server:v3
    ports:
      - 8003:8000
    volumes:
      - /mnt/user/appdata/woodpecker/server:/var/lib/woodpecker/
    environment:
      - WOODPECKER_HOST=https://woodpecker.myserver.eu
      // other app env vars...
    networks:
      - main1

  woodpecker-agent:
    container_name: woodpecker-agent
    image: woodpeckerci/woodpecker-agent:v3
    command: agent
    restart: always
    depends_on:
      - woodpecker-server
    volumes:
      - /mnt/user/appdata/woodpecker/agent:/etc/woodpecker
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - WOODPECKER_SERVER=woodpecker-server:9000
      // other app env vars...
    networks:
      - main1

networks:
  main1:
    name: main
    external: true  # use pre-existing network

 

docker confirms there was no attempt to start the server:

# docker ps --all | grep woodp
5f943419146d   .../woodpecker-agent:v3  ...  30 hours ago    Up 7 seconds (health: starting)
bf936cadc804   .../woodpecker-server:v3  ... 30 hours ago    Exited (0) 4 hours ago

 

---

Why does the plugin try to start the agent?

 

Quote

# cat woodpecker/autostart false

-Means noting its using compose version 2...
Doesn't apear to be pasgin this... is not being read as teh plugin called compose -d from how the orgianl compose was ran...

?Do you have the autostart toggles?


its starting as you have a policy restart always
restart: always

review:

https://docs.docker.com/reference/cli/docker/compose/restart/

 

Quote

To use restart policies, Docker provides the following options:

no: Containers won’t restart automatically.

on-failure[:max-retries]: Restart the container if it exits with a non-zero exit code, and provide a maximum number of attempts for the Docker daemon to restart the container.

always: Always restart the container if it stops.

unless-stopped: Always restart the container unless it was stopped arbitrarily, or by the Docker daemon.

 

10 hours ago, bmartino1 said:

its starting as you have a policy restart always
restart: always

My understanding was that property is only used by docker and wouldn't be in effect unless the plugin calls `compose up -d / compose start`, which is enabled by the toggle (which I have on the compose tab like on your screenshot). Is there plugin source available to see what it's doing?

Edited April 4, 20251 yr by tuxbass

4 hours ago, tuxbass said:

My understanding was that property is only used by docker and wouldn't be in effect unless the plugin calls `compose up -d / compose start`, which is enabled by the toggle (which I have on the compose tab like on your screenshot). Is there plugin source available to see what it's doing?

I think its this:

https://github.com/dcflachs?tab=repositories

As this may be @primeval_god repo for github and some projects for unraid.

 

You would need to find the source files behind the plugin...

CA pulls from this github for the plugin repo

https://github.com/dcflachs/compose_plugin

 

and review the emhttp php web data and script to figure out what's its doing:
example:
https://github.com/dcflachs/compose_plugin/blob/main/source/compose.manager/scripts/compose.sh
https://github.com/dcflachs/compose_plugin/blob/main/source/compose.manager/Compose.page

 

You could view the data on unraid as well...
 

cd /usr/local/emhttp/plugins/compose.manager/php/

 

Can't say I'm intimately familiar with unraid plugin architecture, but this bit suggests my guess was correct.

First and foremost, thank you so very much for this plugin, it has been exactly what I've needed since I moved to Unraid. Now that I've learned more about it I've decided to install compose directly instead of the plugin. I'm posting this incase others should want to do the same. 

 

mkdir -p /usr/local/lib/docker/cli-plugins

curl -SL https://github.com/docker/compose/releases/download/v2.34.0/docker-compose-linux-x86_64 -o /usr/local/lib/docker/cli-plugins/docker-compose

 

This installs compose in the same directory that the plugin does and can now be updated more frequently if needed. It is also installed for all users.

3 minutes ago, brecon1 said:

mkdir -p /usr/local/lib/docker/cli-plugins

This path is in RAM and won't survive reboot. The plugin no doubt recreates this at boot when it is reinstalled.

3 minutes ago, trurl said:

This path is in RAM and won't survive reboot. The plugin no doubt recreates this at boot when it is reinstalled.

ARGH!!!! I haven't rebooted yet so wouldn't have guessed. THANK YOU!!!

 

So if I ran both the mkdir command and the curl from my previous post in a script at reboot I should be ok?

2 minutes ago, brecon1 said:

ARGH!!!! I haven't rebooted yet so wouldn't have guessed. THANK YOU!!!

 

So if I ran both the mkdir command and the curl from my previous post in a script at reboot I should be ok?

User Scripts plugin can run a script at first array start.

8 minutes ago, trurl said:

User Scripts plugin can run a script at first array start.

Perfect! I did just that so we'll see how it goes at my next reboot. 

 

THANK YOU!!!!

On 4/4/2025 at 12:23 PM, tuxbass said:

My understanding was that property is only used by docker and wouldn't be in effect unless the plugin calls `compose up -d / compose start`, which is enabled by the toggle (which I have on the compose tab like on your screenshot). Is there plugin source available to see what it's doing?

You are correct the restart:always option is for compose while the compose plugin only acts based on the value in the "autostart" file. The autostart file is updated based on the state of the autostart toggle for the stack on the compose page. 

To determine if the compose plugin is responsible for starting this stack you should enable the "Debug Logging" option in the compose plugin settings. Then next time you reboot you can look in your system log for messages from the compose plugin. It should log a message for each stack it tries to start.

I run a script to down then up each of my stacks in the order I want at array start. It works great:

 

https://gist.github.com/mtongnz/f3ca13c7ff8472e54bbb7ff8cec265e1

 

This script also means I can add custom buttons into Folder View for each folder... I have each stack in it's own folder and a button for update, restart, down and up. Very handy

For anyone else pulling their hair out trying to figure out how to properly schedule things with compose stacks created by this plugin, I found this to work pretty well:

COMPOSE_PROJECT_DIR=/boot/config/plugins/compose.manager/projects/bw-export
docker compose --project-directory "${COMPOSE_PROJECT_DIR}" --project-name "$(sed -E 's/[\.\s\-]/_/g' ${COMPOSE_PROJECT_DIR}/name || true)" up --pull always --wait

 

I noticed the sanitize function in https://github.com/dcflachs/compose_plugin/blob/main/source/compose.manager/php/util.php replaces dots, dashes, and spaces with underscores, and as long as you set the project directory and project name correctly you can use pretty basic docker compose commands and be fully compatible with the plugin.

 

I have the above in a user script scheduled to run daily because the one and only container in that stack exits once it finishes running (it only takes a few seconds to complete) and I want it to run once per day automatically.

 

This pattern could easily be adapted to loop through multiple projects (ex: auto detect any projects in the /boot/config/plugins/compose.manager/projects folder) or use other compose commands like down, pull, etc.

 

@primeval_god if you happen to see this, you might take note that the commands above are NOT adding a ton of arguments to specify the compose file, override, env, etc. It's really just the project directory and project name that's needed. The project name actually wouldn't be needed at all because compose names projects using the folder if you don't specify otherwise, but to keep the above compatible with what you've got in your repo it's needed. The code in your repo might be able to be simplified with that in mind. The compose CLI automatically knows what to do with the compose file, override file, and env file (because you happen to have them named the way compose expects, which is perfect) and you can omit the project name since compose will auto-generate that. In the case above my project name (if auto-generated) would be bw-export (with a dash) instead of how the plugin names it bw_export (with an underscore). Anyway the project name is hardly the important part. Not having all the file arguments really cleans it up.

Here's an example of finding any project that is set to autostart true and running compose up with pull (update) and wait until the containers are reporting healthy before detaching (running in the background so the script can consider itself finished running):

 

find /boot/config/plugins/compose.manager/projects -type f -name autostart -exec grep -l "true" {} + | while read -r autostart; do
    docker compose --project-directory "$(dirname "${autostart}")" --project-name "$(sed -E 's/[\.\s\-]/_/g' "$(basename "${autostart}")/name" || true)" up --pull always --wait
    echo "Successfully started $(sed -E 's/[\.\s\-]/_/g' "$(basename "${autostart}")/name" || true)"
done

 

Could run on a schedule or when array starts. Could be modified to do other things pretty easily.

Edited April 9, 20251 yr by iXNyNe

1 hour ago, iXNyNe said:

@primeval_god if you happen to see this, you might take note that the commands above are NOT adding a ton of arguments to specify the compose file, override, env, etc. It's really just the project directory and project name that's needed. The project name actually wouldn't be needed at all because compose names projects using the folder if you don't specify otherwise, but to keep the above compatible with what you've got in your repo it's needed. The code in your repo might be able to be simplified with that in mind. The compose CLI automatically knows what to do with the compose file, override file, and env file (because you happen to have them named the way compose expects, which is perfect) and you can omit the project name since compose will auto-generate that. In the case above my project name (if auto-generated) would be bw-export (with a dash) instead of how the plugin names it bw_export (with an underscore). Anyway the project name is hardly the important part. Not having all the file arguments really cleans it up.

What you may have missed is that the plugin has an option that allows the user to store the stack files in a directory other than the default projects directory. In that case the override and env files are not stored in the same directory as the main compose file. 

9 minutes ago, primeval_god said:

What you may have missed is that the plugin has an option that allows the user to store the stack files in a directory other than the default projects directory. In that case the override and env files are not stored in the same directory as the main compose file. 

I did indeed miss that. Is there a reason that the override and env files could not be kept together with the compose file? I see there is an option to specify the path to the env file, but if left blank it does seem to be stored in the stack folder. It also looks like there is a file named "indirect" that contains the stack folder, so that actually simplifies things quite a bit (the loop example I posted above could easily be updated to check for and use the indirect file if it exists). it could also easily read the compose.manager.cfg to find the default PROJECTS_FOLDER. So really all I'm suggesting is to keep the override file in the stack folder, which would allow simplified calls to the docker compose CLI (fewer arguments).