# Docker > Fix container problems: base images and gconv, fonts in the image, restoring from the private feed in docker build, ports and a backend in another container. - **Product:** TX Text Control .NET Server - **Section:** Documentation - **Kind:** Topic - **Path:** TX Text Control .NET Server > Troubleshooting > Docker - **1193 words** - **Web URL:** https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/docker/ - **LLMs URL:** https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/docker/llms.txt - **LLMs-Full URL:** https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/docker/llms-full.txt --- In a container, TX Text Control .NET Server depends on what the image contains, on how `docker build` reaches the private NuGet feed and on how the Document Editor backend is placed: in the application's container or in one of its own. [Dockerfile](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/docker/dockerfile/llms-full.txt) in the Deployment Guide builds an image that avoids them; the Linux libraries behind some of them are explained on [Linux](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/linux/llms-full.txt). ### Read the Output of the Container Run the container in the foreground and read its output: ```bash docker run --rm -p 8080:8080 myapp ``` A working container logs `Started TXTextControl.Web.Server.Core` and `Starting TCP listener on port 4283` before the application listens on port 8080, and each editor that connects adds the line `Starting web editor worker process with connection ID`. Lines with the prefix `[TXTextControl.Web.Server.Core]` come from the backend. [Build and Run the Image](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/docker/dockerfile/#build-and-run-the-image) shows the complete output. ### The Container Stops When It Creates a PDF The application process ends without an error message as soon as it creates a PDF document, or the container doesn't work at all with the chosen base image. Not every ASP.NET Core image contains what TX Text Control needs: chiseled images leave out the gconv modules, the plain chiseled image also lacks ICU, and Alpine doesn't work at all. 1. Use `mcr.microsoft.com/dotnet/aspnet:10.0`, or `8.0` for a .NET 8 application. [Choose the Base Image](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/docker/dockerfile/#choose-the-base-image) compares the images. 2. For a chiseled image, use the `-extra` variant and copy the gconv modules from the regular image, as [Use a Chiseled Image](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/docker/dockerfile/#use-a-chiseled-image) shows. ### Fonts Are Missing in the Container Documents created in the container use other fonts than on the development machine, although font packages were installed in the *Dockerfile*. The Core engine doesn't use fonts installed in the image; it reads the *Fonts* folder published with the application. Add the fonts to that folder instead, as [A Font Installed on the Server Isn't Used](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/fonts/#a-font-installed-on-the-server-isn-t-used) describes. In Windows containers with the Classic engine, the fonts installed in the container are used instead. ### docker build Can't Restore the Packages The restore in `docker build` fails for the TX Text Control packages, or the publish after it ends with error NETSDK1047. The build stage restores from the Text Control Private NuGet Feed, which needs the credentials in your *nuget.config*. A *Dockerfile* generated by Visual Studio restores without them. Pass *nuget.config* to the restore as a build secret, restore with `-r linux-x64` when the publish runs with `--no-restore`, and keep the file out of the image with *.dockerignore*. [Write the Dockerfile](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/docker/dockerfile/#write-the-dockerfile) shows the complete file and the build command. If the feed rejects the credentials, see [NuGet Authentication](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/nuget-authentication/llms-full.txt). ### The Site Isn't Reachable The container runs, but the browser can't reach the application. ASP.NET Core in the .NET images listens on port 8080. The port of the Document Editor backend, 4283, is used only inside the container. 1. Map port 8080 of the container: `docker run --rm -p 8080:8080 myapp`. 2. Don't publish port 4283. Articles for version 33.0 map port 4282; don't copy their port numbers. ### The Backend Doesn't Start in the Container The output shows `Error starting TXTextControl.Web.Server.Core: An error occurred trying to start process 'dotnet'`, and the application ends. Start the application with `ENTRYPOINT ["dotnet", "MyApp.dll"]`, and publish with `/p:UseAppHost=false` and without `--self-contained`. [The Backend Can't Start the dotnet Command](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/linux/#the-backend-can-t-start-the-dotnet-command) explains the cause. ### The Editor Can't Reach a Backend in Another Container The Document Editor backend runs in a container of its own, and the application container doesn't start, with a `SocketException` from the constructor of `TXTextControl.Web.WebSocketMiddleware` in its log, or the editor doesn't connect. The application resolves the host name of the backend container once, at startup, and a backend that listens only on the loopback address isn't reachable from another container. Start the backend with `--listen-address 0.0.0.0`, let the application depend on it with `depends_on`, and restart the application container after the backend container was recreated. [Run the Backend in Its Own Container](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/docker/multiple-processes/#run-the-backend-in-its-own-container) shows both projects and the Compose file. ### Several dotnet Processes Run in the Container The process list of the container shows several `dotnet` processes. This is expected: besides the application, the container runs the backend and one worker process for each connected editor. [The Processes of an Application](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/docker/multiple-processes/#the-processes-of-an-application) describes them, including what happens when the backend ends. A liveness probe on the application doesn't notice a backend that has ended; watch the log for the backend's messages. ### Related Pages - [Dockerfile](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/docker/dockerfile/llms-full.txt): build an image for an application with TX Text Control. - [Linux](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/linux/llms-full.txt): problems of the Linux system inside the image. - [Fonts](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/fonts/llms-full.txt): replaced fonts and the *Fonts* folder. - [Scaling Containers](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/docker/scaling/llms-full.txt): several containers behind a load balancer. --- ## Nearby - **Previous:** [Linux](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/linux/llms-full.txt) - **Next:** [Fonts](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/fonts/llms-full.txt)