/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

```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: | '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?