longhorn/longhorn

Describe the Bug If a v1 backing image loses all its file copies and its download URL becomes invalid, Longhorn still blindly and unlimitedly retries recovering it (by trying to download the data from the invalid URL). This is meaningless and causes the whole Longhorn system to be flooded with the related error logs, which may confuse users. To Reproduce No response Expected Behavior May need to set a max retry count for the recovery, or add a backoff window for the retry Support Bundle for Troubleshooting The backing image manager was flooded with these logs: 2026-07-16T00:50:28.631713994Z time="2026-07-16T00:50:28Z" level=debug msg="Sync Service: initializing sync file /data/backing-images/vmi-083b2476-39aa-4847-a99d-8722ac3345eb-a70176d8/backing" func="sync.(*Service).checkAndInitSyncFile" file="service.go:323" component=sync-server listen=":8001" 2026-07-16T00:50:28.631716444Z time="2026-07-16T00:50:28Z" level=info msg="SyncingFile: cannot to reuse the existing file, will clean it

Is your improvement request related to a feature? Please describe Follow-up to #12225, which added longhornManager.resources to the chart (thanks!). The value is applied only to the longhorn-manager container. The hardcoded pre-pull-share-manager-image sidecar in the same DaemonSet pod has no resources and no way to set any: # chart/templates/daemonset-sa.yaml (v1.11.3 and v1.12.1) - name: pre-pull-share-manager-image imagePullPolicy: {{ .Values.image.pullPolicy }} image: ...longhorn-share-manager:... command: ["sh", "-c", "echo share-manager image pulled && sleep infinity"] Kubernetes only assigns a pod-level cgroup memory.max when every container in the pod has a memory limit. With the sidecar unlimited, setting longhornManager.resources.limits.memory still leaves the pod-level cgroup at max. This matters on platforms whose OOM handling ranks pod-level cgroups. For example, the Talos Linux (v1.12+) userspace OOM controller's default ranking protects pods whose pod cgroup has me

Describe the Bug After deleting old backups ( the corresponing volume is not needed anymore) via longhorn the attached s3 storage (local minio) needs some time to also clean up the now empty folder structure. Long wrongly assumes it must be able to find the volume.cfg file if the structure exists. It would be more reasonable to see a missing volume.cfg as a deleted indication. Longhorn v1.10 .0 (harvester 1.7.1) {"time":"2026-08-04T06:47:33.240903134Z","stream":"stderr","logtag":"F","message":"time=\"2026-08-04T06:47:33.24071255Z\" level=error msg=\"Failed to list backups from backup target\" func=\"controller.(*BackupVolumeController).reconcile\" file=\"backup_volume_controller.go:283\" backupVolume=pvc-cdbee6ab-7cfd-49a3-b63a-6e6fb8e9d546-ca82898e controller=longhorn-backup-volume error=\"cannot find backupstore/volumes/0b/0c/pvc-cdbee6ab-7cfd-49a3-b63a-6e6fb8e9d546/volume.cfg in backupstore\" node=harvester-6vd2k","kubernetes_namespace":{"name":"longhorn-system","labels":{"app.ku

Describe the Bug When the v2 data engine is disabled while the block disks are not cleaned up, those block disks will become unavailable, and block the longhorn uninstallation. To Reproduce Enable v2 data engine kubectl -n longhorn-system patch -p '{"value":"true"}' --type=merge lhs v2-data-engine Set block disks for nodes Disable v2 data engine Enable deletion confirmation flag kubectl -n longhorn-system patch -p '{"value":"true"}' --type=merge lhs deleting-confirmation-flag Delete longhorn-system by deploying the uninstall YAML Check the uninstall pod. You will see a bunch of error logs: time="2026-07-20T20:56:07.19641482Z" level=warning msg="Failed to uninstall" func="controller.(*UninstallController).handleErr" file="uninstall_controller.go:309" controller=longhorn-uninstall error="failed to delete nodes: failed to update node annotations to mark for deletion: admission webhook \"validator.longhorn.io\" denied the request: update disk on node ip-10-0-2-50 error: The disk block-di

Describe the Bug The system snapshot created during volume expansion is named expand- using only the target size, with no volume identifier or UUID. When two volumes are expanded to the same byte size only one Snapshot CR can exist for that name. To Reproduce Two Longhorn volumes, both at size X. Expand both to the same size Y at roughly the same time. kubectl -n longhorn-system get snapshot | grep expand -> only one CR named expand- exists. Both on-disk snapshots exist (visible per-volume in the UI as system/hidden). The volume that lost the create race has no Snapshot CR for it. Expected Behavior Each volume's expansion snapshot gets its own Snapshot CR (name disambiguated by volume, as other system snapshots are by UUID). Support Bundle for Troubleshooting no bundle Environment Longhorn version: v1.10.0 Impacted volume (PV): any Installation method (e.g. Rancher Catalog App/Helm/Kubectl): kubectl/kustomize Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version: RKE2 Number o