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 nobody else wants to take over, I'd volunteer to do this during the next week as investing time on improving the nextcloud module is one item on my todo list :) I was aware of being stateful, but thanks a lot for linking the corresponding ticket! I'll have a look at this as soon as I have sufficient time to :)
In the light of this issue, what's the correct way to upgrade nextcloud to a new major version? Do I just pull a newer , upgrade my system and hope that the systemd job will do the right thing?
The service runs an that should apply all changes like database migrations needed for the new Nextcloud version (beware, downgrades aren't possible). As long as you let Nextcloud do its job, you shouldn't get that much issues. IMHO the actual problem here is the configuration of the software within Nix(OS).
just a simple question (could not come to a conclusion after the lengthy thread) but I recently updated my nextcloud via nixops deploy and the update disabled the calendar module. Did I mess up or is that expected ? any way to configure this from nix ?
Assuming that you installed the calendar module via the UI, it is installed in . The beginning of my config reads: So in principle nextcloud can edit the apps installed via the web interface (otherwise you couldn't install them via the interface in the first place).
I don't think there's anything actionable here - the nextcloud nixos module is limited by how Nextcloud (imperatively) manages its configuration. The current state is properly documented in , and we raised our concerns to upstream in - closing this issue, feel free to reopen if there's more to be done.
I think one actionable item would be to have the nextcloud service fail with an explicit error if the configuration being used is not compatible with the configuration defined in the .nix. At least the user would be warned in practice that configuration is not really applied, and not only by the manual that they are relatively unlikely to actually read. Reopening for now, feel free to reclose if you think that's not a reasonable “solution” :)
The problem is we don't know whether the configuration on disk containing database connection information () differs from the one that would be generated through an installation via - we don't render the configuration on our own, but the installer writes it out as a side-effect.