🚀 Executive Summary
TL;DR: Installing Immich with Docker inside a Debian LXC often causes network loss due to subnet conflicts between Docker’s bridge and the LXC’s network. The primary solution involves configuring Docker’s daemon.json to use a non-conflicting IP range, or for persistent issues, migrating the application to a dedicated KVM VM for better isolation.
🎯 Key Takeaways
- Nested Docker within an LXC can lead to network conflicts, specifically when Docker’s default `docker0` bridge subnet (`172.17.0.0/16`) overlaps with the LXC’s assigned IP range.
- To permanently resolve Docker-LXC network conflicts, configure Docker’s `daemon.json` with a custom `bip` and `default-address-pools` to ensure Docker operates on a distinct subnet.
- For complex applications like Immich, if `daemon.json` fixes are insufficient, migrating from an LXC to a full KVM Virtual Machine provides superior network isolation and native Docker compatibility, albeit with higher overhead.
When your Debian LXC goes dark after an Immich install, it’s usually because Docker’s default bridge is fighting your container’s network interface for dominance. Learn how to resolve IP conflicts and restore your Samba shares without nuking your setup.
When Immich Nukes Your Network: Rescuing Debian LXCs from the Docker Bridge Abyss
I’ve been there. It’s 11:00 PM on a Friday, you finally decide to self-host Immich to get your photos off the big-tech cloud, and you run that docker-compose up -d. Suddenly, your terminal freezes. You try to ping prod-media-01, and nothing. Silence. You haven’t just lost Immich; you’ve lost the whole container, your Samba shares, and your sanity. At TechResolve, we call this the “Docker-LXC Nesting Tax.” You tried to do something simple, and Docker decided it owned your entire network stack.
The “Why”: What Actually Happened?
The root of this headache is almost always a subnet conflict. When Docker starts up, it creates a virtual bridge (usually docker0). If the default subnet Docker picks (often 172.17.0.0/16) overlaps with your local network or the internal IP assigned to your LXC by Proxmox, the routing table gets confused. Your packets try to leave the container, hit the Docker bridge, and get swallowed into a black hole. Furthermore, Docker loves to mess with iptables, which can be particularly disastrous inside the restricted environment of an unprivileged LXC.
Pro Tip: Docker and LXC are like two alpha wolves in one small cage. LXC is already a form of containerization; running Docker inside it (nested) requires clear boundaries, or they will fight over the routing table.
Solution 1: The Quick Fix (The “Jolt”)
If you can still get into the Proxmox console (the web GUI shell), you can often force the network back up by manually cycling the interface and clearing the rogue routes. It’s hacky, but it gets your Samba shares back online instantly.
# Drop the docker interface temporarily
ip link set docker0 down
# Check your routing table for the conflict
ip route show
# Restart the primary networking service
systemctl restart networkingSolution 2: The Permanent Fix (The “Diplomat”)
To stop this from happening every time the container reboots, we need to tell Docker exactly which IP range it is allowed to use. We do this by editing the daemon.json file. This prevents Docker from “guessing” a subnet that conflicts with your home network or your Samba mount points.
Create or edit /etc/docker/daemon.json:
{
"bip": "10.200.0.1/24",
"default-address-pools": [
{
"base": "10.201.0.0/16",
"size": 24
}
]
}After saving, restart Docker. This forces Immich and its sidecars to live in the 10.200.x.x range, leaving your primary 192.168.x.x (or whatever your LAN uses) alone.
Solution 3: The ‘Nuclear’ Option (The “Clean Slate”)
If you’ve tried the above and your networking is still brittle, it’s time to admit that LXC might be the wrong tool for this specific job. Immich is a heavy application with many moving parts (PostgreSQL, Redis, Machine Learning models). Moving the installation to a full KVM Virtual Machine (VM) instead of an LXC gives Docker its own dedicated kernel and hardware virtualization.
| Feature | LXC (Current) | VM (The Nuclear Fix) |
| Network Isolation | Shared with Host | Fully Virtualized |
| Docker Compatibility | Finchy / Needs Nesting | Native / Perfect |
| Overhead | Low | Medium |
In my experience, if daemon.json doesn’t fix it, you’ll spend more time debugging nftables than you will actually enjoying your photo gallery. Back up your Immich upload folder, spin up a clean Debian VM, and use a dedicated bridge. Your Samba shares will thank you.
Warning: Before moving to a VM, ensure your Proxmox host has enough RAM. Immich’s machine learning features can be thirsty, and a VM doesn’t share memory as efficiently as an LXC.
🤖 Frequently Asked Questions
❓ Why did my Debian LXC lose network access after installing Immich with Docker?
Your LXC likely lost network access due to a subnet conflict where Docker’s default `docker0` bridge (e.g., `172.17.0.0/16`) overlaps with your LXC’s network, causing routing table confusion and `iptables` issues.
❓ How does running Docker in an LXC compare to running it in a KVM VM for applications like Immich?
Running Docker in an LXC offers lower overhead but shares the host kernel and network, leading to potential conflicts. A KVM VM provides full network isolation and native Docker compatibility with its own kernel, making it more robust for heavy applications like Immich, despite higher resource overhead.
❓ What is a common implementation pitfall when running Docker inside an LXC, and how can it be avoided?
A common pitfall is Docker’s default bridge (`docker0`) creating a subnet conflict with the LXC’s network, leading to routing issues. This can be avoided by explicitly defining Docker’s IP range in `/etc/docker/daemon.json` using `bip` and `default-address-pools` to prevent overlap.
Leave a Reply