Chart not working without persistence

[xstasi]

Describe your Issue

If persistence is not enabled then the pod only works the first time, but on subsequent runs it won't find version.php and will attempt to install again.

Wouldn't it be possible to store the information found in version.php elsewhere, such as database or object storage?

Logs and Errors

See example log:

$ kubectl logs -f xxx-nc-nextcloud-bfb76c9c8-ds8gr
Defaulted container "nextcloud" out of: nextcloud, nextcloud-cron
Configuring Redis as session handler
Initializing nextcloud 30.0.6.2 ...
New nextcloud instance
Installing with PostgreSQL database
=> Searching for scripts (*.sh) to run, located in the folder: /docker-entrypoint-hooks.d/pre-installation
==> Running the script (cwd: /var/www/html): "/docker-entrypoint-hooks.d/pre-installation/helm.sh"
==> Finished the script: "/docker-entrypoint-hooks.d/pre-installation/helm.sh"
Starting nextcloud installation
The Login is already being used
Retrying install...
The Login is already being used
Retrying install...
The Login is already being used
Retrying install...
The Login is already being used
Retrying install...

Describe your Environment

• Kubernetes distribution: k3s

• Helm Version (or App that manages helm): v3.17.2

• Helm Chart Version: 6.6.9

• values.yaml:

replicaCount: 1

image:
  flavor: fpm
  tag: 31.0.2-fpm

nginx:
  enabled: true

nextcloud:
  host: xxx
  podSecurityContext:
    fsGroup: 33
  trustedDomains:
    - xxx
    - yy

  phpConfigs:
    zz-memory_limit.ini: |-
      upload_max_filesize=5G
      memory_limit=512M
  configs:
    proxy.config.php: |-
      <?php
      $CONFIG = array (
        'trusted_proxies' => array(
          0 => '127.0.0.1',
          1 => '10.0.0.0/8',
          2 => '1.2.3.4/24',
          3 => '5.6.7.8/24',
        ),
        'forwarded_for_headers' => array('HTTP_X_FORWARDED_FOR'),
      );

cronjob:
  enabled: true

redis:
  enabled: true
  auth:
    enabled: false

service:
  type: NodePort
  nodePort: 30850

internalDatabase:
  enabled: false

externalDatabase:
  enabled: true
  type: postgresql
  host: xxxxx
  database: nextcloud
  user: nextcloud
  password: xxxxx

objectStore:
  s3:
    enabled: false
    accessKey: xxxxx
    secretKey: xxxxxx
    host: xxxx.minio-nc.svc.cluster.local
    bucket: nextcloud-bucket
    ssl: false
    port: 9000


startupProbe:
  enabled: false
  initialDelaySeconds: 240

persistence:
  enabled: false

[biclighter81]

Same problem here

[poggenpower]

Even if there would be a way to store version.php I think you won't get happy with Nextcloud. You need a place where Apps can be stored. I think you don't want to install them on each restart. What's the advantage to not add a few GB for a PVC?

[xstasi]

@poggenpower havin or not having the PVC makes all the difference because if you want to run nextcloud on multiple nodes you need a ReadWriteMany PVC which is computationally expensive. For example I'm using longhorn, and a RWM PVC would mean nextcloud bootstrapping in half an hour instead of a few seconds, because it needs to rsync the whole app to the www root before it does anything.

That is beside the point though. My problem is that the PVC is marked as optional when it isn't. Without a PVC nextcloud just breaks. S3 is posed as an alternative but it isn't, because version.php (or its contents) isn't stored there.

I would like to have the option to have the storage be only on S3, as implicitly advertised by the chart.

[poggenpower]

All the file system requirements and S3 support is simply what nextcloud it self provides/requires. This chars help with the deployment. ¯_(ツ)_/¯ Btw. where have you read in the docs, that a setup is working without any persistence on disk? The only indicator I found was that persistence.enabled is set to false be default.

I am using Longhorn too. To avoid the delay you have two options don't force the the volume to the same node as the nextcould pod (as there is not a lot of data, this should not be a big performance issue) or ensure that pods get created on the same pod each time the get started, this will avoid the sync.

[xstasi]

where have you read in the docs, that a setup is working without any persistence on disk? The only indicator I found was that persistence.enabled is set to false be default.

Never mind the default, the fact that the option exists at all implies that it makes sense to use it. If persistence.enabled is settable, I think one wouldn't be blamed if they thought it could be set to false. As things stand it can't, lest you waste hours of your life trying to understand why nextcloud works only until you delete the pod.

If an option is there it should work at least in some cases. If it doesn't it's a bug, hence the bug report.

I am using Longhorn too. To avoid the delay you have two options don't force the the volume to the same node as the nextcould pod (as there is not a lot of data, this should not be a big performance issue) or ensure that pods get created on the same pod each time the get started, this will avoid the sync.

The pvc was on the same node as nextcloud, longhorn does that by default. For me the performance fix was to set it to RWO, nothing else changed. But again this is off topic.

I understand that persistence.enabled does not work because of a nextcloud limitation, but for me it makes more sense to open the issue here as the problem only appears when deploying on k8s. It's something that should be figured out together between helm and nextcloud proper I think, but one has to start somewhere :)

[poggenpower]

I think the logic that there is an option persistence.enabled=false is because of the migration from docker compose, because docker keeps changes across restarts. Therefore I agree that this is a kind of bug and persistence.enabled should be true by default. IMHO there is a use case for false: If you want to spin up a temporary instance for testing, as the PVC is configured to keep the PV, you need to do additional clean up otherwise.

[wrenix]

Sadly Nextcloud is not willing use a immutibel Image (with per installed apps and Backup of config.php to database). During the developing of tbe dPhoenixSuite and openDesk there was already such a setup: https://gitlab.opencode.de/bmi/opendesk/components/platform-development/images/opendesk-nextcloud-base-layer/-/blob/main/README.md

So sadly, i do not thing i/we should do not spend time again for develop something what never is official supported.

[poggenpower]

If your write changes to a PV or DB in both cases the image is immutable and you have an external persistence layer. Even if I agree that the way how the container bootstraps nextcloud is special, as it runs an installation when starting the first time with a new version. On the other hand this concept is very similar to a migration databases would run in such situation.

[arvinkarimi2005]

I have a serious issue with PVC. Let's say you are developing on Nextcloud and have an S3 backend. You update codes with persistence because the Nextcloud image's entrypoint does not copy to /var/www/html. Your PVC won't update if there are any files, and the helm won't function properly if you remove persistence. Only the configuration, data, and possibly custom app folders should remain.