/entrypoint.sh: line 192: php/conf.d/redis-session.ini: Permission denied for non-root container

[devent]

Need to run a non-root container. I set the securityContext as following:

securityContext:
  runAsUser: 33
  runAsGroup: 33

Get the error:

Configuring Redis as session handler
/entrypoint.sh: 56: cannot create /usr/local/etc/php/conf.d/redis-session.ini: Permission denied

Of course a non-root can not write to /usr/local/etc/php/conf.d

Source https://github.com/nextcloud/docker/blob/master/22/apache/entrypoint.sh#L77

[jessebot]

Does this still happen today using the latest version of this helm chart? I know that config may always be owned by root, as per this issue, https://github.com/nextcloud/helm/issues/335, however, I'm not sure that's related. You could try setting this:

nextcloud:
  podSecurityContext:
    runAsUser: 33
    runAsGroup: 33
    runAsNonRoot: true
    fsGroup: 33

However, that may already get set here:

https://github.com/nextcloud/helm/blob/ff07aacd1bb2199e36544e11661835157cc7a6a3/charts/nextcloud/templates/deployment.yaml#L346-L364

Note: Since this issue was introduced, we've modified the available securityContext parameters. We have nextcloud.securityContext, nginx.securityContext (for the containers) and nextcloud.podSecurityContext (for the pod).

[applejag]

@jessebot Still having the issue when trying your YAML snippet. Also can't use the example from the chart's values.yaml as they are invalid values:

https://github.com/nextcloud/helm/blob/0b6bd840f2757e7737566bf388f0e45aa56467d9/charts/nextcloud/values.yaml#L195-L208

Have to revert to last known working version, which for me is 3.5.19 of the chart.

[jessebot]

@jilleJr or @devent could you please provide your whole values.yaml after anonymizing any sensitive data?

Also can't use the example from the chart's values.yaml as they are invalid values

Could you explain what you mean by invalid and where you're seeing the error? Those are the default values that are applied if you're using the non-alpine containers.

[applejag]

@jilleJr or @devent could you please provide your whole values.yaml after anonymizing any sensitive data?

Also can't use the example from the chart's values.yaml as they are invalid values

Sure:

values.yaml

image:
  flavor: fpm

nginx:
  enabled: true
  resources:
    requests:
      memory: 10M
      cpu: 5m
    limits:
      memory: 100M
      cpu: 100m

redis:
  enabled: true
  architecture: standalone
  auth:
    enabled: true
    password: ref+sops://secrets.yaml#redisPassword
  master:
    persistence:
      enabled: false
    requests:
      memory: 10M
      cpu: 10m
    limits:
      memory: 100M
      cpu: 100m

ingress:
  enabled: true
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt
    traefik.ingress.kubernetes.io/router.middlewares: nextcloud-nextcloud-replace-dav@kubernetescrd,nextcloud-nextcloud-replace-well-known@kubernetescrd,nextcloud-nextcloud-headers@kubernetescrd
  tls:
    - secretName: nextcloud-tls
      hosts:
        - XXXXXXXXXXXXXXXX

nextcloud:
  host: XXXXXXXXXXXXXXXX
  username: ref+sops://secrets.yaml#nextcloudUsername
  password: ref+sops://secrets.yaml#nextcloudPassword
  mail:
    enabled: true
    domain: ref+sops://secrets.yaml#emailDomain
    smtp:
      host: ref+sops://secrets.yaml#emailSmtpHostname
      port: ref+sops://secrets.yaml#emailSmtpPort
      secure: ssl
      name: ref+sops://secrets.yaml#emailSmtpUsername
      password: ref+sops://secrets.yaml#emailSmtpPassword
  configs:
    misc.config.php: |
      <?php
      $CONFIG = array(
        'default_phone_region' => 'DE',
        'music.lastfm_api_key' => getenv('LASTFM_API_KEY'),
        'trusted_proxies' => array(
          0 => '127.0.0.1',
          1 => '10.0.0.0/8',
        ),
        'trusted_domains' => array (
          2 => 'XXXXXXXXXXXXXXXX',
        ),
      );
  extraEnv:
    - name: LASTFM_API_KEY
      valueFrom:
        secretKeyRef:
          key: LASTFM_API_KEY
          name: nextcloud-extras
    - name: PHP_MEMORY_LIMIT
      value: 1024M
  # Security context is broken in the Nexus chart:
  # https://github.com/nextcloud/helm/issues/187
  #securityContext:
  #  runAsUser: 33
  #  runAsGroup: 33
  #  runAsNonRoot: true
  #podSecurityContext:
  #  fsGroup: 82
  #  fsGroupChangePolicy: OnRootMismatch

cronjob:
  enabled: true

  resources:
    requests:
      memory: 10M
      cpu: 5m
    limits:
      memory: 100M
      cpu: 100m

resources:
  requests:
    memory: 1500M
    cpu: 100m
  limits:
    memory: 2000M
    cpu: 1000m

persistence:
  enabled: true
  size: 30Gi
  annotations:
    helm.sh/resource-policy: keep

internalDatabase:
  enabled: false

externalDatabase:
  enabled: true
  type: mysql

mariadb:
  enabled: true
  auth:
    username: ref+sops://secrets.yaml#mariadbUsername
    password: ref+sops://secrets.yaml#mariadbPassword
    rootPassword: ref+sops://secrets.yaml#mariadbRootPassword
  primary:
    persistence:
      enabled: true
      annotations:
        helm.sh/resource-policy: keep
    resources:
      requests:
        memory: 300M
        cpu: 30m
      limits:
        memory: 500M
        cpu: 200m

  volumePermissions:
    enabled: true

metrics:
  enabled: true
  token: ref+sops://secrets.yaml#metricsToken

Could you explain what you mean by invalid and where you're seeing the error? Those are the default values that are applied if you're using the non-alpine containers.

The readOnlyRootFilesystem is not a valid pod-level securityContext field.

Given that they're just copy-pasted from each other, I don't know how credible they are.

[eloo]

will this ever be fixed? or are we doomed to run nextcloud as root in kubernetes for ever?

[spikeygg]

I updated my nextcloud docker installation to 27.1.3 today and it failed with this similar error. I am running non-root user as well. I found this thread: https://forums.unraid.net/topic/88504-support-knex666-nextcloud/page/20/ where robbenmu suggests that removing the redis config from the docker container makes it work. I tried that and it also worked for me (without disabling/removing the redis configuration in config.php) but I doubt my nextcloud is using redis now.

EDIT I found quickly that the mobile uploads wouldn't work: Malformed Server Configuration with Redis configured in the config.php but no Redis server defined. So, I added a bind volume to my docker container with a pointer to a local and editable redis-session.ini so that nextcloud could edit it inside /usr/local/etc/php/conf.d/redis-session.ini. This is a super dumb problem that should be fixed...

[jessebot]

@provokateurin or @tvories Are you running redis and a non-root container?

https://github.com/nextcloud/docker/blob/d1dbc77e0b5e851105cf8606942e74b7d21fe682/27/apache/entrypoint.sh#L108-L133

I see that this does indeed try to write to /usr/local/etc/php/conf.d/redis-session.ini, which would actually be a root owned directory I think. Would the correct thing to do be raising this with nextcloud/docker or nextcloud/server? Why is this being written here and could we maybe make it configurable?

[98jan]

Any plans to make it work rootless? I am also failing for running nextcloud with redis enabled with a non-root user.

Would really appreciate it, when there would be an option to run it rootless.

[jessebot]

@98jan can you please try asking in the upstream repo about this? This seems to be a nextcloud/docker issue.

[eloo]

there is already an issue upstream.. and its more than 4 years old :D but the maintainers seems not to care about that

https://github.com/nextcloud/docker/issues/763

[jessebot]

and its more than 4 years old :D but the maintainers seems not to care about that

Please be nice. I know you're all frustrated, but it's not that the maintainers dislike you or your particular GitHub Issue. We're unpaid volunteers that do this in our free time.

I left a comment on that issue: https://github.com/nextcloud/docker/issues/763#issuecomment-1855485793

One of the contributors there suggested:

Don't set redis host. Configure it with occ

If we can figure out the occ command, I'm open to a PR to remove the ConfigMap and instead have a job that has post-install helm hook annotations to set the redis host that way. As long as it doesn't break anything, that seems like a win-win situation, yes?

Update

@stavros-k responded and helped us out by providing the scripts we need here:

here is the redis script, you will also find other utils in this dir https://github.com/stavros-k/containers/blob/master/apps/nextcloud-fpm/configure-scripts/occ-redis.sh

Please feel free to test out the suggested solution and submit a PR.

also, I played with the docker hooks feature a bit, but couldn't seem to get it to work? :thinking: you can see more details in https://github.com/nextcloud/docker/issues/763#issuecomment-1857453976 but until that's resolved (https://github.com/nextcloud/docker/pull/2115), we still need to do this via a job with a helm hook rather than using the docker hooks feature.

[R-Nabil]

May I ask what's the altest on this ? Trying to use redis with my k3s deployment and it fails with the same error (i'm not even running it as nonRoot for now...)

[jessebot]

@R-Nabil, sorry for the extreme delay here, but this shouldn't occur for non-root usage. If it's still happening, could you please open a separate issue?