Task Advisor Warnings

The Task Advisor continuously checks your cluster and management node and raises a recommendation whenever it finds something worth your attention. Each recommendation shown in the croit UI (and available to hook scripts via the OnTaskAdvisorFindingAdded/OnTaskAdvisorFindingRemoved events) corresponds to one of the warning types below. For some warnings the UI also shows one or more buttons that apply a fix automatically, so it is worth checking a recommendation in the UI before fixing it by hand. This page lists every warning type with a general description and its usual causes; the croit UI additionally shows a short, per-cluster summary and, where applicable, links to the affected object. Clicking a recommendation's title in the croit UI opens this page at that warning.

Ceph

CephReleaseDoesNotMatch: Ceph release mismatch

The cluster is running a different Ceph release than the one configured in croit.

Usual causes: the Ceph packages/containers were upgraded (or downgraded) outside of croit, or the configured Ceph version in croit was never updated to match a completed upgrade.

MultipleCephReleasesRunning: Multiple Ceph releases running

Some nodes in the cluster are running a different Ceph release than others.

Usual causes: a rolling upgrade is stuck partway through, or a node was reinstalled or manually patched without going through croit's upgrade flow.

ContainerMismatch: Ceph container mismatch

The cluster is configured to run one Ceph release's container image while a different default image is expected for that release.

Usual causes: croit's bundled container defaults changed after a croit update, and the cluster has not yet been switched over to the new container.

CephEOLWarning: Ceph release reached end of life

The currently configured Ceph release will no longer receive updates.

Usual causes: the cluster has not been upgraded in a while and is still running an older major Ceph release (Luminous through Quincy).

CephSecurityUpdateAvailable: Ceph security update available

The Ceph version running in the cluster is missing important security fixes: CVE-2025-30156, CVE-2026-39944, CVE-2026-50152 and CVE-2026-54330. Between them they cover an authentication bypass and three ways a client can gain permissions it was never granted.

Updating the Ceph version is the whole fix for three of them. The fourth, the authentication bypass, also needs the cluster's access keys replaced afterwards, which croit raises separately once the update is in (see Ceph access keys require renewal).

Usual causes: the cluster runs a Ceph release older than 19.2.6 (Squid) or 20.2.4 (Tentacle).

CephKeysNeedRenewing: Ceph access keys require renewal

The cluster's access keys, the credentials its own services and its clients authenticate with, were created with an encryption method that has a known flaw. Installing the Ceph update does not replace them, so until they are replaced the flaw is still reachable.

The recommendation links to a guided renewal that works through it step by step. croit renews the keys it manages itself, including the ones its own services and its access to the cluster depend on, and lists the keys only you can renew, because only you know which machines hold them and whether the software there is new enough. You can leave the guided renewal at any point and pick it up where you left off.

Usual causes: the cluster was updated to a Ceph release that reports these keys, and the renewal has not been finished yet.

CephOldKeysStillAllowed: Legacy Ceph access keys still allowed

Every access key has been renewed, but the cluster still accepts keys using the encryption method with the known flaw, because the guided renewal was finished with that left open. Nothing is using the old method any more; what remains is that a key created with it would still be accepted.

The guided renewal's last step offers to close it, and the recommendation links straight there. It is worth doing once the last client too old for the new method has been updated.

Usual causes: the operator chose "leave old clients working" on the last step of the guided renewal, to keep serving a client that cannot use the new encryption yet.

MON

MonCountBelowMin: Too few MONs

The cluster has only one or two MON services.

Usual causes: a small or test cluster was never scaled up, or MON services were removed without replacing them. Croit recommends 3 MONs for smaller and 5 MONs for bigger clusters, so that quorum survives the loss of a single node.

MonCountEven: Even number of MONs

The cluster has an even number of MON services (4 or 6).

Usual causes: a MON was added without considering that Ceph quorum requires an odd count. An even count adds a node without improving how many failures the cluster can tolerate, since quorum still needs more than half the MONs to agree.

MonCountAboveMax: Too many MONs

The cluster has more than 7 MON services.

Usual causes: MONs were added faster than they were removed during cluster growth or migrations. More than 7 MONs adds Paxos round-trip latency to every cluster map change without a proportionate reliability gain.

OSD

OsdCountIsZero: No OSDs

The cluster has no OSDs, so no data can be stored.

Usual causes: a freshly bootstrapped cluster before disks were assigned, or all OSDs were removed during maintenance and not yet replaced.

OsdIsNearFull: OSD almost full

An OSD's usage ratio is above roughly 70%.

Usual causes: uneven data distribution (CRUSH weighting or PG imbalance), or overall cluster capacity approaching its limit. Left unaddressed this escalates to OsdIsTooFull.

OsdIsTooFull: OSD full

An OSD's usage ratio is above roughly 80%.

Usual causes: same as OsdIsNearFull, left unaddressed. Ceph blocks writes to the pool once an OSD reaches its full ratio, so free up space or rebalance promptly.

CrushmapHostOutsideRoot: Host outside CRUSH root

A host bucket exists in the CRUSH map but is not reachable from any root bucket.

Usual causes: a host was removed from a rack/root bucket during manual CRUSH map edits, or croit's expected topology and the actual CRUSH map have drifted apart. Data is not placed on OSDs on an unreachable host.

CheckMemoryConfig: OSD memory target too high

The sum of configured OSD memory targets on a server exceeds the server's total RAM.

Usual causes: OSDs were added to a server without re-tuning osd_memory_target downward, risking OOM kills under load.

CRUSH

MetadataNotOnSsd: Metadata pool on HDD

A metadata-heavy pool (e.g. an RGW metadata pool) is mapped by a CRUSH rule that does not target SSD/NVMe (or DB-on-SSD) OSDs, even though such a rule exists in the cluster.

Usual causes: the pool's CRUSH rule was never switched to the fast-media rule after SSDs were added, hurting metadata operation latency.

MinSizeTooLow: Insufficient pool redundancy

A pool's min_size is 1 (or equals k for erasure-coded pools), meaning it can serve writes with zero redundancy margin.

Usual causes: the pool was created with a permissive default, or min_size was lowered temporarily during a recovery event and never restored. A single further OSD failure can then put data at risk.

MinSizeTooHigh: Insufficient pool availability

A pool's min_size equals its size (or k+m for erasure-coded pools), so the pool becomes unavailable as soon as a single OSD goes down.

Usual causes: min_size was set equal to size by mistake, or a resilience setting was copied from a different pool profile.

MDS

CephFsAllowStandByReplay: CephFS standby replay disabled

A CephFS filesystem does not have standby-replay enabled.

Usual causes: the filesystem was created before standby-replay was recommended, or it was disabled to save resources without reviewing the resulting failover-speed trade-off.

CephFsNotEnoughStandby: Insufficient CephFS standby MDSs

A filesystem using standby-replay has fewer replay MDS than active MDS, or the cluster has zero MDS in general standby.

Usual causes: MDS count was not scaled up alongside the number of active ranks, or standby MDS were removed during resource trimming. This delays failover if an active MDS goes down.

CephfsGuardDetection: CephFS Guard detected suspicious activity

CephFS Guard saw a pattern of file activity on a CephFS filesystem that resembles ransomware, such as a client rewriting or renaming a large number of files in a short time.

Usual causes: a compromised client encrypting files, or a legitimate bulk operation (a large migration, a backup restore, or a mass re-encryption) that happens to look the same. Check which client caused it before assuming an attack.

RBD Mirror

RbdMirrorPeerMissing: RBD Mirror peer missing

RBD mirroring is enabled on a pool, but no mirror peer is registered.

Usual causes: mirroring was turned on before the peer cluster/bootstrap token was configured, or a peer was removed without disabling mirroring.

RbdMirrorDaemonMissing: RBD Mirror daemon missing

Pools expect to receive mirrored data, but no rbd-mirror service is running.

Usual causes: mirroring was configured on the receiving side but the rbd-mirror daemon was never deployed, or it was stopped/removed.

iSCSI

IscsiLegacyCapacity: iSCSI disks affected by data-loss bug

A kernel-backstore iSCSI image does not explicitly disable emulate_legacy_capacity, which has already lost the data in the last 512-byte sector of that image.

Usual causes: the image was created with an older croit version before this setting was defaulted to off. See the linked blog post in the UI for remediation steps.

IscsiInsufficientGateways: Only one iSCSI gateway configured

An iSCSI service has fewer than two gateway servers assigned.

Usual causes: the service was set up for testing with a single gateway and never extended for production HA. A single gateway is a single point of failure for that service's initiators.

NVMe-oF

NvmeOFConfigErrors: NVMe-oF configuration errors

One or more NVMe-oF gateway services failed to apply their configuration.

Usual causes: a gateway host is unreachable, a subsystem/namespace configuration conflicts with existing state, or the NVMe-oF service crashed mid-reconfiguration.

NvmeOFSubsystemWithoutStandby: NVMe-oF subsystem without a standby

An NVMe-oF subsystem is served by one target service although its cluster has more, so the initiators have no second path when that target fails.

Usual causes: the cluster was set up before croit 2609, which stored every target service after a cluster's first as Inaccessible, or a standby runs on a server whose image has an SPDK older than 26.05, which croit does not let serve beside another server. Failover needs a Non-optimized standby the initiator can fall back to.

How to resolve it: follow the warning's link to the cluster's subsystems page, select the subsystem, and set a second service to Non-optimized under Access States. Where a server's image is too old, the service's hint and the refusal name it: boot that server from an image with SPDK 26.05 or later first.

S3

ConnectionLimitAboveRgwCapacity: S3 request limit too low for HAProxy

An S3 server behind an HA group handles fewer requests at once than HAProxy opens connections to it, so the surplus queues inside the S3 server instead of in HAProxy, where a timeout would bound it and the statistics would show it. It shows up as S3 latency under load, with both sides looking correct on their own.

Usual causes: the group's "Max connections per S3 server" was raised without a matching change to rgw max concurrent requests, or that Ceph setting was lowered after the group was tuned.

How to resolve it: press the warning's button. It raises rgw max concurrent requests to the highest "Max connections per S3 server" among the affected groups, in every Ceph section that applies to those gateways, and never lowers a value. Saving a group above the current limit offers the same raise.

S3SignatureCheckRelaxed: S3 signature check is relaxed

This cluster accepts S3 requests whose signature does not cover every header they carry. Ceph 19.2.6 and 20.2.4 reject those by default, because accepting them lets a client attach x-amz- headers the signature never covered (CVE-2026-54330). croit relaxes the check for a multisite setup, because a site that has not been updated yet signs the metadata writes it forwards to its peers the old way, and an updated peer would reject them.

Usual causes: croit relaxed the check while this cluster, which is part of a multisite setup, moved onto a Ceph release that enforces it. An operator can also set rgw sigv4 insecure by hand on the Ceph configuration page, globally or for a single gateway; the warning covers both.

How to resolve it: update every site in the multisite setup to Tentacle 20.2.4 or later, Squid 19.2.6 or later, or a newer Ceph release. Then press the warning's button. It removes the option so the cluster uses Ceph's default, and the warning disappears, and croit does not set it again on a cluster whose gateways already enforce it. Until every site is updated, leaving the check relaxed is the deliberate trade: a site still on an older Ceph loses the metadata writes it forwards here the moment the check is enforced again.

RgwStsKeyVulnerable: RGW STS key needs to be renewed

This cluster authenticates S3 requests with STS, and the rgw sts key at least one object gateway resolves is insecure: it is not a key on the authenticated cipher. Such a token carries the identity fields it grants, so a holder of any valid session token can alter their own token into an administrator one (CVE-2026-39944).

Updating Ceph does not close this by itself. Tentacle 20.2.4 and Squid 19.2.6 pick the cipher from the key itself: a key generated on the fixed release carries aes256k and gets authenticated encryption, while the sixteen-character secret every earlier release demanded keeps the vulnerable one. A cluster that used STS before the update therefore stays exposed after it, and Ceph raises no health check to say so.

Generate the key after the update, not before. ceph-authtool --gen-print-key on an older Ceph prints a key on aes, the cipher this flaw lives in, and croit reports such a key as vulnerable however well formed it is.

Usual causes: STS was enabled before the fixed Ceph release, so rgw sts key holds a secret in the only shape the older Ceph accepted. A gateway that resolves no key at all is covered too, whether because nothing sets one or because the key was set on a different Ceph section: croit reads the value each gateway inherits, not whether the cluster has a good key somewhere.

How to resolve it, in this order: update every object gateway to Tentacle 20.2.4 or later, Squid 19.2.6 or later, or a newer Ceph release. An older gateway accepts only the sixteen-character key, so rotating first breaks STS for its clients. Then generate a key with ceph-authtool --gen-print-key, set rgw sts key to it on the Ceph configuration page for every gateway in the zone (every zone in the realm, for a multisite setup), and restart the gateways. The warning clears itself on the next advisor pass.

There is one key and no period where both are accepted, so the rotation invalidates every outstanding session token: clients call GetSessionToken or AssumeRole again to get new temporary credentials. An operator who accepts the risk, or who cannot rotate yet, can press the card's Dismiss this warning button. That dismissal outlives a croit restart; to bring the warning back, set the advanced croit setting croit rgw sts key warning dismissed to false on Croit > Settings.

OS

HostOsUpdateAvailable: OS update available

A newer default OS image exists than the one currently marked default for the architecture (x86/ARM).

Usual causes: croit shipped a new OS image (e.g. with security fixes) since the cluster's default was last set.

RunningImageMismatch: Server reboot needed

One or more servers are running a different OS image than currently configured.

Usual causes: the configured image was changed after the server last booted. A reboot/PXE cycle is needed to apply it.

HostOsImageDeprecated: Deprecated OS image in use

A server is running an OS image that has been marked deprecated.

Usual causes: the cluster has not been rebooted/updated since a newer image superseded the deprecated one.

DuplicateNicNames: Duplicate NIC names

croit has two or more entries for one OS interface name on a server, so it cannot tell which of them describes the interface that is really there.

Usual causes: a network card was replaced, so croit still has the old card's entry under the same name. "Remove duplicate NICs" resolves that: it asks the server for a fresh hardware report and then keeps a single entry, carrying over any bond, VLAN, or service configuration attached to it. A group is left for manual review when more than one of its entries carries such configuration, because croit cannot choose which one survives.

Software interfaces croit does not manage raise the same finding as a warning rather than a critical problem, because nothing is at risk: the entries are stale bookkeeping. The kernel gives an interface such as a dummy a new MAC address every time it is created, and croit identifies an interface by its MAC, so each recreate adds another entry. Pin the MAC in the hook script that creates the interface to stop that, as shown in Extra network interfaces. croit clears the leftover entries itself as soon as the server reports its hardware again.

Backup

Every backup croit creates, where it lands, and how to restore it is described in Backups.

BackupNotConfigured: Management node backup not configured

No automatic cloud backup of the management node is configured on your cluster. If you would rather not use the croit cloud, you can also configure backing up to your own S3 buckets instead.

Usual causes: backup setup was skipped during initial installation.

MonBackupFailed: Database backup to a MON disk failed

A scheduled backup of the croit database to a MON disk failed.

Usual causes: the target MON disk ran out of space, became unreachable, or has permission/mount issues.

CloudBackupFailed: Cloud backup failed

A scheduled cloud backup job failed.

Usual causes: invalid or expired cloud credentials, network connectivity issues to the backup endpoint, or the remote bucket/quota being unavailable.

S3BackupFailed: S3 backup failed

A scheduled backup of the croit database to S3 failed.

Usual causes: invalid or expired S3 credentials, the endpoint being unreachable, or the target bucket being missing, full, or write-protected.

MGR

DuplicateMgrServicesOnServer: Duplicate MGR services found

A server has more than one MGR service database entry.

Usual causes: a MGR service was re-added without removing a stale entry, often after a server rename or reinstall.

Croit

AutoUpdateFailed: croit update failed

An automatic croit update task failed.

Usual causes: the update package could not be downloaded, disk space ran out during extraction, or a post-update step (e.g. container restart) failed.

AutoUpdatesDisabled: Automatic croit updates disabled

Automatic croit updates are turned off on this cluster, and nobody has been asked about them. The cluster stays on its current croit version until someone updates it by hand.

Usual causes: the cluster was installed before croit offered the automatic-update step during setup, so the setting was never turned on.

The recommendation offers to enable automatic updates for you, or to dismiss it if you prefer to update by hand. Dismissing it is permanent; the settings themselves stay available under Maintenance > Croit Updates. Offline clusters never show it, since they cannot reach a registry to update from.

CronScheduleNeedsAttention: Cron schedule needs attention

An RBD or CephFS snapshot schedule, or the croit auto-update schedule, could not be carried over exactly when croit switched from Quartz to plain UNIX cron. Its previous and (if any) current schedule are named in the warning.

Usual causes: the old schedule used a Quartz-only feature UNIX cron has no equivalent for, such as "the last day of the month" or "the third Friday". Where a close UNIX cron equivalent exists, the schedule keeps running on it; where none does, the schedule is turned off. Either way, the warning names both the previous and (if any) current schedule, and offers an "Accept" button for every schedule that is still running: pressing it keeps the schedule as shown and clears the warning. A link to the schedule's own settings page is offered too, for setting up a new schedule instead, which also clears the warning.

AmbiguousMacIdentity: Duplicate management MAC addresses

A duplicated MAC address is used for more than one server's management interface. croit picks one of the servers to boot as, which one is undefined, so the wrong server can come up under this identity until the duplicate is resolved.

Usual causes: two live servers whose management interfaces share the same MAC (a cloned VM, a vendor MAC collision, or a MAC set by hand). Or a server was retired and its management NIC was moved to another machine.

MultipleDefaultGateways: Multiple default gateways configured

A server's network interfaces/VLANs resolve to more than one distinct default gateway address.

Usual causes: overlapping or duplicated network/VLAN configuration assigns conflicting gateways to the same server.

NoDefaultGateway: No default gateway configured

None of the cluster's configured networks have a default gateway set, so servers cannot reach other networks.

Usual causes: a network was set up without a gateway by mistake. This warning does not appear for clusters running in offline mode, since air-gapped clusters commonly have no gateway anywhere by design.

AddressOnBondMember: Address on a bond member

An address is configured on a bond member, or a VLAN on one, instead of on the bond. A bond member has no network presence of its own, so the address cannot be reached.

Usual causes: the address was never moved off the NIC when it was bonded, or an HA group or SMB cluster still binds to the member interface. Move the address to the bond instead.

IpAddressConflict: IP address conflict

Another device answers for an address croit configured on a running server. Every minute, croit asks each server whether any other device on its networks answers for the server's addresses and for the virtual IPs it currently holds. The finding names each device that answers: a croit server by its hostname, any other device by its MAC address. Traffic for the address reaches either device, which shows up as connection resets and as SSH reporting a changed host key.

Usual causes: the address was assigned to another machine or appliance on the same network, a server's address was added by hand on another server, or two servers hold the same virtual IP at once. Make sure only one device answers for the address. The finding clears on the next check once no other device answers.

VipOutsideInterfaceNetwork: Virtual IP on an interface outside its network

Virtual IPs are bound to an interface without an address in their network. Where that network is the Ceph public or cluster network, Ceph daemons on the affected servers can pick a virtual IP as their own address and fail to start.

Usual causes: an interface address was moved to another interface or a bond while the virtual IP stayed bound to the old one, a virtual IP was moved to another network and the servers' interfaces were not changed after it, the binding predates croit's check, or a network was declared later that covers the virtual IP. Bind the virtual IP to the interface in its network:

• HA group (keepalived): edit the group's servers, or its HA Proxy servers where HA Proxy holds the address, under Object Storage > HA Groups, or on the NFS cluster's High Availability page.
• HA group (keepafloatd): its interfaces cannot be changed, so delete the group and create it again with each server's interface in that network.
• croit-nfs: edit the interfaces on the NFS cluster's High Availability page.
• SMB: remove the server on the cluster's Servers page under File Storage > SMB and add it again with that interface.

Where a group's or cluster's virtual IPs lie in several networks and no single interface of a server has an address in all of them, no choice of interface places every one: keep them in one network.

BootIpNotFound: Boot IP not available

A server's configured boot IP/interface no longer exists on the host.

Usual causes: the network interface was renamed, replaced, or reconfigured outside of croit. PXE boot fails until the configuration is corrected.

BootNetworkNetmaskMismatch: Boot network prefix mismatch

A server's live network interface has a different prefix length than the netmask configured for its boot network.

Usual causes: the boot network's netmask was changed in croit without updating the interface configuration on the host, or vice versa.

NTPUnconfiguredInOfflineMode: NTP server not configured

The cluster is running in offline mode but no NTP server is configured.

Usual causes: offline mode was enabled without providing a local NTP source, leaving nodes without a time-sync target. Clock drift between nodes can then cause authentication and cluster-map timing issues.

LegacyNtpConfigFile: Legacy NTP configuration ignored

A /config/ntp.conf file is present on the management node. The management node uses chrony, so croit ignores this legacy file.

Usual causes: the file was written for the ntpd service previously used on the management node. Configure standard NTP servers with the croit ntp server setting, which applies to the management node and every storage server. For custom options, edit the chrony-management template under Config > Templates. Then delete /config/ntp.conf to clear the warning.

NotSynchronised: Management node clock not synchronized

The management node reached none of its NTP servers, so its clock is drifting.

Usual causes: the servers in the croit ntp server setting are not reachable from the management node, which is common on an offline cluster where the setting names hosts only the storage network can reach. The warning lists the servers the management node could not reach, so correct those in the setting. The storage servers read the time from the management node unless that setting gives them servers of their own, so Ceph starts reporting clock skew between the monitors once they disagree.

UnhealthyDisks: SMART disk health warnings

One or more disks report SMART health warnings.

Usual causes: disks approaching end-of-life, reallocated sectors, or other early-failure indicators reported by SMART. Plan to replace the affected disk before it fails outright.

BrokenEncryptedOsds: Imminent encrypted OSD data loss

An encrypted OSD's DB/WAL partition fails its passphrase check.

Usual causes: an interrupted encryption operation or a partially completed disk-replacement/rekey step left the encryption state inconsistent. Do not reboot the affected host; contact support.

SshdMisconfigured: SSH configuration not applied

A server's SSH daemon configuration was not applied successfully.

Usual causes: a manual edit to sshd_config conflicts with croit-managed settings, or the SSH service failed to reload after a configuration push.

SambaRecoveryLockUpgradeAvailable: Legacy CTDB recovery lock in use

A Samba service still uses the legacy CephFS-file-based CTDB recovery lock instead of the RADOS-based helper lock.

Usual causes: the service was created before the RADOS-based lock was introduced and has not been migrated yet.

FailedMultipathPaths: Failed disk paths

A multipathed disk reports one or more failed (inactive) paths.

Usual causes: a cable, HBA port, or switch/fabric issue on one of the redundant paths. The disk is still reachable via its remaining path(s), but redundancy is reduced.

VulnerableSambaADAuditLogs: Active Directory credentials exposed

Audit logs from an older croit version recorded Active Directory admin credentials in plain text.

Usual causes: the cluster ran a croit version predating the audit-log redaction fix while Samba AD authentication was configured. Rotate the exposed credentials after upgrading.

VulnerableSambaSimpleAuditLogs: SMB passwords exposed

Audit logs from an older croit version recorded SMB root/croit-ro passwords in plain text.

Usual causes: same as VulnerableSambaADAuditLogs, for simple (non-AD) Samba authentication.

DeprecatedSyslogConfig: Deprecated syslog configuration

The deprecated syslogTarget configuration option is set.

Usual causes: the cluster was configured before VictoriaLogs became the recommended log destination and has not switched over.

LicenseExpirationWarning: License expires soon

The croit license will expire within 7 days.

Usual causes: license renewal has not been processed yet ahead of the expiry date.

LicenseAlreadyExpired: License has expired

The croit license has expired.

Usual causes: license renewal was not completed before the expiry date. Enterprise features stop working until a new license is applied.

CleanUpMetricsAndLogs: Legacy logs and metrics data found

Old logs/metrics from before the migration to VictoriaLogs/VictoriaMetrics are still present.

Usual causes: the migration to VictoriaLogs/Metrics completed, but the one-time cleanup step was never run.

QuarantinedLogPartitions: Corrupted log data was moved aside

A day's worth of stored log data was corrupted, so croit moved it to /logs/quarantine on the management node to let log collection start again. The recommendation names the day it lost, or, when several partitions went, how many and the span they fall in, plus how much disk space they hold. It offers a button that deletes the data.

Deleting the quarantined data is what gets the disk space back. croit has no recovery for it and its log retention only covers the live log storage, so nothing else ever clears the quarantine.

Worth looking into is what corrupted the data in the first place, since the usual causes say something about the management node rather than about logging. Contact croit support if you cannot explain the corruption, if you would like a hand, and especially if it keeps coming back.

Usual causes: the management node lost power, or its disk is failing or ran out of space while the log storage was writing, leaving a partition without its index.

LogPartitionQuarantineFailed: Log collection has stopped

Corrupted log data was found but could not be moved out of the way, so log collection is not running. No new logs are being recorded until this is resolved.

Usual causes: /logs on the management node is full or not writable. croit retries every time the log service starts, but it cannot clear this on its own, so contact croit support if freeing up space or fixing the permissions does not bring logging back.

LegacySambaConfig: Legacy Samba configuration

Some SMB gateways still run the older Samba configuration layout.

Usual causes: the cluster's SMB gateways were set up before the current configuration format existed and were never migrated. The recommendation offers a button that upgrades them.

ManagementNodeUnderprovisioned: Management node undersized

The management node's actual CPU/RAM/disk falls below what is recommended for the cluster's size.

Usual causes: the cluster grew (more OSDs/servers) without scaling up the management node's resources to match.

ManagementNodeInfoParsingFailed: Management node resource check failed

croit could not determine one of the management node's CPU/RAM/disk resource values.

Usual causes: an unusual virtualization layer or restricted /proc//sys access prevents croit from reading the expected system information; contact support.

CroitVersionWarning: croit version requires attention

The croit API published a warning for the exact croit version currently running.

Usual causes: a known issue was discovered in that specific release after it shipped. The warning text and severity come from croit's update-info service, so they vary by version.

CroitUpdateAvailable: croit update available

A newer croit version is available than the one currently installed.

Usual causes: none required; croit ships regular releases, so this is expected and not a sign of local misconfiguration.

DockerAPIVersionTooOld: Docker version too old

The Docker daemon on this host reports an API version below what the Docker tools bundled in the croit container require.

Usual causes: the host runs Docker older than version 25 (API 1.44). Features that read container logs through those tools, such as croit's own log collection and the support VPN's logs, fail until Docker is updated on the host.

DockerSocketNotAvailable: Docker socket not available

croit could not connect to a Docker socket, and no DOCKER_SOCKET override file exists.

Usual causes: the Docker socket was not mounted into the croit container, so auto-update and self-management features are unavailable.

DockerSocketNotWorking: Docker socket not reachable

A Docker socket is mapped but connecting to it still fails, for a reason other than the more specific cases below.

Usual causes: a stale or wrong socket path, or a Docker daemon that is not running on the host.

DockerSocketPermissionDenied: Docker socket permission denied

Connecting to the Docker socket fails with a permission error.

Usual causes: SELinux/AppArmor policies or file permissions on the host prevent the croit container from using the mounted Docker socket.

DockerCroitContainerNotFound: croit container not found

croit can reach Docker but cannot find its own running container by the expected name.

Usual causes: the croit container was renamed away from croit, breaking self-management features that look it up by name.

DockerLegacyVolumes: Legacy Docker volume setup detected

croit's data is stored using the older bind-mount volume layout instead of named Docker volumes.

Usual causes: the installation predates the named-volume layout and has not been migrated.

DockerNotRunningInContainer: croit is running outside Docker

Docker is reachable, but the croit process itself does not appear to be running inside a container.

Usual causes: croit was started directly on the host instead of via the supported Docker deployment, which is unsupported.

DockerCapSysTimeNeeded: SYS_TIME capability missing

The croit container is missing the SYS_TIME Linux capability, and NTP management is not disabled.

Usual causes: the container was started with a capability set that dropped SYS_TIME, preventing croit from managing system time.

DockerCapNetAdminNeeded: NET_ADMIN capability missing

The croit container is missing the NET_ADMIN capability, and DHCP/dnsmasq management is enabled.

Usual causes: the container was started with a restricted capability set that prevents croit's DHCP stack from configuring network interfaces.

LowDiskSpaceManagementNode: Low disk space on management node

One of the management node's monitored volumes (/logs, /stats, /var/lib/mysql, or /) has free space at or below its configured minimum threshold.

Usual causes: log/metric retention outgrew allocated disk space, or the database grew faster than expected. Free up space or extend the volume.