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: If I'm not missing something obvious, checking configuration changes would translate to parsing/evaluating on every nextcloud startup as an , comparing every "interesting" key with the one provided through nixos configuration, and eventually then bailing out if they differ. I'm not sure if that's a road we'd like to go and keep up to date, while the underlying bug is a missing distinction between configuration and state upstream…
Since upstream mixes state and config it's questionable whether their configuration format is somehow supposed to be backwards-compatible (as it's only supposed to be used internally by Nextcloud). Hence I'm afraid that this will make i.e. upgrades even harder in case of configuration changes, so :-1: from me. As the issues are documented in the manual now, folks are warned and I think that this is a better option in contrast to adding more complexity to . I suggest we either close this for the reasons already stated or wait for an appropriate upstream fix.
I really don't feel good having stuff in that's actually a disguised command line… :/ Something that would sound nicer to me would be an executable that the user would have to manually run, and a bare-bones module that does not handle setup or configuration and just makes sure that the systemd unit is setup. At least the error is obvious (enabling the module without having run the executable would fail), all module options actually mean something, and the impure operation is made explicit. Either that or, similar to , rename all the options so it's explicit that they're used only for initial configuration. Would one of these solutions make sense to you?
Me neither, but currently we don't have much choice… I really like the fact that we can set up the Nextcloud instance in an unattended fashion, without having to worry about manual setting things up. I really don't want to end with more imperative setup steps than necessary. In theory, we could move some of the options in to to make it more obvious what isn't applied continuously. But TBH, I'd rather like to see the state/config mixing fixed upstream than having to introduce more mental complexity here, especially if this gets fixed and we end up with both incarnations. Really, this issue only occurs while a user changes nextcloud database parameters (mostly while tweaking his initial setup), and not having read the module documentation, where the behaviour is documented.