Before the start, installing Nextcloud to my Raspberry Pi Kubernetes cluster seemed like a walk in the park. They have a Helm chart, which supports also ARM64, so what could possibly go wrong?

The first problem was that I somehow managed to use deprecated chart and repository. After finding the correct one, things started to proceed to the right direction. My first installation went smoothly and the only problem was that News app was not updating the RSS feeds. After a while I found this issue that explained that the Nextcloud chart does not support system cron and News app requires it.

For a while I thought that I could be living without my daily dose of LWN and Hacker News. I came back to my senses, when I saw sseneca’s solution, which used lifecycle.postStartCommand to start the cron daemon, while the container starts.

That solution, however, used nginx reverse proxy in front of Nextcloud. This meant that everything else worked just fine, but Android and desktop sync clients would fail to connect. A quick tour around the web with DDG and I saw I wasn’t alone with this. The solution was to add the following two sets of lines to the Nextcloud chart:

  # Extra config files created in /var/www/html/config/
  # ref:
    androidclient.config.php: |-
      $CONFIG = array (
        'overwrite.cli.url' => 'https://nextcloud.domain/',
        'overwritehost' => 'nextcloud.domain',
        'overwriteprotocol' => 'https'

This will automatically create a file called androidclient.config.php, which is then inserted into running PHP config.

You need to also add some config to nginx, so that it passes the correct IP addresses through the proxy. You should have this section in your chart:

  ## You need to set an fpm version of the image for nextcloud if you want to use nginx!
  enabled: true
    repository: nginx
    tag: 1.19.10-alpine
    pullPolicy: IfNotPresent

    # This generates the default nginx config as per the nextcloud documentation
    default: false
    custom: |-
      location / {
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;

  resources: {}

The installation was actually the easier part. Migrating the data from the previous installation was more cumbersome, as I had several apps and the database changed from MariaDB to SQLite, so I couldn’t just take a dump and restore it. Or maybe I could have? I didn’t check it, it was just an assumption.