This is a freshly installed iso appliance and I noticed login problems to the admin area after a reboot. Its probably a (known) bug. When trying to login in the webinterface the server responses with "The server encountered an error while processing the request." by an http error 500. Checking the api services on the console reveals:
# systemctl status grommunio-admin-api.service
● grommunio-admin-api.service - grommunio admin api
Loaded: loaded (/usr/lib/systemd/system/grommunio-admin-api.service; enabled; preset: disabled)
Active: active (running) since Wed 2025-11-12 14:32:00 CET; 43s ago
TriggeredBy: ● grommunio-admin-api.socket
Main PID: 777 (uwsgi)
Status: "uWSGI is ready"
Tasks: 7 (limit: 4666)
CPU: 3.199s
CGroup: /system.slice/grommunio-admin-api.service
├─ 777 /usr/sbin/uwsgi --ini /usr/share/grommunio-admin-api/api-config.ini
└─1334 /usr/sbin/uwsgi --ini /usr/share/grommunio-admin-api/api-config.ini
Nov 12 14:31:58 grommunio uwsgi[777]: Failed to detect schema version, assuming up-to-date schema
Nov 12 14:31:58 grommunio uwsgi[777]: Database connection failed with error 2002: Can't connect to local MySQL server through socket '/run/mysql/mysql.sock' (2)
Nov 12 14:32:00 grommunio uwsgi[777]: Could not load license: No such file or directory
Nov 12 14:32:00 grommunio uwsgi[777]: WSGI app 0 (mountpoint='') ready in 4 seconds on interpreter 0x7f99ac1a3c18 pid: 777 (default app)
Nov 12 14:32:00 grommunio uwsgi[777]: *** uWSGI is running in multiple interpreter mode ***
Nov 12 14:32:00 grommunio uwsgi[777]: spawned uWSGI master process (pid: 777)
Nov 12 14:32:00 grommunio systemd[1]: Started grommunio admin api.
Nov 12 14:32:00 grommunio uwsgi[777]: spawned uWSGI worker 1 (pid: 1334, cores: 4)
Nov 12 14:32:00 grommunio uwsgi[1334]: [WARNING] (tasq) Schema version too old (n102 required) - falling back to offline mode.
Nov 12 14:32:28 grommunio uwsgi[1334]: [WARNING] (grommunio Admin API) Database schema version updated detected - reloading ORM
Somehow the service has issues connecting to the mysql/mariadb service, after doing a # systemctl restart grommunio-admin-api.service the service runs clean and logging in to the admin area works. Looks like a bug in the starting order to me, as the api service is not depending on the sql service to come up first.
