Hello,
This is my first post here, so I will start by presenting myself. I live in France and I work for a computer entreprise.
I'm used to use command lines, log files, etc. so don't hesitate to make me "test" things.
And now, here is the problem I encounter.
I have develop a Blazor application which uses a SQL Server database behind.
Everything is working well as expect in local (using Visual Studio Code as IDE).
I would now like to deploy this application on my Syno in a docker container, more precisely in 2 containers (1 with the application and 1 with the database).
For this, I have created a docker-compose file which is this one :
Code:
services:
myapp-web-sql:
image: mcr.microsoft.com/mssql/server:2019-latest
container_name: myapp-web-sql
ports:
- "1986:1433"
environment:
SA_PASSWORD: "MyPassword!"
ACCEPT_EULA: "Y"
networks:
- myapp-web-network
myapp-web-app:
image: myapp-web-image:latest
container_name: myapp-web-app
ports:
- "1987:8080"
depends_on:
- myapp-web-sql
networks:
- myapp-web-network
networks:
myapp-web-network:
driver: bridge
This is a very simple docker-compose that for me should work as expect.
For the connection string in the Blazor app (development and production settings are the same), this is it :
Code:
"ConnectionStrings": {
"DefaultConnection": "Server=myapp-web-sql,1433;Database=MyDatabase;User Id=SA;Password=MyPassword!;MultipleActiveResultSets=true;Encrypt=false;TrustServerCertificate=True"
When I test it on my local machine (Windows computer) with Docker Desktop, it works as expected.
Then, on Container Manager, in the project tab, I choose my folder, it recognizes the docker-compose file inside, load everything but then, the app container is failing with this message :
Unhandled exception. Microsoft.Data.SqlClient.SqlException (0x80131904): A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 40 - Could not open a connection to SQL Server)
In the Network tab, I can see that it has created a network where the 2 containers are located, so they should see each other.
I don't know what I'm missing, I have search on Internet for a lot of information, but none of them help, it seems to be related to the NAS and not Docker.
FYI, when I tried to use the "Terminal" on the myapp-web-app, but it fails everytime when opening.
Thanks for your help on this.
Kevin
I don't know what I'm missing, I have search on Internet for a lot of information, but none of them help, it seems to be related to the NAS and not Docker.
FYI, when I tried to use the "Terminal" on the myapp-web-app, but it fails everytime when opening.
Hello and welcome to the forum!
Have you tried to replace
Code:
"Server=myapp-web-sql,1433
with the IP of the host (NAS)?
Looks like it doesn’t connect to the database.
Docker Desktop runs docker-ce in a utility vm, Synology runs a customized docker-ce on the host.
Since your compose file uses a bridge network, it should work with either docker version as is.
I assume you minified the compose file for simplicity, otherwise I would be concerned that no volume is declared to persist data outside the container.
Please check the logs and look out for errors. The problem you experience would make sense, if the database container would fail to start.
Thanks for these quick answers !
As one-eyed-king suggests, the 2 containers should normally see each other by their name because they use the same network.
The docker-compose was not simplify, but I just tried to be minimalist at the first time to validate how it all works, and it works on Docker Desktop... Is that okay for a first try?
What I didn't mention is that I can see that the myapp-web-sql container is well starting and I can access it threw SQL Server Management on my computer using the ip address of my NAS + port 1986. I can also create the Database in there, no problem.
I have then tried to restart the myapp-web-app container but it fails with the same message.
when I tried to use the "Terminal" on the myapp-web-app, but it fails everytime when opening.
Considering the front-end container has a dependency towards the back-end (SQL), it is no wonder it fails considering the error you posted. Looks like the SQL side is failing and you should start there.
Have you tried to simplify things 1st? Maybe run SQL as a single container on its own and see it will boot the instance so that you can use it normally.
Looks like a mystery: if the database can be reached through a published port, than it must be listening on 0.0.0.0. If it would listen just on localhost, the published port wouldn't allow to reach the port inside the container.
As a first workaround you should try what
@BobW
suggested: use the host ip and published host port.
Anyway the connection error doesn't make sense to me. In a docker bridge network each container can communicate with every other container on any port without restrictions.
Does a cli based tool exist that you could use to test the connection? If so, you could make join the network namespace of the app container by declaring
network_mode: service:myapp-web-app
or with the cli argument
--network container:myapp-web-app
(Syntax might be wrong, if so please take a look in the docs).
Hi again,
As suggested I tried to use the local ip address of the container and external port like this :
Code:
"DefaultConnection": "Server=172.23.0.2,1986;Database=MyDatabase;User Id=SA;Password=MyPassword!;MultipleActiveResultSets=true;Encrypt=false;TrustServerCertificate=True"
But it fails in the same way.
I have ssh my NAS and do a "sudo docker network inspect myapp-web_myapp-web-network" (that's the name of the network created by Docker on my NAS"
Here is the result:
Code:
"Name": "myapp-web_myapp-web-network",
"Id": "cc3ca60eb40677f8c27f60ef31256f9f36861699dd1a18f3c53f07e775a6f5fd",
"Created": "2024-06-11T08:07:52.868168567+02:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
"Subnet": "172.23.0.0/16",
"Gateway": "172.23.0.1"
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
"ConfigOnly": false,
"Containers": {
"673ac82e8e3cf88a2de7f99efdeea0f6e9abf5e9e470be7db69b824c127b4fd5": {
"Name": "myapp-web-app",
"EndpointID": "fe6fdd3abfc040cdf3edf1140b8fc402767c188bdafdf889b5b6f672619e127d",
"MacAddress": "02:42:ac:17:00:03",
"IPv4Address": "172.23.0.3/16",
"IPv6Address": ""
"77f9e77d5cc419c7c6b2cedb39c52a0667b06d3da9efd9ea1afe9943d130c7be": {
"Name": "myapp-web-sql",
"EndpointID": "05efcbe993dfc83984d974eab4cc640f208cfc49fb26f0ef32a9039bed71beb6",
"MacAddress": "02:42:ac:17:00:02",
"IPv4Address": "172.23.0.2/16",
"IPv6Address": ""
"Options": {},
"Labels": {
"com.docker.compose.network": "myapp-web-network",
"com.docker.compose.project": "myapp-web",
"com.docker.compose.version": "2.9.0"
As suggested I tried to use the local ip address of the container and external port like this :
I am lost. Which suggestion do you mean?
@BobW
suggested:
BobW said:
with the IP of the host (NAS)?
I suggested:
one-eyed-king said:
As a first workaround you should try what @BobW suggested: use the host ip and published host port.
... and my other suggestion was to use a troubleshooting container that is joined into the network namespace of your application container.
If SQL Manager is able to access the database through the nas-ip:published-port, so should your application container (unless the firewall prevents it).
You're right, I misunderstand the "local ip address" and the "host ip address".
I tried with my NAS Ip but it fails again ...
I don't understand, really, what's happening here.
Do you think it has something to do with the firewall ?
For container to host communication: most likely, as the container networks are not considered the lan cidr.
For container to container communication in a bridge network: i'd be surprised.
Since things don't add up anyway, you could try if the behavior changes with temporarily disabled firewall.
All right ! Just to finalize this problem.
I have a lot of rules in my firewall and the last one of them is blocking all other communication (all ports from all ip source have forbidden access)
I just had to add a rule saying to accept connection to port 1433 but didn't manage to use a list of IP, instead using "All"
But why would it prevent container to container communication in a bridge network? In theory, the container should not be affected by the interfaces the firewall controls.
Have you considered adding a firewall rule that permits traffic in the docker cidr range
172.0.16.0/12
172.17.0.0/116
, 172.16.0/12, instead of pocking holes for single ports? Docker networks are isolated from each other, so unless someone deliberately attaches containers that shouldn't communicate with each other into the same container network, everything should already be good.
Oh no, I messed up the cidr range. I thought about my response from yesterday and realized that 172.17.0.1/16 can't be right, as it's the subnet of the default bridge networks. Years ago I would have known the docker ip ranges by heart
The correct cidr range is 172.16.0.1/12, which translates to a netmask of 255.240.0.0.
