# Linux > Fix Linux problems: the Classic package, glibc and gconv modules, ICU, the dotnet command, the working directory, permissions and case-sensitive file names. - **Product:** TX Text Control .NET Server - **Section:** Documentation - **Kind:** Topic - **Path:** TX Text Control .NET Server > Troubleshooting > Linux - **1716 words** - **Web URL:** https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/linux/ - **LLMs URL:** https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/linux/llms.txt - **LLMs-Full URL:** https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/linux/llms-full.txt --- An application that works on Windows can still fail on its first Linux server, because Linux differs in what it installs, how it names files and how services start. TX Text Control .NET Server runs on Linux with the Core engine, and most failures there involve that engine or its Document Editor backend. Containers have a page of their own: [Docker](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/docker/llms-full.txt). ### Check What Runs on the Server With the application running as a systemd service, as [Ubuntu](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/linux/ubuntu/llms-full.txt) sets it up, collect the evidence first: 1. Follow the log of the service: ```bash sudo journalctl -fu kestrel-myapp.service ``` A backend that has started logs `Started TXTextControl.Web.Server.Core with Process ID`, then `Starting TCP listener on port 4283`, and for each editor that connects `Starting web editor worker process with connection ID`. 2. List the ports that are open: ```bash sudo ss -ltnp ``` The backend listens on 127.0.0.1:4283 and the application on the port of Kestrel, for example 127.0.0.1:5000. [Verify the Deployment](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/linux/ubuntu/#verify-the-deployment) describes the output of a working server. ### The Application Uses the Classic Engine The application references `TXTextControl.TextControl.ASP.SDK` or `TXTextControl.Web.DocumentViewer.Classic`, which work on Windows only. Only the Core engine runs on Linux; replace the packages as [The Classic Engine Doesn't Run Outside Windows](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/native-libraries/#the-classic-engine-doesn-t-run-outside-windows) describes. ### The Distribution Is Too Old or Uses musl The application runs on an older distribution, such as Debian 11, and fails when it loads the engine. The native libraries of the Core engine need glibc 2.34 or later and a `libstdc++` with `GLIBCXX_3.4.29`, which Debian 11 doesn't provide. Run the application on a current distribution, such as Ubuntu or Debian, with the packages `libc6`, `libstdc++6` and `libgcc-s1` installed. [Processor Architecture and C Library](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/linux/requirements/#processor-architecture-and-c-library) lists the requirements. Alpine Linux, ARM64 processors and other unsupported platforms are covered in [The Processor or the Operating System Isn't Supported](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/native-libraries/#the-processor-or-the-operating-system-isn-t-supported). ### The Process Ends When It Creates a PDF The application process ends without an error message as soon as `ServerTextControl` creates a PDF document, and the Document Editor closes its connection when it exports a PDF document. TX Text Control converts character sets with the gconv modules of glibc in */usr/lib/x86\_64-linux-gnu/gconv*, and they are missing. Check that the folder exists and contains the modules; on Debian 13, they belong to the package `libc6`. [System Files](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/linux/requirements/#system-files) explains them, and [The Container Stops When It Creates a PDF](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/docker/#the-container-stops-when-it-creates-a-pdf) covers chiseled container images. ### The Backend Logs an Invalid Culture Identifier For each editor that connects, the backend logs: ```text en is an invalid culture identifier. ``` .NET runs in globalization-invariant mode, because the ICU libraries are missing or `DOTNET_SYSTEM_GLOBALIZATION_INVARIANT` is set to `true`. Install ICU, or use an image that contains it, such as `10.0-noble-chiseled-extra`, and remove the variable from the environment of the application. [System Files](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/linux/requirements/#system-files) describes the images. ### The Backend Can't Start the dotnet Command The application ends at startup with: ```text Error starting TXTextControl.Web.Server.Core: An error occurred trying to start process 'dotnet' ``` The backend and its worker processes are started with the `dotnet` command, which an application started through its own executable, or published self-contained, doesn't provide. Start the application with `dotnet`, for example with `ExecStart=/usr/bin/dotnet /var/www/myapp/MyApp.dll` in the systemd unit, or add the folder of the `dotnet` command to the search path of the service. [.NET Runtime](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/linux/requirements/#net-runtime) describes what the backend needs. ### The Application Ignores appsettings.json Settings from *appsettings.json* aren't applied, for example the address or port of the Document Editor backend, which then listens on all network interfaces again. ASP.NET Core reads the file from the working directory of the process. Set the working directory of the service to the application folder, for example `WorkingDirectory=/var/www/myapp` in the systemd unit, and restart the service. [Run the Application as a systemd Service](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/linux/ubuntu/#run-the-application-as-a-systemd-service) shows the complete unit. ### The Account Has No Access to the Files The application or the backend can't read its files, or the backend can't write its log. The account that runs the service, which the backend and its worker processes share, needs read access to the whole application folder, and write access to the log folder of the backend if you set `LogTarget` to `File`. Give the account the application folder, for example with `sudo chown -R www-data:www-data /var/www/myapp`. [Files and Permissions](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/linux/requirements/#files-and-permissions) lists what the account needs. ### A File That Exists Isn't Found A file is in the application folder, but TX Text Control behaves as if it were missing. Linux file names are case-sensitive, and TX Text Control looks for some files by their exact names: - **The *Fonts* folder.** A folder named *fonts* isn't found. See [The Default Font Installation Failed](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/fonts/#the-default-font-installation-failed). - **The configuration file of the backend.** The backend reads *TXTextControl.Web.Server.Core.config.json* only in exactly this spelling. When it reads the file, it logs `Successfully read config file 'TXTextControl.Web.Server.Core.config.json'.` - **Images in templates.** Templates can reference images by Windows paths, such as *C:\\Users...*, that don't exist on the server. See [Images Are Missing After Loading](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/conversion/#images-are-missing-after-loading). Rename the file or folder to the exact name, or use the one from the package. ### A Feature of the Windows Version Is Missing A feature that the application used on Windows fails or has no effect on Linux. The Core engine and the cross-platform backend differ from the Classic engine on Windows. [Not Available on Linux](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/linux/requirements/#not-available-on-linux) lists the differences, among them: - **DOC documents.** See [A DOC File Can't Be Converted on the Core Engine](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/conversion/#a-doc-file-can-t-be-converted-on-the-core-engine). - **Printing on the server.** Applications on Linux create a PDF document and let users print it in the browser. See [Let Users Print in the Browser](https://docs.textcontrol.com/tx-text-control-dotnet-server/document-processing/printing/#let-users-print-in-the-browser). - **Render mode, formatting printer and dialog boxes of the Document Editor.** See [A Method Fails With the Cross-Platform Backend](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/document-editor/#a-method-fails-with-the-cross-platform-backend) and [A Dialog Box Is Missing on Linux](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/document-editor/#a-dialog-box-is-missing-on-linux). - **Fonts.** Core uses the *Fonts* folder of the application instead of the fonts of the system. See [Fonts](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/fonts/llms-full.txt). ### Related Pages - [Linux Requirements](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/linux/requirements/llms-full.txt): everything a Linux server needs. - [Docker](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/docker/llms-full.txt): problems of container images. - [WebSockets](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/websockets/llms-full.txt): the Document Editor doesn't connect. - [Native Library / Runtime Errors](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/native-libraries/llms-full.txt): unsupported platforms and a missing runtime. --- ## Nearby - **Previous:** [WebSockets](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/websockets/llms-full.txt) - **Next:** [Docker](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/docker/llms-full.txt)