StartOS 0.4.0.1 - Nextcloud 31.0.13:1 fails with "get-ssl-certificate: unknown hostname" despite hostname being registered

[dmageetx]

Title:

Nextcloud 31.0.13:1 fails with “get-ssl-certificate: unknown hostname” although hostname is registered

Hello,

I’m hoping someone from engineering can help diagnose what appears to be an inconsistency between the SSL subsystem and the package binding database.

Environment

• StartOS 0.4.0.1

• Nextcloud 31.0.13:1 (Legacy)

• ~1.5 TB of production data stored in Nextcloud

Because of the amount of data, I’m trying to avoid uninstalling the package.

Problem

Nextcloud will not start.

The server logs consistently report:

get-ssl-certificate

unknown hostname: 153.66.101.236

The failure occurs before Nextcloud finishes starting.

What I’ve verified

WAN IP is detected correctly

The server reports:

153.66.101.236

Manual certificate generation succeeds

start-cli net ssl generate-certificate 153.66.101.236

This succeeds.

The package host is registered

start-cli package host nextcloud address main list --format json

returns:

[
  {
    "address":"nextcloud.twitchy-toga.local",
    "public":null,
    "private":["enp2s0"]
  }
]

The HTTPS binding contains the public IP

Running:

start-cli package host nextcloud binding main list --format json

shows that the UI binding includes:

• nextcloud.twitchy-toga.local

• twitchy-toga.local

• LAN addresses

• Tor address

• 153.66.101.236 (ssl=true, public=true)

Why I’m confused

The binding database clearly contains the public IP, but during startup get-ssl-certificate reports:

unknown hostname: 153.66.101.236

It appears the binding database recognizes the hostname while the SSL lookup rejects it.

Additional information

I also verified:

• start-cli net ssl generate-certificate 153.66.101.236 succeeds.

• start-cli net vhost dump-table contains the Nextcloud virtual host.

• The package script references interface "main" for the network pointers.

Questions

1. Is this a known issue with StartOS 0.4.0.1 or the legacy Nextcloud package (31.0.13:1)?

2. Is there a safe way to repair the package registration or SSL host database?

3. Is start-cli package rebuild nextcloud a non-destructive operation that preserves the existing data volume?

I’m trying to avoid risking approximately 1.5 TB of Nextcloud data.

Thank you.

---

I also recommend attaching (rather than pasting) these outputs if the forum allows files:

• start-cli server logs (showing the unknown hostname error)

• start-cli package host nextcloud address main list --format json

• start-cli package host nextcloud binding main list --format json

• start-cli net vhost dump-table

This keeps the post concise while still giving the engineers the detailed diagnostics if they need them.

[dmageetx]

I gathered additional diagnostics. The Nextcloud logs show that get-ssl-certificate requests a certificate for 153.66.101.236, and the StartOS core (shared-libs/crates/start-core/src/service/effects/net/ssl.rs:50) returns unknown hostname: 153.66.101.236. However, start-cli package host nextcloud binding main list --format json shows that the same IP is already registered as a public SSL hostname for the package. Could an engineer advise whether this is a known issue with the 0.3.5.1 → 0.4.0.1 migration or the legacy Nextcloud package?

[dmageetx]

Additional detail: Nextcloud Legacy 31.0.13:1 now shows “Running,” but the Web Interface health check remains at “Nextcloud is initializing.” The health check reports /dev/stdin: No such device or address and syntax error: operand expected. The package logs also show get-ssl-certificate failing because StartOS reports unknown hostname: 153.66.101.236. Please advise before I rebuild or reinstall because the instance contains approximately 1.5 TB of data.