config folder permission

[steled]

Describe the bug
When I configure configs for the first start in my values.yaml file the permissions of the config folder are set to root:root

Version of Helm and Kubernetes:

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.0", GitCommit:"cb303e613a121a29364f75cc67d3d580833a7479", GitTreeState:"clean", BuildDate:"2021-04-08T16:31:21Z", GoVersion:"go1.16.1", Compiler:"gc", Platform:"linux/arm64"}
Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.0", GitCommit:"cb303e613a121a29364f75cc67d3d580833a7479", GitTreeState:"clean", BuildDate:"2021-04-08T16:25:06Z", GoVersion:"go1.16.1", Compiler:"gc", Platform:"linux/arm64"}

$ helm version
version.BuildInfo{Version:"v3.5.3", GitCommit:"041ce5a2c17a58be0fcd5f5e16fb3e7e95fea622", GitTreeState:"dirty", GoVersion:"go1.15.8"}

Which chart:
nextcloud:2.6.1

What happened:
I wanted to set overwritehost and overwriteprotocol via an extra config file created in /var/www/html/config/.

What you expected to happen:
nextcloud starts with config.php and custom.config.php

How to reproduce it (as minimally and precisely as possible):
Put the following lines of code into the values.yaml file:

  configs:
    custom.config.php: |-
      <?php
      $CONFIG = array (
         'overwritehost' => '***.duckdns.org',
         'overwriteprotocol' => 'https',
      );

Anything else we need to know:
The following error is seen in logs:

$ kubectl logs -n nextcloud nextcloud-dcc4678d9-gk9pd -f
Initializing nextcloud 19.0.3.1 ...
Initializing finished
New nextcloud instance
Installing with PostgreSQL database
starting nextcloud installation
Cannot write into "config" directory!
This can usually be fixed by giving the webserver write access to the config directory

Or, if you prefer to keep config.php file read only, set the option "config_is_read_only" to true in it.
See https://docs.nextcloud.com/server/19/go.php?to=admin-config
setting trusted domains…
Cannot write into "config" directory!
This can usually be fixed by giving the webserver write access to the config directory

Or, if you prefer to keep config.php file read only, set the option "config_is_read_only" to true in it.
See https://docs.nextcloud.com/server/19/go.php?to=admin-config

After applying the configuration the file/folder permissions looks like:

$ ls -la /ext/persistent/nextcloud/server/
total 36
drwxr-xr-x 9     1000 1000 4096 May  1 22:03 .
drwxr-xr-x 5     1000 1000 4096 May  1 20:11 ..
drwxr-xr-x 2 root     root 4096 May  1 22:03 config
drwxr-xr-x 2 root     root 4096 May  1 22:03 custom_apps
drwxr-xr-x 2 root     root 4096 May  1 22:03 data
drwxr-xr-x 8 www-data root 4096 May  1 22:03 html
drwxr-xr-x 4 root     root 4096 May  1 22:03 root
drwxr-xr-x 2 root     root 4096 May  1 22:03 themes
drwxr-xr-x 2 root     root 4096 May  1 22:03 tmp

$ ls -la /ext/persistent/nextcloud/server/config/
total 8
drwxr-xr-x 2 root root 4096 May  1 22:03 .
drwxr-xr-x 9 1000 1000 4096 May  1 22:03 ..
-rwx------ 1 root root    0 May  1 22:03 .htaccess
-rwx------ 1 root root    0 May  1 22:03 apache-pretty-urls.config.php
-rwx------ 1 root root    0 May  1 22:03 apcu.config.php
-rwx------ 1 root root    0 May  1 22:03 apps.config.php
-rwx------ 1 root root    0 May  1 22:03 autoconfig.php
-rwx------ 1 root root    0 May  1 22:03 custom.config.php
-rwx------ 1 root root    0 May  1 22:03 redis.config.php
-rwx------ 1 root root    0 May  1 22:03 smtp.config.php

As a workaroung I can set the values via extraEnv:

  extraEnv:
    - name: OVERWRITEHOST
      value: "***.duckdns.org"
    - name: OVERWRITEPROTOCOL
      value: https

But this is not how I expect that it should work like.

[benedikt-bartscher]

same here

[jessebot]

AHA! I have been trying to figure this out for months, and this has to be the cause! I understand how frustrating this is, because it can also affect your backups. I don't have a fix, but maybe a workaround. 🤔

So, I don't know why it's created as root, but I do know that recently the community introduced a securityContext feature, that should let you force the container and/or pod to run as a different user, for instance 33 (this is the UID of the www-data user). You can check out the change in #269.

I currently have an issue open where I'm troubleshooting this in #335 if you have issues with it.

[jessebot]

@steled and @benedikt-bartscher how are you both deploying k8s? Are you using k3s? Are you using NFS?