Code change:
Hi, I'm testing nextcloud it seem there is an issue. I'm tying to install a fresh nextcloud and with the minimal example of the man : I get : janv. 29 16:56:31 cloud systemd[1]: Starting nextcloud-setup.service... janv. 29 16:56:31 cloud nextcloud-setup-start[]: Nextcloud is not installed - only a limited number of commands are available janv. 29 16:56:31 cloud nextcloud-setup-start[]: janv. 29 16:56:31 cloud nextcloud-setup-start[]: Command "upgrade" is not defined. nextcloud-setup-start try to update a new install same result with : = [ "nextcloud-19.0.6" ]; or system: `"x86_64-linux" host os: multi-user?: sandbox: version: channels(root): nixpkgs: I may not be calling all the maintainers in case it's a false alarm :-)
I just ran into this too, with as my package. Running doesn't show an command.
I ran the command manually, and now shows up. Not sure why it didn't install through nix, though.
Thanks, it works for me too. It must certainly come from the test. I'll check that later.
Cannot reproduce this on latest master and release-20.09. Can you please give me a minmal VM config that I can use to reproduce?
Same config works in a test VM. I'll try to take a closer look next week if it's still relevant.
I am running into this error as well with about the same config as . Specifically I'm using configuration without the nginx stuff (e.g. lines 5 to 27 commented out and not set) for on both nixpkgs master and release-20.09. I'll try it in a VM and report back..
It doesn't look like the builds of nextcloud and postgres are cleaned up completely, which is where it looks like this problem is coming from. Specifically, I had built nextcloud and postgres several times while I worked out the configuration settings I wanted. It turns out there were nextcloud and postgres folders in that still remained after I uninstalled both apps. Removing those two folders, then reinstalling these programs via nix fixed the error for me.
When I've first set up Nextcloud i encountered the same issues is describing, but since then everything has run smoothly for me.
It might sense to verify the result of after the block, before executing , e.g. using and , where causes 's returncode to represent the boolean value of . The of is unclean. Instead of returning simply JSON, it also returns an informative message on the same FD: Although this should be fixed upstream in the long term (see also ), it needs to be stripped away for now (e.g. using ).
may prevent corrupted installations in some cases. But I'm still missing a minimal VM setup to reproduce.
I thought I gave one. I 'm very new with nixos but I would be delighted to learn more. maybe you can give me a link or guide me to do this? or pass the assignees to someone that can reproduce it. thanks
Well, that's the test VM's config that I already checked. Was there any existing state in /var/lib/nextcloud during your install attempt?
I don't know I need to reproduce this on the machine in question. i can try
have you checked whether repeated calls are actually safe? Especially if you want to "work out" your options iteratively. Yeah please do that. You can also answer my question "Was there any existing state in /var/lib/nextcloud during your install attempt?". This is IIRC the main cause for problems like this.
I don't have access to the machine but I've just started a vps and the same config works with the same steps. the problem would not have been solved :-) ? I'm going to look at the merge for the fun
cool merge :-) I've used adminpass = "" on vps may be this is the trick. And ok I just read other posts.
do you really need me to reproduce the problem ? it's really very easy and I know you are active in others post who explain the problem. If you really need that I have a vps whith the bug.
Well, I'm trying to check if there are any other causes apart from an existing state. Hence my question whether there was any existing state when you encountered the issue.
I don't know in any case, /var/lib/nextcloud/* seems to be the same between the 2 generations
Hit this too: I'd misconfigured the postgres database (the nextcloud module doesn't setup a nextcloud user and role on the db, which I'm used to for other modules), so the service errored out with a database "role doesn't exist" issue. Once I fixed this, I hit this problem, which went away with a good old .
To me it seems as if most of the issues here are because the initial install failed and then the app wasn't properly installed, correct? Rather than letting this stall here even more, I'd write a few more notes in the documentation.

Related discussion:
text: </para> </section> <del> <section xml:id="module-services-nextcloud-pitfalls-during-upgrade"> <title>Pitfalls</title> <para> Unfortunately Nextcloud appears to be very stateful when it comes to managing its own configuration. The config file lives in the home directory of the <literal>nextcloud</literal> user (by default <literal>/var/lib/nextcloud/config/config.php</literal>) and is also used to track several states of the application (e.g. whether installed or not). </para> <para> 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. </para> <warning> <para>Don't delete <literal>config.php</literal>! This file tracks the application's state and a deletion can cause unwanted side-effects!</para> </warning> <warning> <para>Don't rerun <literal>nextcloud-occ maintenance:install</literal>! This command tries to install the application and can cause unwanted side-effects!</para> </warning> </del> <ins> <section xml:id="module-services-nextcloud-pitfalls-during-upgrade"> <title>Common problems</title> <itemizedlist> <listitem> <formalpara> <title>General notes</title> <para> Unfortunately Nextcloud appears to be very stateful when it comes to managing its own configuration. The config file lives in the home directory of the <literal>nextcloud</literal> user (by default <literal>/var/lib/nextcloud/config/config.php</literal>) and is also used to track several states of the application (e.g., whether installed or not). </para> </formalpara> <para> All configuration parameters are also stored in <filename>/var/lib/nextcloud/config/override.config.php</filename> which is generated by the module and linked from the store to ensure that all values from <filename>config.php</filename> can be modified by the module. However <filename>config.php</filename> manages the application's state and shouldn't be touched manually because of that. </para> <warning> <para>Don't delete <filename>config.php</filename>! This file tracks the application's state and a deletion can cause unwanted side-effects!</para> </warning> </ins> <del> <para> Nextcloud doesn't allow to move more than one major-version forward. If you're e.g. on <literal>v16</literal>, you cannot upgrade to <literal>v18</literal>, you need to upgrade to <literal>v17</literal> first. This is ensured automatically as long as the <link linkend="opt-system.stateVersion">stateVersion</link> is declared properly. In that case the oldest version available (one major behind the one from the previous NixOS release) will be selected by default and the module will generate a warning that reminds the user to upgrade to latest Nextcloud <emphasis>after</emphasis> that deploy. </para> </del> <ins> <warning> <para>Don't rerun <literal>nextcloud-occ maintenance:install</literal>! This command tries to install the application and can cause unwanted side-effects!</para> </warning> </listitem> <listitem> <formalpara> <title>Multiple version upgrades</title> <para> Nextcloud doesn't allow to move more than one major-version forward. E.g., if you're on <literal>v16</literal>, you cannot upgrade to <literal>v18</literal>, you need to upgrade to <literal>v17</literal> first. This is ensured automatically as long as the <link linkend="opt-system.stateVersion">stateVersion</link> is declared properly. In that case the oldest version available (one major behind the one from the previous NixOS release) will be selected by default and the module will generate a warning that reminds the user to upgrade to latest Nextcloud <emphasis>after</emphasis> that deploy. </para> </formalpara> </listitem> <listitem> <formalpara> <title><literal>Error: Command "upgrade" is not defined.</literal></title> <para> This error usually occurs if the initial installation (<command>nextcloud-occ maintenance:install</command>) has failed. After that, the application is not installed, but the upgrade is attempted to be executed. Further context can be found in <link xlink:href="https://github.com/NixOS/nixpkgs/issues/111175">NixOS/nixpkgs#111175</link>. </para> </formalpara> <para> First of all, it makes sense to find out what went wrong by looking at the logs of the installation via <command>journalctl -u nextcloud-setup</command> and try to fix the underlying issue. </para> <itemizedlist> <listitem> <para> If this occurs on an <emphasis>existing</emphasis> setup, this is most likely because the maintenance mode is active. It can be deactivated by running <command>nextcloud-occ maintenance:mode --off</command>. It's advisable though to check the logs first on why the maintenance mode was activated. </para> </listitem> <listitem> <warning><para>Only perform the following measures on <emphasis>freshly installed instances!</emphasis></para></warning> <para> A re-run of the installer can be forced by <emphasis>deleting</emphasis> <filename>/var/lib/nextcloud/config/config.php</filename>. This is the only time advisable because the fresh install doesn't have any state that can be lost. In case that doesn't help, an entire re-creation can be forced via <command>rm -rf ~nextcloud/</command>. </para> </listitem> </itemizedlist> </listitem> </itemizedlist> </ins> </section> <section xml:id="module-services-nextcloud-httpd">