Hello everyone, I’m trying to configure Nginx Proxy Manager with Let’s Encrypt on my homelab setup to handle SSL certificates for my Docker applications. I’m running everything on a TrueNAS system and want to assign a specific IP address to the container instead of using the host IP. This worked fine when I set up Pihole, but I’m having trouble getting it to work with NPM. Can someone help me fix my docker compose configuration?
Just dealt with this exact thing last month on my TrueNAS box. Your Docker daemon probably isn’t set up right for macvlan networks on TrueNAS. You need to enable promiscuous mode on your network interface first. SSH into TrueNAS and run ip link set enp0s3 promisc on - swap enp0s3 for whatever your interface is called. Without this, macvlan traffic gets dropped at the hypervisor level. Also check your router settings - some block inter-VLAN communication by default. Once you enable promiscuous mode, your NPM container should grab the custom IP and work properly. I had the same silent failures until I figured this out.
your docker compose is missing the external network declaration. with macvlan, you’ve got to create the network first using docker network create, then reference it as external in your compose file. also, ditch the port mappings - macvlan gives you direct ip access, so those ports are probably causing conflicts.
Your macvlan config looks fine, but I hit a sneaky issue with TrueNAS Docker networking. TrueNAS creates extra bridge networks that mess with macvlan routing. Check if your TrueNAS host can actually reach 192.168.1.5 after the container starts. Here’s the thing - with macvlan, your host can’t talk directly to containers on the same interface unless you set up a dedicated macvlan interface for host communication. I had to create a separate macvlan interface on the TrueNAS host just to manage NPM. Without it, Let’s Encrypt requests from outside work great, but any management tasks from the host fail silently. Test connectivity with a basic nginx container first before adding all the SSL stuff to NPM.
The Problem: You’re trying to configure Nginx Proxy Manager (NPM) with Let’s Encrypt on TrueNAS using Docker Compose and a macvlan network to assign a specific IP address to the NPM container. The setup seems to be failing silently, preventing NPM from functioning correctly.
Understanding the “Why” (The Root Cause):
Using macvlan networks in Docker on TrueNAS can introduce several complexities related to network configuration and IP address management. The macvlan driver assigns a real network interface to the container, bypassing the Docker bridge network. This creates tighter integration with the host’s network, but requires careful attention to IP address allocation, network routing, and potential conflicts with existing network settings (like your router’s DHCP range). A misconfiguration can lead to silent failures, where the container appears to start but doesn’t function properly due to network connectivity problems.
Step-by-Step Guide:
Refine your Docker Compose configuration: The core problem is likely a combination of network configuration issues and an overly broad IP range in your macvlan setup. Here’s how to improve your docker-compose.yml file:
version: "3.8"
services:
proxy-manager:
image: jc21/nginx-proxy-manager:latest
container_name: npm-container
environment:
PUID: 1000
PGID: 1000
# Removed port mappings as macvlan provides direct IP access
networks:
custom_net:
ipv4_address: 192.168.1.5
volumes:
- ./config:/data
- ./ssl:/etc/letsencrypt
restart: always
network_mode: "custom_net" # Added network_mode
networks:
custom_net:
driver: macvlan
driver_opts:
parent: enp0s3
ipam:
config:
- subnet: 192.168.1.0/29 # Significantly reduced IP range
gateway: 192.168.1.1
ip_range: 192.168.1.200/29 # Smaller, dedicated range
Explanation of Changes:
network_mode: "custom_net": This explicitly ties the container to the custom_net macvlan network.
Reduced IP range (192.168.1.0/29 and 192.168.1.200/29): This prevents conflicts with your DHCP server. The /29 subnet provides only 6 usable IP addresses (which is more than enough for one or a small group of containers). Adjust this range based on your needs, ensuring it does not overlap with your router’s DHCP range.
Enable promiscuous mode (if necessary): On your TrueNAS system, access the interface via SSH and run the following command, replacing enp0s3 with your actual interface name. This allows the interface to capture traffic not explicitly addressed to it:
ip link set enp0s3 promisc on
Verify network interface: Use the command ip link show to confirm enp0s3 (or your equivalent interface) is the correct network interface connected to your router.
Check for IP address conflicts: Ensure that 192.168.1.5 is not already in use on your network. Use your router’s administration interface or a network scanner to verify.
Test with a simple container: Before configuring Let’s Encrypt, deploy a basic Nginx container using the same macvlan setup to isolate network issues from NPM-specific problems. If the basic Nginx container can’t access the IP address assigned via macvlan, the problem lies within your TrueNAS/Docker configuration.
Investigate TrueNAS network settings: TrueNAS might create additional bridge networks that interfere with macvlan. Check your TrueNAS networking settings and ensure no routing conflicts are present.
Common Pitfalls & What to Check Next:
DHCP Conflicts: The most frequent issue is overlapping IP addresses between your macvlan range and your router’s DHCP pool. Double-check that your DHCP server isn’t assigning addresses within the range you’ve specified for your macvlan network.
Firewall Rules: Ensure your firewall on both your TrueNAS system and your router allows traffic to and from the assigned IP address (192.168.1.5).
Virtualization: If TrueNAS is running in a virtual machine, the hypervisor might be interfering with macvlan traffic, even with promiscuous mode enabled. Consider using bridge networking as an alternative.
TrueNAS SCALE: If you are using TrueNAS SCALE, its built-in Docker networking might have specific configuration requirements for macvlan networks that are not the same for TrueNAS CORE.
Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!
macvlan’s tricky, but here’s another gotcha - is your TrueNAS on a VM or bare metal? If it’s virtualized, the hypervisor might block macvlan traffic even with promiscuous mode on. Hit this exact issue with Proxmox running TrueNAS. Switched to bridge networking with host mode instead - works way better for npm containers.
This is probably a macvlan network config issue - I ran into the exact same thing setting up NPM on TrueNAS SCALE. Your ip_range covers the whole subnet, which clashes with your router’s DHCP pool. Change it to something tighter like 192.168.1.200/29 so containers only get a small reserved range. Also double-check that 192.168.1.5 isn’t already taken by another device. And make sure enp0s3 is actually your network interface - run ‘ip link show’ in the shell to confirm. Fixed all this stuff and NPM started working great with Let’s Encrypt on my custom IP.
Understanding the “Why” (The Root Cause):
Step-by-Step Guide:
Common Pitfalls & What to Check Next:
Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!