Test our new work-in-progress upgrader script

[rigrig]

I got the same error as dom134 about /assets. That folder was created a while ago when I enabled the assets pipeline, so should be handled by the updater I think?
After deleting /assets the updater worked fine, reloading Nextcloud and starting the update through the webinterface still disabled 3rd party apps though, was that supposed to happen?

[ANT_Cloud]

@LukasReschke

This seem to do the trick… however shell_exec is not available for me, does this mean I need to manually do it, or are you working on this too ?

Hehe. That’s another one, so Nextcloud 9.0.50 and 9.0.51 ship the broken ownCloud updater. To prevent breaking user data it is deactivated in a lot of cases. (if you would have clicked on the button here like you can in ownCloud your instance would get destroyed!)

I just created a revert PR at Revert "[stable9] Don't show the updater if updater is incompatible" by LukasReschke · Pull Request #228 · nextcloud/server · GitHub for this, for you to test this the easiest way would be to change server/apps/updatenotification/controller/admincontroller.php at 49a916fb46a2281aed818d20a9487b6af7e2b1dc · nextcloud/server · GitHub into the following:

‘updaterRequirementsFulfilled’ =>true,

The file for this is apps/updatenotification/controller/admincontroller.php.

It seems like I need to do this again for .52 ? As I’m getting the same message again

[ANT_Cloud]

Now I’m getting the following:

Fatal error: Uncaught Symfony\Component\Process\Exception\RuntimeException: The Process class relies on proc_open, which is not available on your PHP installation. in /www/htdocs/xxxxxxx/domain/next.domain.net/cloud/updater/vendor/symfony/process/Process.php:144 Stack trace: #0 /www/htdocs/xxxxxxx/domain/next.domain.net/cloud/updater/src/Utils/OccRunner.php(45): Symfony\Component\Process\Process->__construct(‘php /www/htdocs…’) #1 /www/htdocs/xxxxxxx/domain/next.domain.net/cloud/updater/src/Utils/OccRunner.php(56): Owncloud\Updater\Utils\OccRunner->run(‘config:list --p…’) #2 /www/htdocs/xxxxxxx/domain/next.domain.net/cloud/updater/src/Utils/ConfigReader.php(106): Owncloud\Updater\Utils\OccRunner->runJson(‘config:list --p…’) #3 /www/htdocs/xxxxxxx/domain/next.domain.net/cloud/updater/src/Utils/ConfigReader.php(50): Owncloud\Updater\Utils\ConfigReader->load() #4 /www/htdocs/xxxxxxx/domain/next.domain.net/cloud/updater/src/Control in /www/htdocs/xxxxxxx/domain/next.domain.net/cloud/updater/vendor/symfony/process/Process.php on line 144

[LukasReschke]

@Raegar

The updater resets the Maximum upload size back to default - it’d be nice if that (and potentially other values) get pulled prior to upgrade so they can be applied when the file is overwritten.

On the roadmap.

@John

It’s just: clicking it only shows another button “Click here to finish” …but NOTHING happens between these two clicks.

Anything in your browser console?

@rigrig

After deleting /assets the updater worked fine

Good catch. I filed a bug at Ignore asset folder · Issue #23 · nextcloud/updater · GitHub and we will fix this

@rigrig

the webinterface still disabled 3rd party apps though, was that supposed to happen?

Unfortunately, at the moment this is still the case. But a newer version will do that.

@ANT_Cloud

It seems like I need to do this again for .52 ? As I’m getting the same message again

Unfortunately yes, the 9.x releases still ship the old ownCloud updater. And as you can see that one is super prone to break randomly. In your case some required PHP extensions are not installed.

At the moment one has to manually upload the new updater every time. I’ll look with @MorrisJobke for when we will ship the new updater. Hopefully soon. Sorry for the hassles! – We just wanted to really make sure to not ship something that does more harm than good.

[John]

@LukasReschke yet again nothing just as before. The only difference I notice is that the permissions are still in place (with the first update these got screwed up as you may remember)

Shall I create an account for you so you can check yourself? (it is a test installation anyway)

John

[ANT_Cloud]

@LukasReschke

Sorry for the hassles!

No worries, just let me know when I should run an update

[LukasReschke]

@John

Shall I create an account for you so you can check yourself? (it is a test installation anyway)

That would be awesome

[MorrisJobke]

@John

Edit: ok, I could do with some help here: has anyone a clue, what could possibly cause the “Continue Update” button to behave the way it does (nothing)?Any idea anyone?

Could you please also check the .step file in data/updater-INSTANCEID/ ? There should be a number. This is the number at which the updater continues And that is why there is a continue button skips the already executed steps.

[John]

Thanks for your help.

the content of the file reads:

(“state”:“end”,“step”:11)

[amcdade]

I know this doesn’t add anything much, but this worked a dream for me. I had a permissions problem because I had made a backup to updater/index.php.bak and this wasn’t owned by www-data, but otherwise it was all fine. It did disable 4 of my plugins, but I simply re-enabled them after the upgrade.

[Thor]

I guess the updater won’t work if my nextcloud instance is not located in the nextcloud folder (I renamed the folder)?
Is it enough to rename the folder back to Nextcloud and after the update rename it agian?

I’m already on .52 so i can’t test it.

[MorrisJobke]

@Thor

I guess the updater won’t work if my nextcloud instance is not located in the nextcloud folder (I renamed the folder)?Is it enough to rename the folder back to Nextcloud and after the update rename it agian?

It should work no matter how the parent folder is named.

@Thor

I’m already on .52 so i can’t test it.

This is most likely why the updater would not show up

[Thor]

@MorrisJobke

It should work no matter how the parent folder is named.

Oh great, I’ll try it as soon as there is a new version to test.

@MorrisJobke

This is most likely why the updater would not show up

Yeah, I know. I just wait till the next version gets released.

[Micha-Btz]

I am on owncloud 9.0.2 and want to test the new script. but sadly it does nothing.

I have yesterday uploaded the index to the updater folder and add the line in the config.
change the update channel and nothing happends. can i check somewhere why nothing happends?

[hitam4450]

Starting from NextCloud 9.051 it worked flawless and as expected!

regards, hitam4450

[Henry78]

Just upgraded from owncloud to 9.50 manually an then used the updater to go to 9.51. Worked very well, just - naturally! - doesn’t work with Strong Permissions

[eischmann]

I got stuck on this error message:
Check for write permissions
The following places can not be written to:/var/www/html/nextcloud/updater/…/apps/notes/.git/objects/pack/pack-17eddcbf421e526c08aa2359c72d3cf848f58435.pack/var/www/html/nextcloud/updater/…/apps/notes/.git/objects/pack/pack-17eddcbf421e526c08aa2359c72d3cf848f58435.idxThe following places can not be written to:/var/www/html/nextcloud/updater/…/apps/notes/.git/objects/pack/pack-17eddcbf421e526c08aa2359c72d3cf848f58435.pack/var/www/html/nextcloud/updater/…/apps/notes/.git/objects/pack/pack-17eddcbf421e526c08aa2359c72d3cf848f58435.idx

It’s strange because everything in /nextcloud should have apache:apache owner.

[Bugsbane]

No, but if someone has run the strong permissions script, then hopefully they read the part that warns that they’ll need to temporarily change the permissions back before upgrading…

[eischmann]

I did run the script that changes owner of all files in /var/www/html/nextcloud to apache:apache. And all files there seem to have apache:apache as their owner. Yet I’m told during the upgrade that some files can’t be written to.

[Henry78]

Like me? Yeah, missed that.