CorpXeno

29 Nov 2025

Troubleshooting SQL Container Issues

SQL ServerLinuxDocker Containers

How to check Docker Logs:

Docker logs <container name>

Use above command to review SQL Server error logs generated inside the container

  1. The most common mistake while creating a SQL server container is not adhering to password complexity of the SA account.
  2. Unlike in Linux, failing the SQL Server password complexity policy on Windows does not terminate the container nor does it creates an entry in SQL Error logs. The container will continue to run but it won't allow you to log in using the SA credentials. Use docker exec command to start the container in single user mode and change the SA password.
  3. Use docker logs with -f parameter to review SQL error logs in real time.
  4. Ways to review Docker Daemon logs:
  5. Systemctl status docker -l
  6. Cat var/log/messaged | grep docker

SQL Server container startup errors

Error:

failed to create endpoint CONTAINER_NAME on network bridge. Error starting proxy: listen tcp 0.0.0.0:1433 bind: address already in use.,

This error occurs when you try to map the container port 1433 to a port that is already in use. This can happen if you're running SQL Server locally on the host machine. It can also happen if you start two SQL Server containers and try to map them both to the same host port. If this happens, use the -p parameter to map the container port 1433 to a different host port. For example:

docker run -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=<password>' -p 1400:1433 -d mcr.microsoft.com/mssql/server:2022-latest`.

Error:

Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.30tdout=1&tail=all: dial unix /var/run/docker.sock: connect: permission denied

Add your user to the docker group using below command. Then logout and login again as this change will affect new sessions.

usermod -aG docker $USER

Enable dump captures

If the SQL Server process is failing inside the container, you should create a new container with SYS_PTRACE enabled. This adds the Linux capability to trace a process, which is necessary for creating a dump file on an exception. The dump file can be used by support to help troubleshoot the problem. The following docker run command enables this capability.

docker run -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=<password>' -e 'MSSQL_PID=Developer' --cap-add SYS_PTRACE -p 1401:1433 -d mcr.microsoft.com/mssql/server:2022-latest

SQL Server connection failures

Make sure that your SQL Server container is running by looking at the STATUS column of the docker ps -a output. If not, use docker start <Container ID> to start it.

If you mapped to a non-default host port (not 1433), make sure you're specifying the port in your connection string. You can see your port mapping in the PORTS column of the docker ps -a output.

If you used docker run with an existing mapped data volume or data volume container, SQL Server ignores the value of MSSQL_SA_PASSWORD. Instead, the pre-configured sa account password is used from the SQL Server data in the data volume or data volume container. Verify that you're using the sa password associated with the data you're attaching to.

SQL Server setup and error logs

logs in /var/opt/mssql/log. If the container isn't running, first start the container. Then use an interactive command-prompt to inspect the logs. You can get the container ID by running the command docker ps.

docker start <ContainerID>

docker exec -it <ContainerID> "bash"

OR

docker exec -it <Container ID> /bin/bash

From the bash session inside your container, run the following commands:

cd /var/opt/mssql/log

cat setup*.log

cat errorlog