Known Issues in Lightbits 3.19.1
ID | Description |
|---|---|
48930 | In a rare situation where during a rebuild at least two snapshots are deleted, one containing data and a higher one containing a trim to the same blocks, the trim might be applied to the next existing version/snapshot - thus losing the valid data in it. |
48546 | When SSD Journaling is enabled and the journal devices are allocated from the same device pool as the data devices, the node-manager service can fail to start after a data drive is lost. No workaround is currently available. |
48532 | The node-manager service can fail to start if the number of drives present falls below the minimum required for the node's configured layout, for example, after a drive failure, power loss or planned maintenance. In earlier releases, the node started with the missing drive marked as failed; in affected releases it does not start at all. Workaround: Set |
48435 | On some AMD EPYC servers, NVMe SSDs can report I/O timeouts. This can cause a storage node to be marked as failed, and while the node is out of service, volumes with reduced protection can become read-only. Workaround: Disable PCIe Relaxed Ordering in the server BIOS. |
48205 | When a large number of clone volumes are created from a small number of shared snapshots and a node is then restarted or replaced, some of those clone volumes can become stuck retrying volume creation, which can leave the node's protection groups unable to complete their rebuild. This issue is fixed in v3.20.2 and v3.21.1. |
48041 | In affected versions, when a management operation fails repeatedly, the delay between retries eventually drops to almost zero: after about 1.5 minutes of consecutive failures in v3.18.x, or about 16 hours in v3.19.x and v3.20.x. The continuous retries can keep a CPU core busy and flood the logs, pushing out older log entries needed to investigate the original failure. This issue is fixed in v3.18.4, v3.20.2, and v3.21.1. |
48012 | In rare cases, a volume or snapshot that is created while a server's node-manager service is down (or the server is powered off), and deleted just as node-manager recovers, can remain on that server. If the leftover is a clone, or a snapshot of a clone, deleting the snapshot it was created from never completes: that snapshot stays in Deleting state and blocks new operations on its source volume. A leftover object can also prevent a rebuild from completing. Data is not lost, and affected volumes remain accessible and continue to serve I/O. Workaround: Contact Lightbits Support to remove the leftover volume or snapshot. This issue is fixed in v3.18.4 and v3.21.1. |
47753 | Changing a node's Permanent Failure (PF) threshold can behave unexpectedly if the node is already Inactive. Lowering the threshold to a value that has not yet elapsed does not take effect until the original threshold time passes, and raising the threshold can prevent the node from reaching Permanent Failure at all. Workaround: Change a node's PF threshold before maintenance that will make it inactive. To shorten the threshold of a node that is already inactive, use a value that has already elapsed. |
47343 | In rare cases, deleting a snapshot while a rebuild is in progress can raise |
47300 | If the cluster manager's connection to the cluster's internal coordination service is interrupted (for example, due to a leader change, network disruption, or a brief service restart), the cluster manager's view of cluster servers can stop updating entirely, with no automatic recovery. Workaround: Restart the cluster-manager service to restore normal operation. |
46869 | If a snapshot is deleted while a rebuild is in progress, the rebuild can fail and display log errors similar to "Exceeded maximum number of 50 write attempts". The failed rebuild is not retried automatically, so the affected protection group remains degraded. Workaround: Contact Lightbits Support to restart the node instance on which the rebuild failed. This issue is fixed in v3.18.3, v3.20.2, and v3.21.1. |
46633 | On large clusters (for example, clusters with more than 1,000 protection groups), evicting a server can fail with a timeout before any data has been moved, because the cluster manager takes a long time to prepare the eviction. Workaround: Increase the |
46209 | The bundled Grafana Alloy log-streaming agent ships with Grafana's anonymous usage statistics reporting enabled by default. The report is sent out on a fixed four-hour schedule to https://stats.grafana.org/. In air-gapped or firewalled deployments, these attempts fail and produce recurring error entries in the journal. In connected deployments, they could represent an unsanctioned outbound connection to a third party. The exact list of fields collected is documented at https://grafana.com/docs/alloy/latest/data-collection/. |
45729 | When SSD journaling is configured with multiple NVMe devices, cluster cleanup does not remove the RAID (mdadm) arrays created by Lightbits. Before re-deploying on the same servers, manually remove these arrays using mdadm. |
45625 | After running the Ansible node cleanup, leftover journaling RAID (mdadm) devices can keep drives attached, so the next installation detects fewer NVMe drives than expected. Workaround: Stop the mdadm RAID device manually before reinstalling. This issue is fixed in v3.21.1. |
45202 | When a volume is created with lbcli, any part of a label key before a hyphen is dropped. For example, --labels="pve-vmid=100" is saved with the key "vmid" instead of "pve-vmid". Workaround: Avoid hyphens in label keys, or create the volume through the REST API, which is not affected. |
45157 | During a node power-up after an abrupt shutdown, the node's reported power-up progress can reach 100%, drop back to 50-60%, and then climb to 100% again. This affects the reported percentage only. Recovery completes correctly, and the node returns to service only when it is actually done. No workaround is needed. |
44875 | lbcli and REST documents describe that you can evict a server with 1x volumes with the force flag, but this is not possible. It also indicates that you can evict a server even if it could lead to risk of service loss using the force flag. However, force will only allow you to evict a server if its nodes are unavailable but still requires other nodes to be active. |
44819 | Lightbits release 3.19.1 introduced stringent validation of any REST requests sent to the Lightbits api-service. While previous faulty requests that had some non-supported fields or corrupted fields would have been accepted, and those fields would be ignored, the 3.19.1 rejects such malformed requests. |
44762 | Log stream to a rsyslog target only supports the secured mode of operation. Unsecured mode is not currently supported. |
44673 | In rare cases, performing a KEK rotation while simultaneously executing a high volume of volume/snapshot control plane operations could result in increased etcd contention. This affects only customers utilizing cluster-level encryption with the KEK rotation API. |
44642 | Update volume commands issued from VCP V1.4.0 (or older) to a Lightbits cluster running Lightbits 3.19.1 release or newer will fail due to invalid arguments. Running with Lightbits releases 3.20.1/3.21.1 or newer will require updating |
44464 | In affected versions, if the server selected as the new primary for an in-progress volume migration becomes permanently failed, the migration does not abort and instead retries indefinitely, repeatedly updating the cluster state. This issue is fixed in v3.21.1. |
44435 | pmem_init and lbe executables are linked using staticx and therefore require /tmp to be mounted with the exec option enabled; otherwise, these executables will fail to run with "permission denied". |
44386 | Grafana dashboards may display a short spike of negative BW/Throughput rate, following the stoppage of a Lightbits service. |
44383 | When cluster-level encryption is enabled, deleting a server that hosts the active Cluster Manager (CM) could prevent subsequent server additions from completing successfully. After removing such a server from the cluster, stop the CM service on it or shut the server down. |
44382 | When a node manager is offline, if the sole journal NVMe device is removed or fails and becomes invisible at the OS level, the failed device might not be detected upon node restart. The node will resume normal operation, but without journaling protection. This affects only nodes configured with a single journal NVMe device. |
44334 | In affected versions, stopping or restarting the node-manager service on a server (for example, during maintenance or an upgrade) can leave the data-path service hung while it waits for a configuration update that never arrives, which delays or blocks the server's shutdown. This issue is fixed in v3.18.3 and v3.21.1. |
44159 | In a rare case, a rebuild could fail after the following sequence: two or more snapshots are created while a node is inactive, and then all are deleted with at least one deletion occurring after the node's recovery had started. This has been resolved. |
44124 | Lightbits 3.19.1 enforces consistent formatting for Protocol Buffer (protobuf) duration fields: values must now be expressed in seconds (e.g., 3600s). Alternative unit formats such as 60m or 1h are no longer accepted. |
43471 | [Log Streaming] Log lines longer than the destination rsyslog server's |
42963 | When SSD journaling is enabled, if the frontend fails due to a non-journal-related issue, the Node Manager (NM) might incorrectly classify the failure as a journal device failure, causing the NM to remain inactive and enter a Permanently Failed state. When SSD journaling is disabled, a frontend failure does not impact the failure scenario. However, users might receive a spurious "journal device failed" event even when journaling is not in use. This is cosmetic only and does not reflect an actual journal issue. |
40883 | When using the vCenter Plugin (VCP) to upgrade a cluster to Lightbits 3.17.1 or later, the upgrade fails because VCP cannot parse the updated version format. To complete the upgrade, use the Lightbits core CLI or REST API directly. |
37830 | In extremely rare cases, a node may not recover to an active state if an I/O error or bad block is encountered on an underlying SSD during its startup sequence. This prevents a key service (gftl) from initializing correctly and may require manual intervention (such as removing the failed SSD from the system) to allow the node to complete its recovery successfully. |
37505 | In a rare combination of events, the |
28027 | In specific circumstances, the server upgrade status may not reflect the correct state after a successful retry. This occurs in the following sequence: 1. A server is upgraded to version x.y.z. 2. The operation fails (for example, due to a timeout); however, the server binaries are successfully updated to version x.y.z. 3. The upgrade is retried to version x.y.z — this step is skipped internally, as the binaries are already up to date. 4. The upgrade status continues to show the previous failed operation, even though the retry completed without error. |
© 2026 Lightbits Labs™