Code change:
</para> <para> <del> Right now changes to the <literal>services.nextcloud.config</literal> attribute set won't take effect after the first install (except <literal><link linkend="opt-services.nextcloud.config.extraTrustedDomains">services.nextcloud.config.extraTrustedDomains</link></literal>) since the actual configuration file is generated by the NextCloud installer which also sets up critical parts such as the database structure. </del> <ins> All configuration parameters are also stored in <literal>/var/lib/nextcloud/config/override.config.php</literal> which is generated by the module and linked from the store to ensure that all values from <literal>config.php</literal> can be modified by the module. However <literal>config.php</literal> manages the application's state and shouldn't be touched manually because of that. </ins> </para> <del> <para> <emphasis>Warning: don't delete <literal>config.php</literal>! This file </del> <ins> <warning> <para>Don't delete <literal>config.php</literal>! This file </ins> tracks the application's state and a deletion can cause unwanted <del> side-effects!</emphasis> </para> </del> <ins> side-effects!</para> </warning> </ins> <del> <para> <emphasis>Warning: don't rerun <literal>nextcloud-occ </del> <ins> <warning> <para>Don't rerun <literal>nextcloud-occ </ins> maintenance:install</literal>! This command tries to install the application <del> and can cause unwanted side-effects!</emphasis> </para> <para> The issues are known and reported in <link xlink:href="https://github.com/NixOS/nixpkgs/issues/49783">#49783</link>, for now it's unfortunately necessary to manually work around these issues. </para> <para> Right now app installation and configuration is done imperatively in the nextcloud web ui or via the <literal>nextcloud-occ</literal> command line utility. You can activate auto updates for your apps via <literal><link linkend="opt-services.nextcloud.autoUpdateApps.enable">services.nextcloud.autoUpdateApps</link></literal>. </para> </del> <ins> and can cause unwanted side-effects!</para> </warning> </ins> </section> </chapter>

Related discussion:
text: What about adding the following (subtile) log statement, to point users to the docs when they peek into the logs while things are not working as expected?
I agree that the log statement is the minimum we can do, and would at least give a hint about the way in which things are broken. Now, I guess the reason we're kind of disagreeing on the path forward is that you're much more hopeful than me that nextcloud will ever fix its stuff -- I'm assuming it'll get fixed in years at best (and even then…) -- and if it's in years then I'd much rather live with for years then spend a year deprecating it by making it conflict with new options than try to live with from now on and have users fail to understand what is going on. Now urhm, I'm investigating the module a bit deeper, and… is there any reason we can't put the database configuration etc. in ? We could then refresh on each activation, and it should be enough? If we have a way to couple it with something that automatically runs iff the database is not ready yet then the setup would actually be… almost perfect?
After having a deeper look at the sources ( at github, (6 commits ahead of v16.0.0RC1)) I guess that this should be possible (I didn't test it yet though). Configs will be loaded from using PHP's function[1] while all files ending with will be taken into account. Hence works as all config arrays will be merged together. This config will be loaded at [2] and is available as which is then used in the DI container[3]. If I understand the code correctly, I assume that it should be possible to render all config options in as config files found by glob will override values from [4]. [4]
Nice catch! This might indeed be possible - we should make very sure that config overrides work the way we think they will - seems to write the merged configuration, and not just the overrides (and merging this with other config in the wrong order can lead to wonderfully weird to debug issues) ;-) While I'd still prefer nextcloud splitting config and state properly, and being able to cope with read-only (base) config - it might be a direction worth exploring. What do you think?