Samsonight

This is standard Docker Compose v2 naming rather than anything the plugin does — but there's an important catch about fixing it that's worth adding. Compose names a container after its service's container_name: if set; otherwise it falls back to <project>-<service>-<n>, where <project> is the stack/project name and the trailing -1 is the replica ordinal Compose always appends. That's why your first container is clean — that service has an explicit container_name: (it happens to match the stack name) — while services 2 and 3 don't, so they get the <stack>-<service>-1 form. It's purely cosmetic; containers still reach each other by service name regardless. The fix is to add container_name: to the other services: services: app: container_name: app db: container_name: app-db cache: container_name: app-cache The catch: adding container_name: to a stack that's already running will NOT rename the existing containers on a normal restart — or even on a Compose Update / force-recreate. Compose identifies an existing container by its internal labels (project + service), not by its name, so it keeps the old name when it recreates in place. To actually apply the new names you have to do a full Compose Down, then Compose Up, so the containers are removed and created fresh. One more thing worth checking if a name ever looks "wrong" despite your file being correct: confirm which file actually created the container. docker inspect <container> --format '{{index .Config.Labels "com.docker.compose.project.config_files"}}' shows the exact compose file it came from. If that points somewhere other than the file you're editing (for example a stray docker-compose.yml sitting in a build-context directory), that other file is what's really launching the stack — and that mismatch, not the plugin, is the cause.

@Cino hardly, with it the compose manager actually becomes functional and compatible ❤️But your human agent clearly hasn't thought about what are the biggest adoption thresholds for both the plug-in and Unraid, letting both drift behind the alternatives. I find it mesmerising someone complains about a fully stand-alone supplementary functionality (poc) boosting the plug-in itself (include it, its free), there is no competition, it is the first thing users run into trying to get even the most rudimentary compose to lift. Please don't follow Unraid in their cargo culting, if containers was implemented properly we wouldn't need to build plugins like this to begin with. 🤠

Enables you to spin up services like SeaFile (App, Redis, SQL) or Discourse (App, Redis, SQL), or even Wazuh (Manager, Indexer, Dashboard) in a single compose file, not having to worry about dependencies, updates or anything else. compose-to-containernet v2026.06.03aConverts custom Docker networks to network_mode: container: (shared network namespace) Auto-detects main service (most ports + most dependencies) Rewrites service hostname references to 127.0.0.1 in environment variables and URLs Adds depends_on: service_started for correct startup ordering Parameterizes images, volumes, and ports with ${VAR:-default} (override via .env, works without one) Moves stray ports from supporting services to the main service Flags mounted config files and external env files for manual hostname review Detects port conflicts between services sharing a namespace Preserves original values as # was: comments Skips services that already have network_mode set Validates output is valid YAML before writing

IF... one where to ALSO automate conversion (even optionally) to produce hints and starting point examples of any existing compose file needed... in the spirit of lowering adoption threshold... Usage: python3 compose-to-containernet.py <compose-file.yml> — only needs PyYAML. The test suite is self-contained, anyone can clone: for f in tests/*.yml; do python3 compose-to-containernet.py "$f"; doneto see the output for themselves. (as used in the previous example section) compose-to-containernet.py

Converting Docker Compose custom networks to container networking on UnraidThe problemMost Docker Compose files use custom networks so containers can talk to each other by name (e.g., app calls db instead of an IP address). On normal Linux, this just works. On Unraid, custom networks are a headache: Unraid's Docker UI doesn't know about them They don't survive reboots unless you hack the go file Containers on custom networks sometimes can't reach the host or LAN The Compose Manager plugin creates/destroys them, but Unraid's native Docker tab gets confused The solution: container networkingInstead of giving containers their own private network, you stack them into one container's network — exactly like how VPN containers (Gluetun) already work on Unraid. (there are other implementations but they are just made by people stuck in the non-containerized mutable old ways). Docker DocumentationNetworking overviewLearn how networking works from the container's point of viewThe conversion recipe:Pick the "main" container — the one users actually connect to (the web UI, the app). This one gets normal bridge networking and port mappings. For every other container in the stack replace: networks: - mynetwork with: network_mode: container:main-container-name Change hostnames to localhost — since all containers now share one network namespace: replace: DB_HOST=db REDIS_HOST=redis with: DB_HOST=127.0.0.1 REDIS_HOST=127.0.0.1 Delete the networks: block at the bottom of the compose file entirely. Move all port mappings to the main container — since only it owns the network, only it can expose ports. What breaks and how to fix itTwo containers bind the same internal port: Reconfigure one to use a different port via env var Startup order matters (DB must be up before app): Most apps retry on their own; compose depends_on still works Main container restarts: Supporting containers briefly lose networking, reconnect automatically What you can't convertStacks where containers need separate IPs (macvlan, multiple web servers each needing port 80) — rare in homelab Multi-stack communication (reverse proxy in stack A needs to reach app in stack B) — use host ports instead Network segmentation (frontend can't reach database) — nobody does this at home That's itFor 95% of compose stacks on Unraid (Seafile, Immich, Paperless, Nextcloud, any app + database + cache combo), the conversion is: pick the main container, attach everything else to it, change hostnames to 127.0.0.1, delete the networks block. Five minutes of editing, zero custom network problems. Example# Converted to container networking (main: app) # Supporting services share network via: network_mode: container:app # # === CHANGES MADE === # [app] DB_HOST=db # -> DB_HOST=127.0.0.1 # [app] REDIS_URL=redis://cache:6379 # -> REDIS_URL=redis://127.0.0.1:6379 # services: app: image: myapp:latest ports: - 8080:80 environment: # was: DB_HOST=db - DB_HOST=127.0.0.1 # was: REDIS_URL=redis://cache:6379 - REDIS_URL=redis://127.0.0.1:6379 depends_on: - db - cache db: image: mariadb:10.11 environment: - MYSQL_ROOT_PASSWORD=secret volumes: - /mnt/user/appdata/myapp/db:/var/lib/mysql # was: networks: [custom] -- converted to container networking network_mode: container:app cache: image: redis:7 volumes: - /mnt/user/appdata/myapp/redis:/data # was: networks: [custom] -- converted to container networking network_mode: container:app

Mesmerising default reasoning given in the blacklisting... instead of actually notifying that the old plugin is deprecated they sabotage the new plugin with obscure "App "Compose Manager Plus (Beta)" is blacklisted: Blacklisted application" instead of something more clear like "temporarily blocked due to template inconsistencies".

How is shutdown supposed work when the container hijacks the usb port from Unraid? Presumably maybe by becoming a client to Nutify, but then when the container isn't running there is no UPS protection (hence plugins vs containers).

I'm certain Limetech is already tracking an issue from 2022, would be nice to know where though. This forum section literally says: "Issues with enabling the Docker service on Unraid." Try entering "accept_ra" in the https://product.unraid.net/b/unraid-os-bugs search box and it returns results not containing the string "accept_ra", I'll leave that windmill for someone else. And other users wont be searching there as during years of unraid use I've never crossed paths with that site before even by mistake. <3 Or to rephrase it, other threads with the same root cause: 1. Docker IPv6 issues on 7.0.1 (https://forums.unraid.net/topic/188533-docker-ipv6-issues-on-701/ ) — VLAN + SLAAC, IPv6 not working in Docker 2. Docker IPv6 with static address issue (https://forums.unraid.net/bug-reports/stable-releases/docker-ipv6-with-static-address-issue-r3832/) (bug report, May 2025) — accept_ra workaround in comments 3. IPv4+IPv6 breaks sharing for Windows clients (https://forums.unraid.net/topic/189378-ipv4-ipv6-for-unraid-network-interface-breaks-sharing-for-some-windows-clients/) — same sysctl workaround 4. SOLVED: Host access to custom networks no longer works (7.1.0) (https://forums.unraid.net/topic/189927-solved-710-host-access-to-custom-networks-no-longer-works/) — same accept_ra/forwarding sysctl 5. Macvlan: different behavior in Portainer vs native Unraid (https://forums.unraid.net/topic/189797-macvlan-problem-different-behavior-in-portainer-and-native-unraid/) — same workaround 6. Containers started with docker compose disconnecting (https://forums.unraid.net/topic/191376-containers-started-with-docker-compose-disconnecting/) — rc.docker restart as workaround 7. IPv6 RA inside UnRAID VM not accepted (https://forums.unraid.net/topic/138717-ipv6-ra-inside-unraid-vm-not-accepted/) (2023, 6.11.5) — earliest thread, accept_ra=2 in VMs 8. Matter x Docker doesn't work (https://forums.unraid.net/topic/182404-matter-x-docker-doesnt-work/) — IPv6/Thread broken, same root cause 9. 6.12.3: Why is IPv6 disabled on Docker network br0? (https://forums.unraid.net/topic/143280-6123-why-ipv6-is-disabled-on-my-docker-network-custom-network-br0/) — enableIpv6: false on br0 10. 6.12.3: Docker ignores IPv6 addresses (https://forums.unraid.net/bug-reports/stable-releases/6123-docker-ignores-ipv6-addresses-r2586/) (bug report) 11. just curious... broadcast address in config (https://forums.unraid.net/topic/194077-just-curious-why-isnt-there-any-broadcast-address-in-the-config/) — bmartino1 debugging accept_ra/forwarding interaction with rc.docker 12. bmartino1's workaround scripts (https://forums.unraid.net/topic/185359-bmartino1-workaround-scripts-updated/) — "Why not the go file? It's too early in the boot process" — same timing issue you identified 13. Unraid with Matter Thread and UniFi IPv6 issues (https://forums.unraid.net/topic/166559-unraid-with-matter-thread-and-unifi-ipv6-connectivity-issues/page/2/) — accept_ra=2 workaround in comments 14. Getting IPv6 working in Docker Containers (https://forums.unraid.net/topic/88239-getting-ipv6-working-in-docker-containers/) — MikroTik + SLAAC + Docker, earliest comprehensive attempt @bmartino1 @CraziFuzzy @ken-ji

Update: Two More Root Causes Found (MLD Snooping + rc.docker Bugs)Since the original post about accept_ra=2 fixing RA acceptance when Docker sets forwarding=1, I've found two additional root causes that can independently break IPv6 on Unraid servers. Both are triggered by the same underlying event (Docker enabling IPv6 forwarding on br0), but they manifest differently. Cause 2: Managed Switch MLD Snooping Filters IPv6 MulticastThis one is subtle and took a while to track down. Even with accept_ra=2 set, the server may still lose IPv6 because Router Advertisements never reach it at the Ethernet level. When Docker sets net.ipv6.conf.br0.forwarding=1, the kernel treats br0 as a router interface. Per RFC 2710 Section 5, routers do NOT send MLD (Multicast Listener Discovery) reports — they're expected to already know about multicast groups. There is no sysctl override for this behavior (unlike accept_ra=2 which overrides RA acceptance for forwarding interfaces). If your server is connected to a managed switch with IGMP/MLD snooping enabled, the switch sees no MLD reports from the server's port. After the membership ages out, the switch stops forwarding IPv6 multicast (including RAs sent to ff02::1) to that port. Key observation: IPv4 multicast still works fine. IGMP is independent of IPv6 forwarding state, and RFC 4541 Section 2.1.2 exempts 224.0.0.0/24 (including mDNS at 224.0.0.251) from IGMP snooping. So you'll see mDNS working while IPv6 is completely dead — a misleading symptom. How to confirm # On the server — you'll see zero IPv6 packets arriving: tcpdump -i br0 -n icmp6 # Meanwhile IPv4 multicast (mDNS) works fine: tcpdump -i br0 -n udp port 5353 The fix Disable IGMP/MLD snooping on the managed switch, at least for the VLAN carrying the server's traffic. Important: Per-port "unknown multicast flood" settings do NOT help when a multicast querier is active on the network. Once a switch detects a querier, it restricts unknown multicast forwarding to querier ports only — this is documented behavior in the IGMP/MLD snooping specs. Who is affected Anyone running Unraid behind a managed switch (any vendor) with MLD snooping enabled. Consumer/unmanaged switches flood all multicast by default, so they're not affected. Cause 3: Three IPv6 Bugs in rc.dockerThis is completely separate from the kernel/network-level issues above. Even if your RAs arrive correctly and accept_ra=2 is set, the Docker custom network for br0 can still end up without working IPv6 due to bugs in /etc/rc.d/rc.docker. Bug 1: Timing race — IPv6 address detectionAround line 463: IPV6=$(ip -6 -br addr show scope global primary -deprecated dev $NETWORK | awk '{print $3;exit}')Docker starts early in the boot process. On SLAAC networks, br0 won't have a global IPv6 address until it receives a Router Advertisement and completes DAD (Duplicate Address Detection) — typically 1-4 seconds after the interface comes up. If Docker starts before this completes, $IPV6 is empty, the network is created IPv4-only, and it's never updated later. Suggested fix: Either wait for a global IPv6 address (with timeout), or defer the IPv6 network configuration: # Wait up to 10 seconds for SLAAC to complete for i in $(seq 1 20); do IPV6=$(ip -6 -br addr show scope global primary -deprecated dev $NETWORK | awk '{print $3;exit}') [[ -n $IPV6 ]] && break sleep 0.5 done Bug 2: Link-local gateway discarded Bug 2: Link-local gateway unusable Two locations — around line 466 and line 519: # Line ~466: gateway is collected as fe80::... GATEWAY6=$(ip -6 route show to default dev $NETWORK | awk '{print $3;exit}')and # Line ~519: fe80 is explicitly rejected [[ -n $GATEWAY6 && ${GATEWAY6:0:4} != fe80 ]] && GATEWAY6="--gateway=$GATEWAY6" || GATEWAY6= On SLAAC networks (which is the vast majority of IPv6 deployments), the default gateway is always a link-local address (fe80::...). This is correct per RFC 4861. The line 519 conditional drops it, so containers get no IPv6 default route. However, simply removing the fe80 check at line 519 does NOT work — Docker itself rejects link-local gateways with "no matching subnet for gateway". The gateway must be a global address within one of the configured subnets. Suggested fix: After collecting the gateway, resolve the link-local address to the router's global address via the NDP neighbor table (same MAC, router flag): # After line ~466: GATEWAY6=$(ip -6 route show to default dev $NETWORK | awk '{print $3;exit}') # Resolve fe80 gateway to router's global address (Docker rejects link-local) if [[ -n $GATEWAY6 && ${GATEWAY6:0:4} == fe80 ]]; then _RMAC=$(ip -6 neigh show dev $NETWORK $GATEWAY6 2>/dev/null | awk '{print $5}') if [[ -n $_RMAC ]]; then GLOBAL=$(ip -6 neigh show dev $NETWORK | awk -v mac="$RMAC" '$0 ~ mac && $1 !~ /^fe80/ && /router/ {print $1; exit}') [[ -n $_GLOBAL ]] && GATEWAY6=$_GLOBAL fi fi# Line ~519: remove the now-unnecessary fe80 rejection [[ -n $GATEWAY6 ]] && GATEWAY6="--gateway=$GATEWAY6" || GATEWAY6=This works because the router's link-local and global addresses share the same MAC in the NDP table. The router flag confirms it's the correct neighbor entry. Bug 3: Duplicate subnets from ip -6 routeAround line 465: SUBNET6=$(ip -6 route show dev $NETWORK | sort | awk -v ORS=" " '$1 !~ /^(default|fe80)/ {print $1}' | sed 's/ $//')ip -6 route show returns each prefix twice — once as proto kernel (from the address assignment) and once as proto ra (from the Router Advertisement). This script doesn't deduplicate them, so docker network create receives duplicate --subnet flags and fails silently. Suggested fix: Add deduplication: SUBNET6=$(ip -6 route show dev $NETWORK | awk '$1 !~ /^(default|fe80)/ {print $1}' | sort -u | awk -v ORS=" " '{print}' | sed 's/ $//') All three are independently capable of breaking IPv6. A complete fix requires addressing all that apply to your setup. Root causes 1 and 2 affect everyone using Docker with IPv6; root cause 3 only matters if you use Docker custom networks with the br0 ipvlan setup.

Hey all, I spent tonight debugging why my Gluetun VPN containers refused to start after an array restart with an IPv6 error, even though IPv6 was working perfectly an hour before. Turns out this is the same underlying bug that's been biting people for years across different Unraid versions, and I think the root cause deserves its own clear explanation because the existing threads dance around it without nailing it down. The symptomAfter any array restart (or reboot), IPv6 stops working. Containers that need IPv6 fail. VMs lose their IPv6 addresses or connectivity. Matter/Thread devices go offline. The host has no IPv6 default route even though your router is advertising one correctly. The root cause, as simply as I can put it When Docker starts, it enables IPv6 packet forwarding on the host: net.ipv6.conf.all.forwarding = 1 This is a Linux kernel-level thing — Docker needs it so containers can route traffic. The problem is that the Linux kernel treats any host with forwarding=1 as a router, and routers don't listen to Router Advertisements from other routers. So the kernel silently stops accepting RAs on all interfaces, which means your IPv6 default route (learned from your gateway via RA) disappears and never comes back. You can verify this yourself: sysctl net.ipv6.conf.br0.accept_raIf it shows 0, that's your problem. Why it worked before the rebootTiming. If Docker was already running when you first configured IPv6, the existing RA-learned route might have still been in the routing table. It just doesn't survive a restart because the startup sequence goes: network comes up → RA installs default route → Docker starts → forwarding=1 kills RA acceptance → route expires → never renewed. Why Unraid's rc.docker doesn't catch thisrc.docker actually does check for an IPv6 default route before deciding whether to start Docker with --ipv6: if [[ -n $(ip -6 route show to default dev $PORT) ]]; then DOCKER_OPTS="--ipv6 --fixed-cidr-v6=$DOCKER0 $DOCKER_OPTS" But this creates a chicken-and-egg problem. The route exists when Docker starts, so Docker gets --ipv6. Then Docker enables forwarding, which kills the route. Next reboot, the route might not be there in time, so Docker starts without --ipv6, and now the Docker bridge network doesn't have IPv6 either. How this cascades to GluetunIf you run Gluetun (https://github.com/qdm12/gluetun) with dual-stack WireGuard (both IPv4 and IPv6 in WIREGUARD_ADDRESSES), this bites extra hard. Gluetun checks IPv6 support at startup by looking at the routing table inside its container namespace. If the Docker network doesn't have IPv6 (because rc.docker didn't see a default route and skipped --ipv6), Gluetun finds no IPv6 routes and refuses to start: ERROR VPN settings: Wireguard settings: interface address is IPv6 but IPv6 is not supported: address 2a07:b944::2:2/128This is logged as "IPv6 is not supported after searching N routes" — it's not a Gluetun bug, it's just reporting what it sees. Any container using Gluetun's network namespace (qbittorrent, prowlarr, etc.) then also fails to start because the network namespace doesn't exist. Related Gluetun issues: - #1597 — interface address is IPv6 but IPv6 is not supported (https://github.com/qdm12/gluetun/issues/1597) (May 2023) - #2713 — IPv6 suddenly no longer working (https://github.com/qdm12/gluetun/issues/2713) (Feb 2025) The fixOne line in /boot/config/go: sysctl -w net.ipv6.conf.br0.accept_ra=2accept_ra=2 means "accept Router Advertisements even when forwarding is enabled." This is the standard Linux fix for any host that needs to both forward packets and receive RAs — which is exactly what an Unraid box running Docker is. This is a known upstream Docker bugThis was reported to Docker in March 2022: docker/for-linux#1373 (https://github.com/docker/for-linux/issues/1373) — "Docker sets forward=1 but not accept_ra=2 when enabling IPv6." Still not fixed as of today. Unraid threads about the same underlying issue- IPv6 RA inside UnRAID VM not accepted (https://forums.unraid.net/topic/138717-ipv6-ra-inside-unraid-vm-not-accepted/) (May 2023, Unraid 6.11.5) - Docker IPv6 issues on 7.0.1 (https://forums.unraid.net/topic/188533-docker-ipv6-issues-on-701/) (June 2025) - The state of ipv6 in unRaid's docker (https://forums.unraid.net/topic/193868-the-state-of-ipv6-in-unraids-docker/) (October 2025) - [7.2.0] ipv6 networking to VMs no longer functional (https://forums.unraid.net/bug-reports/stable-releases/720-ipv6-networking-to-vms-no-longer-functional-r4136/) (2026) The 7.2.1 fix ("load br_netfilter and set IPv6 FORWARD policy to ACCEPT") addresses the ip6tables side of things, but not the RA acceptance problem. They're related but separate issues. Suggestion for LimeTechCould rc.docker add sysctl -w net.ipv6.conf.$PORT.accept_ra=2 right after enabling IPv6 forwarding? That would fix this for everyone without needing manual go file edits. It's a one-liner and it's what every other Docker-on-Linux guide recommends. Running Unraid 7.2.5 / OPNsense gateway with SLAAC / Gluetun WireGuard dual-stack.

Keeps giving https://github.com/docker/for-linux/issues/1373

For clarity the 6 series ran for 10 years so the "promise" (in v7.x) was within the next 10 years or so, meaning releasing it by 2035 would be holding it...

Maybe a status update, hardly any code survives two years without patching and major version changes...