Linux

All about Linux deployment of Devolutions Server. Suggestions / Bug reports / Feature request

AlexMoucha

posted 19 days ago

Resolved

DVLS 2026.3 Docker image: DATABASE_TYPE=PostgreSQL found in the binary, but not documented - please confirm usage

Hello together, DVLS 2026.3 added PostgreSQL as a database backend (release notes 2026.3.5.0, and the blog post "Run Devolutions Server on PostgreSQL" of Oct 14, 2026, which also mentions Linux and Docker deployments). The documentation has not been updated for the Docker image yet: - "Advanced Docker configuration for Devolutions Server" still lists only SQL Server variables (DATABASE_HOST, DATABASE_PORT with default 1433, DATABASE_ENCRYPT, DATABASE_TRUST_SERVER_CERTIFICATE, AZURE_SQL_*) and describes the "SQL Server connection string". - "Deploy Devolutions Server with Docker" lists an SQL Server instance as the only prerequisite. - "Install Devolutions Server for Linux" still uses the SQL Server flow. - "System requirements" only says "PostgreSQL is supported", without supported versions. I inspected the image devolutions/devolutions-server:release-2026.3 (digest sha256:755c87a8...) without starting it: - It ships Npgsql.dll and Npgsql.EntityFrameworkCore.PostgreSQL.dll. - The entrypoint is the DVLS binary itself (--container-entrypoint), so there is no script that shows the variables. - Devolutions.Server.dll contains a new variable DATABASE_TYPE and the error message "DATABASE_TYPE must be 'SqlServer', 'PostgreSQL', or 'SQLite'". It also contains DATABASE_PATH, DVLS_PG_DUMP_PATH, DVLS_PG_RESTORE_PATH and DVLS_DATABASE_UPGRADE_ON_STARTUP, plus an embedded PostgreSqlBaseline.sql. My assumption is that the container is configured like this, but I have not confirmed it: -e DATABASE_TYPE=PostgreSQL -e DATABASE_HOST=<host> -e DATABASE_PORT=5432 -e DATABASE_NAME=<db> -e DATABASE_USERNAME=<user> -e DATABASE_PASSWORD=<password> Questions: 1. Is DATABASE_TYPE=PostgreSQL officially supported with the Docker image? What are the exact accepted values (SqlServer / PostgreSQL / SQLite)? 2. How are DATABASE_ENCRYPT and DATABASE_TRUST_SERVER_CERTIFICATE mapped for PostgreSQL (SSL mode)? Are there PostgreSQL-specific variables? 3. Does the database have to exist before DVLS_INIT=true, or is it created automatically like on SQL Server? 4. DVLS_UPDATE_MODE creates a backup: does this need pg_dump / pg_restore (DVLS_PG_DUMP_PATH, DVLS_PG_RESTORE_PATH), and are these tools included in the image or do I have to provide them? 5. Which PostgreSQL versions are supported? 6. Is there an ETA for updating the Docker and Linux documentation? Environment: Docker (current version) on a Linux x86_64 host, DVLS release-2026.3 (existing SQL Server instance on 2026.3.10.0, PostgreSQL planned only for a new test installation, no migration). Thanks! Best regards, Alex

Recommended Answer

14 days ago

Hi Alex, Sorry I didn’t follow up here sooner. The documentation was updated after my first reply, and I should have let you know. Thanks for the detailed test result, they helped a lot. Here are the answers and a few corrections. 1. Role privileges. My earlier answer was wrong, sorry. CREATEDB is not enough, on a fresh database, the schema creation changes PostgreSQL type casts, which requires SUPERUSER. I reproduced it on DVLS 2026.3.11.0 with PostgreSQL 17.11: initialization fails with 42501: permission denied for table pg_cast when the role isn't superuser. What you did is the right workaround: ALTER ROLE dvls_user SUPERUSER; -- run the container once with DVLS_INIT=true ALTER ROLE dvls_user NOSUPERUSER; DVLS doesn't need superuser at runtime. We've logged this as a bug so that initialization works with a dedicated non-superuser owner role. 2. NOSUPERUSER for future upgrades. Only the initial schema creation needs superuser. The current upgrade steps don't change casts or require superuser, so an instance initialized the way you did should upgrade with a NOSUPERUSER owner, as long as that role owns the DVLS objects (which it does when it ran the initialization). We're fixing the initialization issue and adding a check that runs schema creation and upgrades as a non-superuser role. If a future version ever needs elevated rights for an upgrade, it will be called out in the release notes. 3. SSL mode. I was wrong here too; the documentation is correct. The mapping is: - DATABASE_ENCRYPT=false → SSL Mode=Disable - DATABASE_ENCRYPT=true + DATABASE_TRUST_SERVER_CERTIFICATE=true → SSL Mode=Require - DATABASE_ENCRYPT=true + DATABASE_TRUST_SERVER_CERTIFICATE=false → SSL Mode=VerifyFull 4. Backup. pg_dump and pg_restore are not in the image yet; that's a known issue. The job reporting success and writing a zip without the database dump is a separate problem: it should fail. I am logging that too. Until it's fixed, keep running pg_dump from the PostgreSQL side as you're doing now. 5. DVLS_ENCRYPTION_CONFIG_B64. If App_Data is on a persistent volume, the container works without it: initialization writes encryption.config to App_Data and reuses it on every start. We still recommend setting it, or at least keeping a secure copy of encryption.config outside the volume. That file is the only key to the encrypted data in the database, so if the volume is lost or recreated, the data can't be recovered. 6. Startup warnings behind a proxy. "Failed to determine the https port for redirect" is expected with WEB_SCHEME=http behind a TLS-terminating proxy, and it's harmless. 7. Gateway TLS cipher suites. TLS isn't my area of expertise, so I've asked our Gateway team to confirm the recommended configuration and will update this thread with their answer. From what we've looked at so far: in TLS 1.2, the cipher suite has to match the certificate type, so with an RSA certificate only the ECDHE_RSA_* suites can be used. The five suites you configured don't include any ECDHE_RSA suite, which would explain why RDM on macOS failed over TLS 1.2 while the nine-suite list (which includes the three ECDHE_RSA suites) works. In the meantime, the nine-suite list from the Gateway system requirements page for Devolutions Server is the one to use. Thanks again for the thorough testing.

102

AlexMoucha

replied 12 days ago

nicolosantorso

posted 17 days ago

Errors installing with Postgres

Hi, just followed your guide to install the server with postgres bare metal on a fresh debian 13 machine but i am getting some erorrs during the phase Running the installation at point 1: After running the commands i got those errors at the end: 1) "Update-DPSDatabase -ConnectionString $ConnectionString -InstallationPath $DVLSPath" Update-DPSDatabase: 42501: permission denied for table pg_cast Update-DPSDatabase: 42501: permission denied for table pg_cast WARNING: Update failed. 2) "New-DPSWorkspaceSettings -ConnectionString $ConnectionString" New-DPSWorkspaceSettings: 42P01: relation "dbo.databaseinfo" does not exist POSITION: 8 New-DPSWorkspaceSettings: Error while initializing database settings. 3) "New-DPSAdministrator -ConnectionString $ConnectionString -Name $DVLSAdminUsername -Password $DVLSAdminPassword -Email $DVLSAdminEmail" New-DPSAdministrator: 42P01: relation "dbo.usersecurity" does not exist POSITION: 15 New-DPSAdministrator: 42P01: relation "dbo.useraccount" does not exist POSITION: 15 New-DPSAdministrator: This NpgsqlTransaction has completed; it is no longer usable. I think there is something missing from the guide

Jeremie Perreault

replied 17 days ago

AlexMoucha

posted 8 months ago

Resolved

No connection from RDM to DVLS (including a solution)?

Hello everyone, I'm currently experimenting with the Devolutions Server via Docker in a test environment. So far, the environment is running smoothly and without errors via the WebUI with version 2026.1.7.0. The DPSMain_xxx log appears to be error-free. However, I am unable to establish a connection from an RDM to the Devolutions Server. The connection does not work on Windows, macOS, or iPadOS. In Windows RDM 2026.1.12.0, I receive this error message: System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception. ---> System.Security.Authentication.AuthenticationException: Cannot determine the frame size or a corrupted frame was received. at System.Net.Security.SslStream.GetFrameSize(ReadOnlySpan`1 buffer) at System.Net.Security.SslStream.EnsureFullTlsFrameAsync[TIOAdapter](CancellationToken cancellationToken, Int32 estimatedSize) at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System.Threading.Tasks.Sources.IValueTaskSource<TResult>.GetResult(Int16 token) at System.Net.Security.SslStream.ReceiveHandshakeFrameAsync[TIOAdapter](CancellationToken cancellationToken) at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](Boolean receiveFirst, Byte[] reAuthenticationData, CancellationToken cancellationToken) at System.Net.Http.ConnectHelper.EstablishSslConnectionAsync(SslClientAuthenticationOptions sslOptions, HttpRequestMessage request, Boolean async, Stream stream, CancellationToken cancellationToken) --- End of inner exception stack trace --- at Devolutions.Server.ApiWrapper.RDMSWebClient.RunSynchronous[T](Task`1 task) at Devolutions.RemoteDesktopManager.Business.DataSources.RDMSWebApiClient.ExecuteAnonymousAction[T](Func`2 action) at Devolutions.RemoteDesktopManager.Business.DataSources.RDMSWebApiClient.GetPublicWebInstanceInformation() On macOS RDM 2025.3.10.2, I get this message: Ungültige Protokollversion net_auth_SSPI net_http_ssl_connection_failed I've already imported my license. Unfortunately, it didn't work. I also tried two different proxies. No luck. My docker-compose.yaml follows these instructions: https://docs.devolutions.net/server/kb/how-to-articles/devolutions-server-docker-deployment/advanced-docker-configuration/#reverse-proxy-configuration After doing a bit of searching, I found the EXTERNAL_URL environment variable. Once I added this to my docker-compose file, the RDMs (Windows, macOS, and iPadOS) were able to connect to the Devolutions server. Here's my test Docker Compose file. As I said, I'm still testing it out / playing around with it ;-) environment: # Database connection variables # Web server configuration HOSTNAME: dvls.domain.tld WEB_SCHEME: http PORT: 5000 EXTERNAL_WEB_SCHEME: https EXTERNAL_WEB_PORT: 443 EXTERNAL_URL: dvls.domain.tld # TLS certificate configuration # Operating mode configuration DVLS_INIT: false #DVLS_UPDATE_MODE: ${DVLS_UPDATE_MODE} #DVLS_BACKUP_PATH: ${DVLS_BACKUP_PATH} # Initialization mode variables # System configuration DVLS_PATH: /opt/devolutions/dvls #DVLS_TELEMETRY: ${DVLS_TELEMETRY} #DVLS_ENCRYPTION_CONFIG_B64: ${DVLS_ENCRYPTION_CONFIG_B64} Could it be that this environment variable is missing from the documentation? Thanks in advance, Alex