Nextcloud setup on local network microk8s with nfs mount initialization error

Hello,

I’m learning k8s and trying to apply a k8s setup with nextcloud. I have configured a deployment to use an NFS mount for nextcloud’s /var/www/html. The created pod is just stuck on CrashLoopBackOff. I checked the logs and it seems that it is stuck on initialization with tons of rsync errors.

Initializing nextcloud 26.0.2.1 ...
rsync: [generator] chown "/var/www/html/." failed: Operation not permitted (1)
rsync: [generator] chown "/var/www/html/3rdparty" failed: Operation not permitted (1)
rsync: [generator] chown "/var/www/html/3rdparty/.github" failed: Operation not permitted (1)
rsync: [generator] chown "/var/www/html/3rdparty/.github/workflows" failed: Operation not permitted (1)
rsync: [generator] chown "/var/www/html/3rdparty/aws" failed: Operation not permitted (1)
rsync: [generator] chown "/var/www/html/3rdparty/aws/aws-crt-php" failed: Operation not permitted (1)
rsync: [generator] chown "/var/www/html/3rdparty/aws/aws-crt-php/ext" failed: Operation not permitted (1)
rsync: [generator] chown "/var/www/html/3rdparty/aws/aws-crt-php/src" failed: Operation not permitted (1)
...

On the NFS directory I can see that files have been created

$ ls -la /nextcloud_volume
-rw-------+ 1 nobody users  3256 Jun  8 22:32 .htaccess
-rw-------+ 1 nobody users   101 Jun  8 22:32 .user.ini
drwxr-sr-x+ 1 nobody users   858 Jun  8 22:32 3rdparty
-rw-------+ 1 nobody users 19327 Jun  8 22:32 AUTHORS
-rw-------+ 1 nobody users 34520 Jun  8 22:32 COPYING
drwxr-sr-x+ 1 nobody users  1182 Jun  8 22:08 apps
-rw-------+ 1 nobody users  4095 Jun  8 22:32 console.php
drwxr-sr-x+ 1 nobody users   456 Jun  8 22:33 core
-rw-------+ 1 nobody users  6317 Jun  8 22:32 cron.php
drwxr-sr-x+ 1 nobody users 10898 Jun  8 22:34 dist
-rw-------+ 1 nobody users   156 Jun  8 22:32 index.html
-rw-------+ 1 nobody users  3456 Jun  8 22:32 index.php
drwxr-sr-x+ 1 nobody users   126 Jun  8 22:34 lib
-rw-rw-r--+ 1 nobody users     0 Jun  8 22:06 nextcloud-init-sync.lock
-rwx------+ 1 nobody users   283 Jun  8 22:32 occ
drwxr-sr-x+ 1 nobody users    18 Jun  8 22:34 ocm-provider
drwxr-sr-x+ 1 nobody users    50 Jun  8 22:34 ocs
drwxr-sr-x+ 1 nobody users    18 Jun  8 22:34 ocs-provider
-rw-------+ 1 nobody users  3187 Jun  8 22:32 public.php
-rw-------+ 1 nobody users  5597 Jun  8 22:32 remote.php
drwxr-sr-x+ 1 nobody users   158 Jun  8 22:34 resources
-rw-------+ 1 nobody users    26 Jun  8 22:32 robots.txt
-rw-------+ 1 nobody users  2452 Jun  8 22:32 status.php

Below is the deployment yaml file that I used for this.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nextcloud-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nextcloud-deployment
  template:
    metadata:
      labels:
        app: nextcloud-deployment
    spec:
      volumes:
      - name: raspberry-pi-nfs
        nfs:
          server: ...
          path: /nextcloud_volume
          readOnly: false
      containers:
      - image: nextcloud
        name: nextcloud
        volumeMounts:
        - mountPath: /var/www/html
          name: raspberry-pi-nfs
        env:
        - name: POSTGRES_HOST
          value: ...
        - name: POSTGRES_DB
          value: ...
        - name: POSTGRES_USER
          value: ...
        - name: POSTGRES_PASSWORD
          value: ...

I’ve tried setting the user via adding securityContext.runAsUser it progresses but it comes with a new error on the apache side. So I guess this is not the right approach?

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.1.92.10. Set the 'ServerName' directive globally to suppress this message
(13)Permission denied: AH00072: make_sock: could not bind to address [::]:80
(13)Permission denied: AH00072: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
AH00015: Unable to open logs

Not too sure what else to try. Any help is very much appreciated!

Without the volume mount nextcloud works ok but I don’t want to lose the data on pod restarts. NFS volume mount works ok for postgresql.

You’ll likely need to either set it to bind to ports >1024 or give it capabilities (i.e. CAP_NET_BIND_SERVICE) so that lower ports can be used without being root.

Given your project, you might also be interested in:

My two cents sience I encountered the same problem: the reason why it is not working in the first place seems to be that the code tries to chown the content of the data folder, but you are sharing the folder in NFS with the squash_root option, so everything owned by root is mapped to nobody.

The solution is to activate the security context, which breaks your ability to bind the service to port 80. I feel that adding CAP_NET_BIND_SERVICE will not solve the problem because this capability will be given to the root user inside the container. However, it seems that, given how the container is constructed, Apache will still run as non-root if the security context is activated, so it cannot bind to a privileged port. I didn’t investigate much further.

Science I was using the helm chart. The final solution would be to move Apache to port 8080, but at this moment, the Apache server can not be configured from the helm chart if not by injecting a hacky config map as explained by this issue. Fortunately later, in the same issue, they propose to switch Apache with Nginx in a separate container within the pod, a solution that I found much cleaner and I adopted.