Critical Network Failure in Docker Containers with Exposed Ports
Posted: 07 Dec 2025, 07:19
Subject: Critical Network Failure in Docker Containers with Exposed Ports on TOS 4.2.44
Hardware: TerraMaster F4-220
TOS Version: 4.2.44
Docker Version: 20.10.17
Problem Description:
It is impossible to access ports exposed by Docker containers (launched via both docker-compose and docker run) when these containers also use bridge networks or mount volumes from the NAS's filesystem. Connections to these ports result in a timeout (ERR_CONNECTION_TIMED_OUT), even though the containers are shown as active (Up) and the system firewall (iptables) is explicitly configured to allow the traffic.
Summary of the Debugging Process and Key Findings:
An exhaustive diagnostic process was carried out to isolate the root cause of the issue. The results demonstrate anomalous and contradictory behavior in the Docker networking layer on TOS.
Initial Setup: An attempt was made to launch an Nginx and n8n stack using docker-compose. Nginx was configured as a reverse proxy for n8n, exposing ports 8090 (HTTP) and 8443 (HTTPS).
Result: Timeout.
Firewall Diagnostics (iptables): It was discovered that the INPUT chain in iptables redirects traffic to a custom and restrictive chain (INPUT_PROTECT), which implicitly blocks any unauthorized port. The "Allow All" option in the TOS Firewall GUI does not correctly modify these rules.
Applied Fix: Explicit ACCEPT rules were added to the top of the INPUT chain for ports 8090 and 8443 using sudo iptables -I INPUT ....
Result: The problem persisted. Timeout.
Isolation Test 1 (Simple Container): A standard Nginx container was launched without custom configurations or volumes, on a test port (8888).
Command: sudo docker run --rm -d --name test-nginx -p 8888:80 nginx
A corresponding firewall rule for port 8888 was added.
Result: SUCCESS. The "Welcome to nginx!" page was accessible from the network.
Partial Conclusion: The base Docker system and the firewall are capable of exposing ports.
Isolation Test 2 (Compose without Custom Network): The docker-compose.yml file was modified to remove the custom bridge network, forcing the containers to use the default bridge network (the same one used by the successful test).
Result: Timeout.
Partial Conclusion: The issue is not the type of bridge network (default vs. custom), but potentially the use of docker-compose itself.
Isolation Test 3 (Compose without Volumes): The docker-compose.yml file was modified to remove volume mounts (volumes), making the Nginx container functionally identical to the one in Test 1.
Result: SUCCESS. The "Welcome to nginx!" page was accessible on port 8090.
Partial Conclusion: A direct conflict between port mapping (ports) and volume mounting (volumes) was identified. When a container uses both features, the networking fails.
Workaround 1 (Custom Image): To avoid using volumes, a custom Docker image (my-nginx-custom) was created using a Dockerfile that COPYs the configuration files (default.conf and certificates) directly into the image.
Result: Timeout. It was verified by entering the container (docker exec) that the configuration files were correctly copied and readable, and that the Nginx configuration was syntactically valid (nginx -t test was successful). However, the Nginx server appeared to ignore its own configuration on startup. Forcing a manual nginx -s reload changed the behavior but still did not resolve the issue.
Workaround 2 (Host Mode): The Docker networking layer was completely bypassed by using network_mode: host on both containers, forcing them to use the NAS's network stack directly.
Result: Timeout.
Final Conclusion:
The TOS 4.2.44 operating system exhibits a critical bug that manifests in several ways:
Docker's port mapping functionality fails when volumes are also in use.
The TOS Firewall GUI is ineffective and does not reflect the actual iptables configuration.
Even when avoiding the use of volumes by building a custom image, the Nginx container exhibits anomalous behavior, ignoring its own valid configuration file upon startup.
Not even network_mode: host, which removes Docker's network virtualization, can solve the problem, pointing to a conflict at an even lower system level.
This behavior makes it functionally impossible to reliably deploy standard, secure web applications via Docker on this device and software version. An urgent investigation by your engineering team is highly recommended.
Hardware: TerraMaster F4-220
TOS Version: 4.2.44
Docker Version: 20.10.17
Problem Description:
It is impossible to access ports exposed by Docker containers (launched via both docker-compose and docker run) when these containers also use bridge networks or mount volumes from the NAS's filesystem. Connections to these ports result in a timeout (ERR_CONNECTION_TIMED_OUT), even though the containers are shown as active (Up) and the system firewall (iptables) is explicitly configured to allow the traffic.
Summary of the Debugging Process and Key Findings:
An exhaustive diagnostic process was carried out to isolate the root cause of the issue. The results demonstrate anomalous and contradictory behavior in the Docker networking layer on TOS.
Initial Setup: An attempt was made to launch an Nginx and n8n stack using docker-compose. Nginx was configured as a reverse proxy for n8n, exposing ports 8090 (HTTP) and 8443 (HTTPS).
Result: Timeout.
Firewall Diagnostics (iptables): It was discovered that the INPUT chain in iptables redirects traffic to a custom and restrictive chain (INPUT_PROTECT), which implicitly blocks any unauthorized port. The "Allow All" option in the TOS Firewall GUI does not correctly modify these rules.
Applied Fix: Explicit ACCEPT rules were added to the top of the INPUT chain for ports 8090 and 8443 using sudo iptables -I INPUT ....
Result: The problem persisted. Timeout.
Isolation Test 1 (Simple Container): A standard Nginx container was launched without custom configurations or volumes, on a test port (8888).
Command: sudo docker run --rm -d --name test-nginx -p 8888:80 nginx
A corresponding firewall rule for port 8888 was added.
Result: SUCCESS. The "Welcome to nginx!" page was accessible from the network.
Partial Conclusion: The base Docker system and the firewall are capable of exposing ports.
Isolation Test 2 (Compose without Custom Network): The docker-compose.yml file was modified to remove the custom bridge network, forcing the containers to use the default bridge network (the same one used by the successful test).
Result: Timeout.
Partial Conclusion: The issue is not the type of bridge network (default vs. custom), but potentially the use of docker-compose itself.
Isolation Test 3 (Compose without Volumes): The docker-compose.yml file was modified to remove volume mounts (volumes), making the Nginx container functionally identical to the one in Test 1.
Result: SUCCESS. The "Welcome to nginx!" page was accessible on port 8090.
Partial Conclusion: A direct conflict between port mapping (ports) and volume mounting (volumes) was identified. When a container uses both features, the networking fails.
Workaround 1 (Custom Image): To avoid using volumes, a custom Docker image (my-nginx-custom) was created using a Dockerfile that COPYs the configuration files (default.conf and certificates) directly into the image.
Result: Timeout. It was verified by entering the container (docker exec) that the configuration files were correctly copied and readable, and that the Nginx configuration was syntactically valid (nginx -t test was successful). However, the Nginx server appeared to ignore its own configuration on startup. Forcing a manual nginx -s reload changed the behavior but still did not resolve the issue.
Workaround 2 (Host Mode): The Docker networking layer was completely bypassed by using network_mode: host on both containers, forcing them to use the NAS's network stack directly.
Result: Timeout.
Final Conclusion:
The TOS 4.2.44 operating system exhibits a critical bug that manifests in several ways:
Docker's port mapping functionality fails when volumes are also in use.
The TOS Firewall GUI is ineffective and does not reflect the actual iptables configuration.
Even when avoiding the use of volumes by building a custom image, the Nginx container exhibits anomalous behavior, ignoring its own valid configuration file upon startup.
Not even network_mode: host, which removes Docker's network virtualization, can solve the problem, pointing to a conflict at an even lower system level.
This behavior makes it functionally impossible to reliably deploy standard, secure web applications via Docker on this device and software version. An urgent investigation by your engineering team is highly recommended.