`occ` command cannot overwrite config values that are set in `*.config.php` files

[StrikerRUS]

I tried to set memcache.local value to Redis but seems it's impossible.

I tried to do it inside the docker directly:

runuser -s /usr/local/bin/php - www-data -- /var/www/html/occ config:system:set memcache.local --value='\\OC\\Memcache\\Redis'

System config value memcache.local set to string \OC\Memcache\Redis

and via before-starting hook:

php /var/www/html/occ config:system:set memcache.local --value='\\OC\\Memcache\\Redis'

System config value memcache.local set to string \OC\Memcache\Redis

Neither method works and occ config:list shows old preconfigured value "memcache.local": "\\OC\\Memcache\\APCu", from this file

https://github.com/nextcloud/docker/blob/29d959acfdeccbc3603a37cc4201b6ad916290bd/.config/apcu.config.php#L3

Even more, you cannot delete such preconfigured values:

runuser -s /usr/local/bin/php - www-data -- /var/www/html/occ config:system:delete memcache.local

Log says

System config value memcache.local deleted

which is actually not true - that value appears in config again.

[StrikerRUS]

Linking #2231.

[joshtrichards]

You're correct for that particular config parameter, but (nearly) all others can be set using that approach.

Since that value is hardcoded in that config file and in Nextcloud additional config files always take priority over config.php.

However:

• it's not recommended to use anything other than APCu for the memcache.local since it's a local cache (Redis is slower when used for memcache.local in all deployment scenarios and in multi-server deployments it's a completely invalid config[^other])
• you can override the config/apcu.config.php yourself in that file if desired since config/ is on persistent storage

In theory we could make it possible to override it, like most other values, but given the first item above it doesn't really come up much.

[^other]: Note I'm only speaking of memcache.local; this does not apply to memcache.distributed and memcache.locking .

[StrikerRUS]

@joshtrichards Thanks a lot for your detailed response! It totally makes sense to me!

I absolutely agree with you about this particular situation with memcache.local. However, I think that the main problem here is that all other config options are suffering from the same issue as well. There is no any guarantee that tomorrow some important and not so invariant setting won't be commited in some other *.config.php file.

I believe that this behavior should be documented at least.

you can override the config/apcu.config.php yourself in that file if desired since config/ is on persistent storage

Seems that this your point can bring some problems during upgrade process. Refer to README: https://github.com/nextcloud/docker/blob/29d959acfdeccbc3603a37cc4201b6ad916290bd/README.md?plain=1#L246

So, I guess that the only safe option for overwriting a setting from *.config.php is creating a new *.config.php file that will be loaded later than original one. WDYT?

If you think that my suggested approach makes sense, then I think it would be better to prefix all partial predefined configs in .config/folder with numerical values like 10-apache-pretty-urls.config.php, 15-apcu.config.php and so on to let user easily overwrite them with 90-my.config.php file.

[joshtrichards]

What other config parameters are you unable to set?

Most of the config values set through those files are tied to environment variables. If those variables aren't provided by the operator, those config files are inactive.

The only exceptions are the following which are all intentionally hard coded because changing them isn't expected when using the image (and in most cases will break things):

• https://github.com/nextcloud/docker/blob/master/.config/apache-pretty-urls.config.php

• https://github.com/nextcloud/docker/blob/master/.config/apcu.config.php

• https://github.com/nextcloud/docker/blob/master/.config/apps.config.php

• https://github.com/nextcloud/docker/blob/master/.config/upgrade-disable-web.config.php

[joshtrichards]

Seems that this your point can bring some problems during upgrade process. Refer to README:

That's why the upgrade process doesn't replace those files automatically. In case someone does customize them for some reason, we leave them alone.

A message does get logged at container start-up time if we detect they are out of date / don't match the standard ones. We added that because people were reporting long ago fixed bugs, merely because they had out-of-date config files.

[StrikerRUS]

I played only with memcache.local. My main concern is

There is no any guarantee that tomorrow some important and not so invariant setting won't be commited in some other *.config.php file.

But from your latest comment

The only exceptions are the following which are all intentionally hard coded because changing them isn't expected when using the image (and in most cases will break things):

it seems that this situation is impossible because only values that shouldn't be altered go into image partial configs. Am I right?

[joshtrichards]

it seems that this situation is impossible because only values that shouldn't be altered go into image partial configs. Am I right?

Yes. That's a fair assumption. Those are, ultimately, hard coded values.

I believe that this behavior should be documented at least.

Fair point. I'll add it to #2224.

[StrikerRUS]

Great! Thank you for taking this into account.