IBM Verify

 View Only

 ISVD server error when starting the Kubernetes pod during deployment

Michael Kochenburger's profile image
Michael Kochenburger posted Fri July 25, 2025 06:53 AM
Hi,
 
I'm struggling again with a problem that is most likely a beginner's mistake.
I can't get the Virtual Directory Server container to work. I'm getting the following error messages.
Could this have something to do with an incorrect configuration of PersistentVolume and PersistentVolumeClaim?
But they seem to be fine. Has anyone else had the same problem?
 
 
$~/isvd$ kubectl describe pod isvd-server-5f5bb4947f-tf982
(...)
Events:
  Type     Reason   Age                     From     Message
  ----     ------   ----                    ----     -------
  Normal   Pulled   3m48s (x125 over 10h)   kubelet  Container image "icr.io/isvd/verify-directory-server:10.0.4.0" already present on machine
  Warning  BackOff  3m24s (x3012 over 10h)  kubelet  Back-off restarting failed container isvd-server in pod isvd-server-5f5bb4947f-tf982_default(74808e8e-bb5b-4ce7-b4ee-d551ce9c866c)
 
$~/isvd$ kubectl logs isvd-server-5f5bb4947f-tf982
{"instance": {"epochSecond": 1753427529}, "threadId": "0x5db64cc0", "level": "Information", "loggerName": "ISVD Bootstrapper", "message": {"id": "GLPBOO002I", "text": "Bootstrapping the container."}}
{"instance": {"epochSecond": 1753427529}, "threadId": "0x5db64cc0", "level": "Information", "loggerName": "ISVD Bootstrapper", "message": {"id": "GLPCON011I", "text": "Performing the configuration of the server."}}
{"instance": {"epochSecond": 1753427529}, "threadId": "0x5db64cc0", "level": "Information", "loggerName": "ISVD Bootstrapper", "message": {"id": "GLPBOO001I", "text": "Initializing the environment from the template."}}
tar: can't make dir var/isvd/data/schema: Permission denied
tar: can't create directory 'var/isvd/data/schema': Permission denied
tar: can't open 'var/isvd/data/schema/V3.modifiedschema': No such file or directory
{"instance": {"epochSecond": 1753427529}, "threadId": "0x5db64cc0", "level": "Error", "loggerName": "ISVD Bootstrapper", "message": {"id": "GLPUTI001E", "text": "Failed to execute the command: tar (1)."}, "file": {"name": "SVDExec.cpp", "line": 84}}
 
 
$~/isvd$ kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM              STORAGECLASS    VOLUMEATTRIBUTESCLASS   REASON   AGE
isvd-pv   100Mi      RWO            Retain           Bound    default/isvd-pvc   local-storage   <unset>                          17h
$~/isvd$ kubectl get pvc
NAME       STATUS   VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS    VOLUMEATTRIBUTESCLASS   AGE
isvd-pvc   Bound    isvd-pv   100Mi      RWO            local-storage   <unset>                 17h

J. Alejandro Carrillo's profile image
J. Alejandro Carrillo posted Fri July 25, 2025 10:55 AM

Are you referring to the Virtual Directory Server? It appears that you are attempting to deploy the Verify Directory Server instead. If this is the case, you should modify your question. You seem to be facing a permission issue here, so it's most likely related to the PV and PVC configuration. Can you provide more details about the environment? What is the container orchestration you are using to deploy the ISVD server? What type of PV and PVC are you using? From the look of it, it seems you have configured some local volume. If this is the case, make sure the directory on your local system where you are mounting the local volume has all the needed permissions (rwx). 

Michael Kochenburger's profile image
Michael Kochenburger posted Mon July 28, 2025 03:40 AM

Thanks Alejandro. You are right, I meant Verify Directory, not Virtual.
It's a PV of storageClassName local-storage with hostPath /mnt/isvd-data.
Yes, the permissions were not set for the /mnt/isvd-data directory, I guess I expected too much automation here from the startup script.
It would be nice if the permissions were set automatically by the deployment, but that's too much work for a demo environment at this point.

Robert Graham's profile image
Robert Graham posted Tue July 29, 2025 08:33 AM

You should not have to set any permissions. I have deployed this container many times. 
Does your deployment yaml have securityContext? OCP is a bit different from k8s. If you are deploying on OCP please let me know, I can share securityContext and you can test.

spec:
# The name of the service account which has the required
# capabilities enabled for the isvd container.
serviceAccountName: isvd
securityContext:
runAsUser: 1000
runAsGroup: 1000
fsGroup: 1000
Michael Kochenburger's profile image
Michael Kochenburger posted Wed July 30, 2025 06:34 AM

I'm deploying on k8s.
"You should not have to set any permissions.": This is what I expected, but it doesn't work. I've also created a service account 'isvd', no difference.
I have to login to the node where the local-storage /mnt/isvd-data was created and set the permissions manually.

Related Content