Enabling `.persistence.enabled` leads to `/var/www/html/lib` and probably other files not being created about helm HOT 5 CLOSED

Adding the following to my values.yaml allowed everything to boot normally (eventually), so if your StorageClass is too slow to let the entrypoint.sh script complete before crashing, try this:

livenessProbe:
  initialDelaySeconds: 7200
readinessProbe:
  initialDelaySeconds: 7200
startupProbe:
  initialDelaySeconds: 7200

from helm.

#584 this issue just got transferred here, maybe it is related?

from helm.

I think I'm having this issue as well. Whenever I try to do an upgrade, my occ binary doesn't always update to the latest file

from helm.

Same issue here, meaning I cannot access the nextcloud instance at all as the pod goes into a CrashLoopBackOff status

from helm.

In my case I'm pretty sure its my NFS StorageClass that is at fault here. I'm getting abysmally slow read times (but not write) for some reason that I cannot replicate outside the container. Doing ps -aux | grep entrypoint.sh inside the nextcloud container shows that the entrypoint script is running, but getting interrupted when the container crashes due to the liveness probe.

I was able let the entrypoint script finish running by creating another Nextcloud container without the liveness probes to prevent timing out before (eventually) finishing. There were a lot of volume mounts, so I just pulled the generated Deployment yaml from my helm install using helm install nextcloud nextcloud/nextcloud --dry-run --debug -f values.yaml and removed the liveness probes to prevent it from crashing. I deployed it after deploying the nextcloud helm chart and left it for a few hours. When I came back everything was up.

EDIT:
There are switches to disable the probes already available in values.yaml 💀

from helm.