kubernetes “volume X already bound to a different claim”

volume X already bound to a different claim when recreating Persistent Volume Claim

I recently encountered an issue in Kubernetes (Azure Kubernetes Service v1.19.7 to be exact) in which a Persistent Volume Claim (PVC) kept giving the error “volume “myvolume” already bound to a different claim.” I do not know what caused this, since there were no other claims to the volume. The PVC kept status Pending and the Persistent Volume (Azure-File) kept the status Released

My Google-Fu could not help me, I found an question on stackoverflow, but there the error was caused by sizing differences in the PV and PVC (a PVC may not claim a larger size than the PV provides). But that wasn’t the case in my environment.

Eventually I found the sourcecode for the Persistent Volume Controller which throws the error and it shows that the error should not pop up if the volume.Spec.ClaimRef == nil (line 416 at the time of writing). So I decided to see if I could find this spec.claimref in the properties of the PV. I use Lens IDE which allows you to simply edit the configuration in a GUI, but kubectl edit should do the same)

kubectl edit pv <pv-name>
(Replace the values between <> with the correct values)

I tried to remove everything under spec.claimRef by simply replacing all text with “{}” but after saving the file, it still retained the original values.

So when playing around with the values, I saw that if I editted the spec.claimRef.name to some other value, that it would be applied immediately, so changes do get saved.

At this point I tried changing the spec.claimRef.uid to the value that I found in the properties of the PVC. And that resulted in a Bound PV and PVC.

To find the uid of the PVC:

kubectl get pvc <pvc-name> --namespace <namespace-name> --output yaml |grep uid
(Replace the values between <> with the correct values)

So for some reason this value is not overwritten with the newly created PVC’s value. (Line 83 in the screenshot) But doing by hand fixed the issue. Atleast for now.

apiVersion: v1
kind: PersistentVolume
spec:
  claimRef:
    kind: PersistentVolumeClaim
    namespace: <namespace-name>
    name: <pvc-name>
    uid: 12345678-1234-abcd-defg-1234567890ab <- The uid of the PVC
    apiVersion: v1
    resourceVersion: '14061061'

Advertisement