Skip to main content
Version: 4.1

Troubleshooting

Start with the logs: most of the answers below were found there.

WhatWhere
Hosting panel (2083)/var/log/hitechcloud/user/panel.log, journalctl -u hitechcloud
Admin panel (2087)/var/log/hitechcloud/admin/admin.log, journalctl -u hitechadmin
Customer portals/var/log/hitechcloud/portals/, hitechcloudcli portals logs <portal>
Every hitechcloudcli command run/var/log/hitechcloud/admin/hitechcloudcli.log
Enterprise activation/var/log/hitechcloud/enterprise-activation.log
A background task started from a paneljournalctl -u 'hitechcloud-install-*'

The full list is in Where HiTechCloud stores logs.

Signed in and sent back to the login page​

What you see: the username and password are accepted at https://<server>:2083, and the browser lands on the login page again with no error. The same happens at the customer portals and with a one-time login link from HiTechAdmin.

Why: the panel keeps sessions in the server's Redis-compatible cache (Valkey or Redis). When the panel cannot write the session there, the login succeeds and the session is lost on the next page. panel.log says so:

LOGIN - Failed to write to Redis: no connection

or names the cache's own answer, for example WRONGPASS. From 4.1.2 the sign-in form says so too, instead of silently returning you to it:

Your session could not be saved: the panel cannot reach its session store.

The fix is usually hitechcloudcli objectcache panel-login (below).

What to check:

grep 'LOGIN - Failed to write to Redis' /var/log/hitechcloud/user/panel.log | tail -5
hitechcloudcli objectcache status
systemctl status valkey-server valkey redis-server redis --no-pager

The unit is valkey or valkey-server, and redis or redis-server, depending on the distribution.

  • If the cache service is stopped, start it and sign in again.

  • If the cache answers WRONGPASS or NOAUTH, the panel's cache login and the instance disagree. From 4.1.2:

    hitechcloudcli objectcache panel-login

    writes the first login on file that the cache accepts and restarts the panel once. When it reports that no login on file opens the instance, give the instance a new administrator password (accounts' logins are kept, the panel follows):

    hitechcloudcli objectcache reset-admin valkey --yes # or: redis

    Every 4.1.2 update runs panel-login too, so updating a server that has this problem repairs it.

NOTE

Checked in the code and its unit tests, not on a live server, for this page.

ClamAV does not start: "No supported database files found"​

What you see: clamd@scan (or clamav-daemon) stops right after starting, and its journal says No supported database files found. freshclam exits with The PrivateMirror config option may not include servers under *.clamav.net.

Why: installers before 4.1.2 wrote ClamAV's own server as a PrivateMirror in freshclam.conf, which freshclam refuses, so no virus signatures were ever downloaded.

Fix: update to 4.1.2 or later. The update repairs freshclam.conf (ClamAV's server becomes a DatabaseMirror), runs freshclam to completion and then starts clamd. To run that step on its own:

hitechcloudcli install --extras-only --with clamav

The firewall is off​

A new server has ConfigServer Firewall (CSF) installed and switched off, so that a rule cannot lock you out while the server is being set up. HiTechAdmin and hitechcloudcli module list show it as off by design, not as failed.

Turn it on once you can reach the server:

hitechcloudcli firewall on

It rebuilds the list of open ports, allow-lists the address of the SSH session you run it from (add more with --allow <ip>), then enables CSF. See hitechcloudcli firewall.

Microsoft SQL Server on AlmaLinux and RHEL 10​

What you see: mssql-server does not start, and its journal says error while loading shared libraries: liblber-2.4.so.2.

Why: AlmaLinux and RHEL 10 no longer ship that library. It is in the openldap-compat package.

Fix: from 4.1.2, hitechcloudcli sqlserver install installs openldap-compat first, accepts the licence non-interactively, and fails with the service's journal instead of reporting success when the server does not run. On an earlier install:

dnf install -y openldap-compat
hitechcloudcli sqlserver restart
hitechcloudcli sqlserver status

Microsoft publishes no SQL Server repository for Ubuntu 26.04, so it is not offered there.

NOTE

The AlmaLinux 10 SQL Server path was checked in the code, not on a live server.

A background task will not start again​

What you see: installing something from HiTechAdmin (the App Store, a PHP version, a mail component) does nothing, or reports Unit hitechcloud-install-<name>.service was already loaded or has a fragment file.

Why: panel tasks run as transient systemd units named hitechcloud-install-<task>. A unit that failed stays loaded until systemd is told to forget it. From 4.1.2 the panel clears a stopped or failed unit itself and says already running when it still runs.

Fix: see what is there, read why it failed, then clear it:

systemctl list-units --all 'hitechcloud-install-*'
journalctl -u hitechcloud-install-<name> -n 50 --no-pager
systemctl reset-failed 'hitechcloud-install-*'

Then start the task again from the panel.

WireGuard clients connect but cannot reach the internet​

The VPN's NAT rule needs the netfilter masquerade module of the running kernel. When an update installed a newer kernel, the running one may not be able to load it. hitechcloudcli vpn status names the reason, including a newer kernel is installed ... reboot to load it. Reboot, then:

hitechcloudcli vpn repair

Search (OpenSearch) is not installed on AlmaLinux 10​

The key OpenSearch signs its repository with is rejected by the crypto policy of AlmaLinux and RHEL 10. From 4.1.2 the installer then installs Elasticsearch, which provides the same search feature, and removes the rejected repository so later dnf commands keep working. When neither can be installed, the module is reported as pending with the reason, not as a failure. See System requirements.

Still stuck​

Collect hitechcloudcli report output and the log lines above, and see Report a bug.