Is anyone using postgres and docker compose/dockge? I have been seeing that postgres reports:

```

2025-06-21 16:11:38.252 UTC [1] LOG: database system is ready to accept connections

2025-06-21 16:32:22.807 UTC [2458] LOG: could not send data to client: Broken pipe

2025-06-21 16:32:22.807 UTC [2458] FATAL: connection to client lost

2025-06-21 16:48:21.805 UTC [4229] LOG: could not send data to client: Broken pipe

2025-06-21 16:48:21.805 UTC [4229] FATAL: connection to client lost

2025-06-21 16:48:33.402 UTC [4237] LOG: could not send data to client: Broken pipe

2025-06-21 16:48:33.402 UTC [4237] FATAL: connection to client lost

2025-06-21 20:51:32.631 UTC [32720] LOG: could not send data to client: Broken pipe

2025-06-21 20:51:32.631 UTC [32720] FATAL: connection to client lost

```

its very intermittent and it happens to all apps, regardless of what stack they are in. I've tried postgres:14-16 and its always the same.

Apps that use the unraid UI for docker don't have this issue. I ran the same compose stacks on an Ubuntu server and they don't have the same disconnect issues.

I'm on Unraid 7.1.4 and using zfs for my cache drive.

not dockge, but yes with immich and Postgres...

This looks like dockge is editing and messing with unraid default docker networks...

you may need to edit some of dockge setting to fix docker networking...

https://www.youtube.com/watch?v=HEklvsr7q54

https://www.youtube.com/watch?v=ephiayS50jM

I would rather point you towards portainer then dockge... as I believe the issue to be dockge...

run

docker network ls
and

docker network inspect

as dockge has to be removing or editing the Postgres network for that kind of log.

some other unraid setting to note that should be set.
Under docker setting preserver user defined networks


and in the compose with Postgres, we can use existing unraid docker networks.

at the end of the compose we can have:

networks:

br0:

external: true

under the service you want to use the default ipvlan/macvlan unraid creates

so...

service:
appname (Postgress)
...

networks:

br0: #set to unraid default custom docker netwroking interface in use (br0, bond0, eth0, etc...)

ipv4_address: 192.168.201.2 # Change this as needed for static IP

this will give it a lan IP

Edited June 22, 20251 yr by bmartino1
data - typo

I don't think its dockge removing or messing with my docker networks. My docker settings look identical to that screenshot. Like I said above, stacks started with docker compose on the command line also have this problem. I use a custom-bridge network I had set up and been using long before I started using dockge or docker compose, and containers on this custom-bridge network started with Unraid's docker UI are fine and don't have disconnects.

services:

speedtest-tracker:

image: lscr.io/linuxserver/speedtest-tracker:latest

restart: unless-stopped

ports:

- 31166:80

environment:

- PUID=99

- PGID=100

- APP_KEY=base64:somekey

- APP_URL=https://speedtest.example.com

- DB_CONNECTION=pgsql

- DB_HOST=speedtest-tracker-db-1

- DB_PORT=5432

- DB_DATABASE=speedtest_tracker

- DB_USERNAME=speedtest_tracker

- DB_PASSWORD=redacted

- SPEEDTEST_SCHEDULE=0 6 1 * *

- SPEEDTEST_SERVERS=48375,13345,62875,63281,16089

- DISPLAY_TIMEZONE=America/Chicago

- PRUNE_RESULTS_OLDER_THAN=0

volumes:

- /mnt/user/appdata/speedtest-tracker:/config

depends_on:

db:

condition: service_healthy

networks:

- custom-bridge

db:

image: postgres:17

restart: always

environment:

- POSTGRES_DB=speedtest_tracker

- POSTGRES_USER=speedtest_tracker

- POSTGRES_PASSWORD=redacted

volumes:

- /mnt/user/appdata/postgres-speedtest-tracker:/var/lib/postgresql/data

healthcheck:

test:

- CMD-SHELL

- pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}

interval: 5s

retries: 5

timeout: 5s

networks:

- custom-bridge

networks:

custom-bridge:

external: true

This is an example of one I have tested in docker compose and dockge, both have the same issue.

then let the docker compose make the docker bridge and test and try it.

Docker Compose Yaml File Syntax

#version: "3.9"

services:

speedtest-tracker:

image: lscr.io/linuxserver/speedtest-tracker:latest

restart: unless-stopped

ports:

- 31166:80

environment:

- PUID=99

- PGID=100

- APP_KEY=base64:somekey

- APP_URL=https://speedtest.example.com

- DB_CONNECTION=pgsql

- DB_HOST=speedtest-tracker-db-1

- DB_PORT=5432

- DB_DATABASE=speedtest_tracker

- DB_USERNAME=speedtest_tracker

- DB_PASSWORD=redacted

- SPEEDTEST_SCHEDULE=0 6 1 * *

- SPEEDTEST_SERVERS=48375,13345,62875,63281,16089

- DISPLAY_TIMEZONE=America/Chicago

- PRUNE_RESULTS_OLDER_THAN=0

volumes:

- /mnt/user/appdata/speedtest-tracker:/config

depends_on:

db:

condition: service_healthy

networks:

custom-bridge:

ipv4_address: 172.25.0.10

aliases:

- speedtest-tracker

dns:

- 8.8.8.8

db:

image: postgres:17

restart: always

environment:

- POSTGRES_DB=speedtest_tracker

- POSTGRES_USER=speedtest_tracker

- POSTGRES_PASSWORD=redacted

volumes:

- /mnt/user/appdata/postgres-speedtest-tracker:/var/lib/postgresql/data

healthcheck:

test: ["CMD-SHELL", "pg_isready -U speedtest_tracker -d speedtest_tracker"]

interval: 5s

retries: 5

timeout: 5s

networks:

custom-bridge:

ipv4_address: 172.25.0.11

aliases:

- speedtest-tracker-db-1

dns:

- 8.8.8.8

networks:

custom-bridge:

driver: bridge

ipam:

config:

- subnet: 172.25.0.0/24

name: compose-custom-bridge

1. Uses a custom bridge network named compose-custom-bridge.

2. Assigns static IPs within the 172.25.x.x subnet.

3. Sets Google's 8.8.8.8 as the DNS server.

4. Be sure to Fix any indentation and YAML structure issues.

This way the docker compose makes the docker bridge network and removes it when docker compose down is done...

You may also benfit form lables for unraid icons and other side data.

docker-compose.yaml

Edited June 22, 20251 yr by bmartino1
data - typo

as it looks like your trying to capture data for speediest. Might I recommend a done compose that doesn't use Postgres.

https://forums.unraid.net/topic/163308-docker-netprobe

https://github.com/bmartino1/netprobe_lite

I just used speedtest-tracker as an example. I will be running the following tests:

A stack in dockge with:
networks:
default:

driver: bridge
this should have the containers communicate over that dockge created network

A stack in dockge with:

networks:

default

this should have the containers communicate over that dockge created network (not specifying bridge)

A stack in dockge with:
networks:

custom-bridge:

external: true
this uses my existing custom-bridge network I have been using since I created my unraid server

A stack started with docker compose up -d with:
networks:

default:

driver: bridge
this should have the containers communicate over that docker compose managed network

A stack started with docker compose up -d with:
networks:

custom-bridge:

external: true

this uses my existing custom-bridge network I have been using since I created my unraid server

custom-bridge is just a regular bridge network, nothing really special about it.

I will report back tomorrow after some time has passed and which ones experience issues with their postgres databases

Edited June 23, 20251 yr by nate34k

All of the above solutions today resulted in postgres Broken pipes and also:
2025-06-23 8:03:12 22517 [Warning] Aborted connection 22517 to db: 'romm' user: 'romm' host: '172.18.0.64' (Got timeout reading communication packets).

At this point I'm inclined to think that something in Unraid isn't playing nice with docker compose, since the absence of dockge in the later tests rules that out.
Running docker network ls shows all my networks still there, docker network ls <network_name> shows my networks still have their containers in them.

again I would need the output of the docker inspect, ls and daig file... can't asist with out data...

Docker network ls

NETWORK ID     NAME                                   DRIVER    SCOPE
12570bacbf58   br0                                    macvlan   local
48f611645be0   br0.50                                 macvlan   local
ce517a6a1224   bridge                                 bridge    local
38b60f37fb6b   custom-bridge                          bridge    local
16be98f3fb41   host                                   host      local
1dd159f3167a   none                                   null      local
85bc16055cc2   sonarr-docker-compose_sonarr_network   bridge    local
789245a4d4a6   speedtest-tracker_default              bridge    local

Docker network inspect sonarr-docker-compose_sonarr_network

[
    {
        "Name": "sonarr-docker-compose_sonarr_network",
        "Id": "85bc16055cc27ab2d8bca79d7c5816657b78acf4859cec0d16e1df70dd06e59f",
        "Created": "2025-06-22T19:58:10.856284301-05:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.19.0.0/16",
                    "Gateway": "172.19.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "2841825e2bd2aeef1671d498b9d07230da9191322558851df3332f1a63d5a1d4": {
                "Name": "sonarr-docker-compose-compose-1",
                "EndpointID": "467d32aae6f35bcc2dbd9aa0c58f500f3f82c2455a1903e2a1c1ed0aa915dd15",
                "MacAddress": "02:42:ac:13:00:03",
                "IPv4Address": "172.19.0.3/16",
                "IPv6Address": ""
            },
            "604e7c820d4c507a29225d29ad2bed4d1a8201eedcf309625d084e0e6a7a9868": {
                "Name": "sonarr-docker-compose-db-1",
                "EndpointID": "0c38f36843e1d0ec6829cf8c3bc85c4752544a0b509f779b95b141e6bebfdb10",
                "MacAddress": "02:42:ac:13:00:02",
                "IPv4Address": "172.19.0.2/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {
            "com.docker.compose.config-hash": "545b8c7258cb7aaee791f9b8f199c6fa0d542e17306d614ac4f457d278e1c0c2",
            "com.docker.compose.network": "sonarr_network",
            "com.docker.compose.project": "sonarr-docker-compose",
            "com.docker.compose.version": "2.35.1"
        }
    }
]

If you want more docker network inspect commands let me know, specifically the customs bridge network one is quite lengthy as its has most of my containers attached to it.

Edit: docker network inspect custom-bridge (most containers omitted)

[
    {
        "Name": "custom-bridge",
        "Id": "38b60f37fb6b90341804985e3bc2cf9f0af0429b4bad706316ee34dcd512d910",
        "Created": "2025-02-05T19:41:02.254764931-06:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "00953874ea2989e2edddf31c973352d975a1aca4e5361e31ab6ea475f795a726": {
                "Name": "code-server",
                "EndpointID": "14279560453a8b39019fe4035c3f12f4b497189fdd2fdbfa8192223e91da18fd",
                "MacAddress": "02:42:ac:12:00:27",
                "IPv4Address": "172.18.0.39/16",
                "IPv6Address": ""
            },
            "1266c3db5874be5d72b89dc2760032eea799e1b75215120ce93690ba23fa4159": {
                "Name": "dashdot",
                "EndpointID": "b48fc04228bccd19efe4cc125d032f39bb3e7c94fd83dd985cd2048a7c4d6b3b",
                "MacAddress": "02:42:ac:12:00:36",
                "IPv4Address": "172.18.0.54/16",
                "IPv6Address": ""
            }
        "Options": {},
        "Labels": {}
    }
]

yggdrasil-diagnostics-20250623-1706.zip

Edited June 23, 20251 yr by nate34k

Thank you For posting the Diag File... It appears that the vlan and macvlan is breaking your shim-bridge to connect to the network for other dockers...

yeah. macvlan and vlan related docker networking troubles...

You're likely experiencing PostgreSQL disconnects due to macvlan-related instability in Docker on Unraid, especially when using multiple macvlan bridge networks (br0, br0.50, etc.). Here's what the logs are showing...

Docker Containers Flapping / Disconnecting:

-Multiple containers on macvlan and bridge networks enter disabled states rapidly:

syslog / syslog-previous per diag..

Example:

port 2(vethXXXX) entered disabled state

vethXXXX (unregistering): left promiscuous mode

...

entered disabled state

*These are classic signs of network interface issues—veth pairs flapping on bridge networks... as they are starting and stoping and other netowrking misconfigurations...

Custom Docker Compose Networks:

Many containers have "additional networks" restored (e.g., custom-bridge, br0.50, immich_default, etc.) indicating multiple overlay/bridge networks managed by Docker Compose, likely creating network contention or namespace confusion

Macvlan Shim Interfaces

• You're using shim-br0 and shim-br0.50 via macvlan mode bridge, which is notoriously unstable when the host also talks to containers on the same subnet (common Unraid issue)

• it should be shaing and using 1 shim brdige not both.

Since your using Vlans, THis is a unraid netwroking misconfioguration and not one easliy diagnsted adn fixed...

Theoyr / Root Cause Hypothesis

Macvlan conflict or bridging instability is causing PostgreSQL containers to intermittently lose connectivity, especially when:

• Unraid's host (e.g., 192.168.1.5) tries to communicate with macvlan containers on the same subnet.

• Docker Compose creates overlapping or conflicting bridges.

• Docker's default isolation and veth pairs hit race conditions when rapidly restarting containers.

Unless you absoulte need macvlan (As I prefer to use macvlan myself)...

Some Fix Recomendations...
Fix Recommendations:

Avoid Host-Container Same Subnet Macvlan

Use ipvlan mode instead of macvlan if staying that route...

-Or use a separate subnet for container networks (e.g., 192.168.100.x) to isolate traffic.
so vlan 50 is subnet traffic of 50.x ....

Use Docker Bridge for Internal Services

• If your PostgreSQL is only used by other containers, prefer bridge or custom-bridge networks.

• Avoid putting DB containers on br0.

Add Static Delay to DB Startup

• Add depends_on + restart_policy in docker-compose.yml:

depends_on:

- postgres

restart: always

Reduce Simultaneous Network Restoration

• When containers come up at once, many veth changes occur. Try starting essential services first (like DB), then use docker-compose up for the rest.

Debug Further with Logs

• Look for PostgreSQL container logs (docker logs) for connection reset, timeout, or terminated messages to align with syslog entries.

A tracking comand to see the postgress disconect when flaged...
watch -n 1 "brctl show; docker network inspect <postgres-network>"

or pull form syslog:

tail -f /var/log/syslog | grep veth

When symptoms occur...

But every sign is point to mis linux network configuration and how you have br0.55 createde and working making breaks wiht the underline shim docker birdge on how unriad functions...

The Web UI only affects br0 / eth0 based on unraid documentation...

https://www.youtube.com/watch?v=0xk7LsWwp2I
https://www.youtube.com/watch?v=9Ta9e09KyYw

Your docker networks needs fixing...

I will try removing vlan 50 and disabling vlans and by consequence any containers that were using the br0.50 docker network will be swapped to custom-bridge. I will report back to see if this helps.

Edit: I'd like to ask for clarification, do you mean macvlan docker network in general is the likely issue, or having a vlan (and as a result two macvlan docker networks)

Edited June 24, 20251 yr by nate34k

The steps did not solve the issue, containers are still getting disconnected when started by docker compose.

From a sonarr container started by docker compose:

2025-06-24 00:32:10.477 UTC [1] LOG:  database system is ready to accept connections
2025-06-24 08:40:48.125 UTC [56125] LOG:  could not send data to client: Broken pipe
2025-06-24 08:40:48.131 UTC [56125] FATAL:  connection to client lost
2025-06-24 08:40:56.466 UTC [56133] LOG:  could not send data to client: Broken pipe
2025-06-24 08:40:56.466 UTC [56133] FATAL:  connection to client lost
2025-06-24 09:04:13.836 UTC [58844] LOG:  could not send data to client: Broken pipe
2025-06-24 09:04:13.836 UTC [58844] FATAL:  connection to client lost
2025-06-24 09:04:22.765 UTC [58854] LOG:  could not send data to client: Broken pipe
2025-06-24 09:04:22.765 UTC [58854] FATAL:  connection to client lost

Logs from postgres container started in Unraid UI (in CDT, time overlaps with above)

2025-06-24 03:42:30.725 CDT [27] LOG:  checkpoint starting: time
2025-06-24 03:42:31.606 CDT [27] LOG:  checkpoint complete: wrote 9 buffers (0.1%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.831 s, sync=0.024 s, total=0.881 s; sync files=7, longest=0.008 s, average=0.004 s; distance=20 kB, estimate=67 kB
2025-06-24 03:47:30.706 CDT [27] LOG:  checkpoint starting: time
2025-06-24 03:47:31.465 CDT [27] LOG:  checkpoint complete: wrote 9 buffers (0.1%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.717 s, sync=0.017 s, total=0.759 s; sync files=7, longest=0.004 s, average=0.003 s; distance=20 kB, estimate=62 kB
2025-06-24 03:52:30.565 CDT [27] LOG:  checkpoint starting: time
2025-06-24 03:52:31.325 CDT [27] LOG:  checkpoint complete: wrote 8 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.713 s, sync=0.025 s, total=0.760 s; sync files=7, longest=0.008 s, average=0.004 s; distance=22 kB, estimate=58 kB
2025-06-24 03:57:30.361 CDT [27] LOG:  checkpoint starting: time
2025-06-24 03:57:31.110 CDT [27] LOG:  checkpoint complete: wrote 8 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.716 s, sync=0.013 s, total=0.749 s; sync files=7, longest=0.004 s, average=0.002 s; distance=19 kB, estimate=54 kB
2025-06-24 04:02:30.197 CDT [27] LOG:  checkpoint starting: time
2025-06-24 04:02:30.958 CDT [27] LOG:  checkpoint complete: wrote 8 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.713 s, sync=0.036 s, total=0.762 s; sync files=7, longest=0.008 s, average=0.006 s; distance=14 kB, estimate=50 kB
2025-06-24 04:07:31.058 CDT [27] LOG:  checkpoint starting: time
2025-06-24 04:07:32.000 CDT [27] LOG:  checkpoint complete: wrote 10 buffers (0.1%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.912 s, sync=0.018 s, total=0.942 s; sync files=9, longest=0.003 s, average=0.002 s; distance=28 kB, estimate=48 kB

Output of current docker network ls:

NETWORK ID     NAME                                   DRIVER    SCOPE
12570bacbf58   br0                                    macvlan   local
131ea3336acc   bridge                                 bridge    local
38b60f37fb6b   custom-bridge                          bridge    local
16be98f3fb41   host                                   host      local
1dd159f3167a   none                                   null      local
85bc16055cc2   sonarr-docker-compose_sonarr_network   bridge    local
789245a4d4a6   speedtest-tracker_default              bridge    local

I have provided a new diagnostic file as I made network changes for this test. Also please keep in mind that the container logs are in UTC, and my syslog may be in CDT.

yggdrasil-diagnostics-20250624-0636.zip

Edited June 24, 20251 yr by nate34k

My Honest advice and step by step would be to clear the unraid networking config reboot and start fresh with Unraids default networking.
Before Beginning make sure you have a flash backup.
Main > Flash > Flash backup. This can be used to restore...

Before following these steps be sure to write down any static IPs and have the user script plugin installed as there bay be some scripts used there latter...

Following these steps will completely restart the unraid networking and bring it back to DHCP at first configurations.

Delete the docker network database of docker network configurations. (Also found in the docker disk image.)

rm /var/lib/docker/network/files/local-kv.db

--If docker is off / disabled it may still exisit do this be for diableing docker...

Since we are messing with internal networks. Turn off. LXC/Docker/VMS
Settings Docker Enabled no, VM Manger enabled No.... etc
With the sytem prepred we are ready to proceed with the steps.

Step one is tell the USB to recreate Unraids Default Network. simalr to first inintal configuration.

Reset unraid docker network to guarantee default configurations.

cd /boot/config

rm network*

reboot

this reset unraids to factory default network configurations.

Reboot server!

After a reboot, go to Settings → Network Settings in the Unraid web UI and resetup your static ip if at all...

This Way I can guarantee that 0 previous configuration is to blame...

Now with a the unraid defaults you should have bonding off bridging on and eth0 connected to your lan subnet
*At this time DO NOT DO ANY OTHER CONFIGURATION OUTSIDE OF STATIC IP ASSIGNMENT TO ETH0!

We first need to get the networking stuff set and squared away and working. Then you can futz with vlan and other interfaces settings...

Next lets go to the VM Settings.

Make sure the Default Network Source is NOT VMBIR! it should be set to br0. This affect how the shim bridge is made and some internal cross talk for VMs.
*While Rare, this has also broken docker communications.

Next to Docker settings. (I would honestly recommened deleting the vdisk file. And starting fresh!
-This will clear out the previous Docker Tab all Docker template settings are still on the Flash Drive and Mapped Data is Saved to the Disks

I recommend creating a XFS Docker Vdisk Image. Depends on How You handle your storage and where the system vdisk image is located at. More info in the Release notes...

*This has also rarely caused docker issues.(While Your Diag and other docker issues don't necessarily point to its a recommend change for the future.)

Here we want to make sure that you are enabling Host access to custom networks. and Preserver user defined

(Host access networks is what's making the shim-bridge and ip duplication, which may be problematic and the next step to check and change)

-We want this enabled for lan access to the docker networks...

Next we need to add and run a few user scripts

1. will set the shim bridge to another static ip on the sub lan through eth0

2 will set and make sure unraids system ctl forwarding is enabled and working.

Both scripts will need to run at first array start. as after setting these setting We will reboot once more. (Especially after a deleting of the docker vdisk file.) Which is required to move forward and make sure all of your networking is default!

Script 1:
https://forums.unraid.net/topic/178033-bmartino1-user-scripts/#findComment-1492333

as macvlan and enable host may cause a duplate IP preventing traffic... to fix we treat the interface like a service taht needs its own static IP
check first with ip a

#!/bin/bash
# Reset and configure vhost0 was in v6 v7 may still see vhost but new config its called shim-br interface

ip link set shim-br0 down
# Bring vhost0 down

ip addr flush dev shim-br0
# Remove any existing IPs

#use static IP?:
ip addr add 192.168.x.x/24 dev shim-br0
# Assign the desired IP

ip link set shim-br0 up       
# Bring vhost0 up

at Use Static IP be sure to set an avilable ip address ...

-This will move the other side of the shim bridge to a static IP. By default it will attempt to bridge against br0 with the static IP set to eth0. UNraid esentail takes the eth0 and forms the br0 interface then docker tries to do the same with resutles with 2 interfaces with teh same IP. (This can cause netowrking equipment to fail as it done't know how to talk or cros into unraid.)

More noticable on Unifi Equipment. as seen in teh forum post...

Script 2:

By default Unriad dsibalbe some form of ip forwarding that can prevent docker services and cross talk

#!/bin/bash

# Delay before starting

sleep 10

# Apply sysctl settings

apply_sysctl_settings() {

echo "Applying sysctl settings..."

sysctl -w net.ipv6.conf.all.forwarding=1

sysctl -w net.ipv6.conf.br0.accept_ra=2

sysctl -w net.ipv6.conf.br0.accept_ra_rt_info_max_plen=64

sysctl -w vm.overcommit_memory=1

echo "Verifying sysctl settings..."

sysctl net.ipv6.conf.all.forwarding

sysctl net.ipv6.conf.br0.accept_ra

sysctl net.ipv6.conf.br0.accept_ra_rt_info_max_plen

sysctl vm.overcommit_memory

}

apply_sysctl_settings

This script will apply ipv6 forwarding that is disabled by default. Unraid requires a SLAC with RA enabled to properly handle and see ipv6 witch can also case some internal comunciation issues. ipv4 is already enabled by default. note the br0 acept ra make sure your vlan is added latter...
system control -p

sysctl -p to see all of unraid system control settings...


Reboot the system make sure teh docker vidsk is xfs and created and running, make sure the script have ran...

then lets make a immich docker that hsa postgress that we can follow for testing. somethign I know that has postgress and will function as I'm not sure what your doing that breakign things to this level...

https://forums.unraid.net/topic/190532-guide-immich-docker-setup-docker-compose

chose your pathing I will set a defulat for immich:

I Have to Assume Unraid Default Pathing for the Guide:

mkdir -p /mnt/user/appdata/immich/{config,database/postgres,database/redis,libaries,photos}

/mnt/user/appdata/immich/config/

/mnt/user/appdata/immich/database/postgres/

/mnt/user/appdata/immich/database/redis/

/mnt/user/appdata/immich/libaries/

/mnt/user/appdata/immich/photos/

immich docker compose: https://forums.unraid.net/applications/core/interface/file/attachment.php?id=356591&key=7415fa48ec42d836a47bd783ac65eae8

immich env file: https://forums.unraid.net/applications/core/interface/file/attachment.php?id=356590&key=91c510657d4217e22bb37c785f724dec

compose up and run immich and wait 1 hour or so and check docker logs. AS THIS SHOULD BE YOUR ONLY DOCKERS RUNNING AT THIS TIME!

If it stays up Great restor your Other dockers coreting any issue along the way...

This si the only way I can gurantee that 1 its not unraid, and 2 its non of the uraid gatcha on how your tying to run something...

Now I get this error trying to start any docker containers

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

I followed steps exactly up until I had to start immich

Edited June 25, 20251 yr by nate34k

reboot unraid and verify that docekr is running...

cd /etc/rc.d/

root@Tower:/etc/rc.d# ls

rc.0@ rc.apcupsd* rc.crond* rc.inetd* rc.local_shutdown* rc.ntpd* rc.serial* rc.wireguard*

rc.4* rc.atd* rc.dnsmasq rc.ip_forward* rc.loop* rc.openldap rc.setterm* rc.wireless*

rc.4.local* rc.avahidaemon* rc.docker* rc.kadmind rc.mcelog* rc.php-fpm* rc.smartd rc.wsdd2*

rc.6* rc.avahidnsconfd* rc.elogind* rc.keymap* rc.messagebus* rc.ptpd* rc.sshd* rc0.d@

rc.K* rc.bind rc.flash_backup* rc.kpropd rc.modules* rc.rpc* rc.swapfile@ rc6.d/

rc.M* rc.cgconfig rc.font rc.krb5kdc rc.modules.local* rc.rsyslogd* rc.sysstat

rc.S* rc.cgred rc.inet1* rc.library.source rc.mysqld rc.runlog rc.sysvinit*

rc.S.cont* rc.cgroup2unraid* rc.inet1.conf rc.libvirt* rc.nfsd* rc.samba* rc.udev*

rc.acpid* rc.cpufreq* rc.inet2* rc.local* rc.nginx* rc.saslauthd rc.unraid-api*

root@Tower:/etc/rc.d#

./rc.docker status

if you have something else running, a go script/user script?, other docker or side applicaiton then thats what failed...
-You can disable the netowkr change for testing as this can cause the docker system to stop if your not corret at touching the corect interface...
as this will fix shim bridge...

woudl need ip a to see what interfaces chagned adn configmred....

I Curently need and would like you to cd into /etc/rc.d folder as this is all of unraid servce sripts... and verify that docker is indeed running

./rc.docker restart

./rc.docker stop

./rc.docker start

and then post a unraid diag file. as the instruction above are explicit and don't result in unraid borken nor docker error, unless you fubar your docker xfs storage at disk creation...
another reboot may alos be needed as soem setting wont' load corectly after edits...

As syslog would have more information here to what failed where.

as what we did:

we removed the old docker database (removed docker networkis...)

stoped/disabled docker/VM to not interfere with settings.

we killed unraid configuration to start fress
a reboot and fresh start was setup
we killed and delted teh vdisk file
a new vidsk image was made
a reboot again?

script were setup


not enoth info to further assist.

also make sure the docekr vdisk file is stored corretly.

usualy the system share:





as it should only be set to primary and only set to 1 disk.

I apologize, I have two NICs and one of them has 4 ports, so unraid defaulted to bond on eth0-3. I wanted to get 10G on eth5 so I tried to configure it differently but in the end just redid the steps and configured it instead of bond - > no I set bond - > yes on eth0 and eth5.

I guess docker doesn't work if you don't use eth0 at all? Not sure, but its back up...

XFS docker image

Only stack running is immich and my reverse proxy.

ok that would make sense and yes bond is recomend in that situation.

as previous though ther is mutiple configuration networking that needs setup to acomidate this.

Correct unraid webUI will only affect br0 and eth0 depengin on settings. more on how you direct bridgin and waht interfaes are llistening to hte br0

as teh defualt docker shim bridge is set to target br0

it more telling what is br0 assocatied with

However we have liunx commadns taht can make and edit ad bridges as noted with the script above to change the ip address of the shim bridge.

if postgress is functional and immgich web ui is working / postgress is not disconecting then we can now proced with network layout and configurations.


as you have 10 GB and a 4port nic

what interfcae is conected to what and how do you want them to connect to your network.
what do you want it to do and how do you want to interact with it.

I apologize for the lack of updates. I am slowly restarting docker services with docker compose up -d and through the GUI. So far everything is stable, no disconnect errors. I am just taking time in case it was a specific app/service I was running in docker that was potentially causing it.

I have a 4 port 1G NIC and a 2 port 10G NIC, I only use eth5 with is the 10G NIC. eth0 and eth5 are in bond0 with bridging on.
VMs are set to br0, and containers that require it (so far traefik and qbittorrent) are using the macvlan br0 with ipv4_address set. All other containers use a bridge network.

No other services at this time are planned to go on the docker macvlan br0 network, they will all run through bridge networks either created by docker compose (eg. immich_bridge or sonarr_bridge) or the one I created (custom-bridge).

If it continues to be stable in this configuration for a few days, I will enable a few more of my services and wait to see if its stable at that point. Rinse and repeat until they are all back online.

If you want another diagnostic or any docker commands ran to verify stability, let me know.

No not other data is needed atm, Your seem to be back in a stable networking setup. If you encounter an error let us know, we will glady assist where we can.

I assume you were testing Vlans or some form of network separation. Now that you at least know and have a configuration that is stable and you can revert / default back too.

More on adding and setting up vlans.

https://www.youtube.com/watch?v=9Ta9e09KyYw

https://www.youtube.com/watch?v=0xk7LsWwp2I

and network docker isolation:
https://www.youtube.com/watch?v=LyeywgTOxHk

Spoke to soon. The immich postgresql didn't disconnect, but the sonarr and authentik postgresql containers did multiple times. I tried reconnecting the authentik instance to the postgres container started by Unraid in the webUI and no such disconnects occur while the sonarr postgresql containers started by compose do still experience disconnects. This is clearly a problem specifically with docker compose on unraid, since we reset networking and I deleted my docker image and set it to xfs. The same exact compose on an Ubuntu server 24.04 doesn't experience these problems.

Edited June 28, 20251 yr by nate34k

the ars network really should be in its own docker bridge.

docker network create \
  --driver=bridge \
  --subnet=172.42.0.0/16 \
  --gateway=172.42.0.1 \
  ars_stack

Breakdown:

• --driver=bridge: This specifies the type of network. The default type is bridge, which allows containers to communicate with each other and the host system.

• --subnet=172.42.0.0/16: This defines the range of IP addresses in the subnet. The /16 gives you a large range (172.42.0.1 to 172.42.255.254).

• --gateway=172.42.0.1: This sets the gateway for the network, which is typically the first IP in the subnet.

• ars_stack: This is the name you're giving to the network.

Place all the *ars dockers in this bridge so they can talk to each other...

I did. The arrs are in their own bridge network.

3 hours ago, nate34k said:

Spoke to soon. The immich postgresql didn't disconnect, but the sonarr and authentik postgresql containers did multiple times. I tried reconnecting the authentik instance to the postgres container started by Unraid in the webUI and no such disconnects occur while the sonarr postgresql containers started by compose do still experience disconnects. This is clearly a problem specifically with docker compose on unraid, since we reset networking and I deleted my docker image and set it to xfs. The same exact compose on an Ubuntu server 24.04 doesn't experience these problems.

this soulds like cross talk between 2 different docker netowrks.

so unless the postgress database is in teh same docker bridege or set to its own lan IP with custom ip it won't be able to talk to somethign else int eh docker bridge.

teh docker brdige uses router esk NAT and docker sget a 172.x.x.x address and are acessble via NAT rules form there docker brdge via the host.

theus a docker like posgeree in unrads default bridge or host will not be able to cros the netowrk without forming some ip route and inter network cros talk...

what docker netowrk do you have for ars and what is the docker networkg for the postgress docker?

psotgress should be at its own custom IP, based on what your telling me.