Upgrade stuck at "Step 4 is currently in process. Please reload this page later"

I started using the built in updater to update from 12.0.4 to 13 and hit an error at the “backup” stage. I turned maintenance mode back off to research it, and now I can’t get past step 4.

If I clear out data/updater-occ7xyz123/.step It will let me try the update from the beginning but I keep getting as far as the backup and then this:

Parsing response failed. <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>500 Internal Server Error</title> </head><body> <h1>Internal Server Error</h1> <p>The server encountered an internal error or misconfiguration and was unable to complete your request.</p> <p>Please contact the server administrator, webmaster@brooklynlocal.info and inform them of the time the error occurred, and anything you might have done that may have caused the error.</p> <p>More information about this error may be available in the server error log.</p> <p>Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.</p> </body></html>

What I see in my error logs is a lot of: [Mon Feb 12 17:02:23 2018] [crit] [client xx.xxx.xxx.xx] (13)Permission denied: /home/.../owncloud/data/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable

But when I actually look in /owncloud/data, .htaccess is definitely world readable:

-rw-r--r-- 1 abh pg140705 324 Dec 14 15:51 .htaccess

The updater is stuck on Step 4.


More details:

Nextcloud version: 12.0.4
Operating system and version: Ubuntu 14:04 (note, I can’t fix this, I’m on Dreamhost)
PHP version: 7.0.27

Logs: There’s nothing – a lot of carddav errors from December when I was fiddling with something, and some failed login attempts.

Config.php:

<?php
$CONFIG = array (
  'instanceid' => 'occ7c1677a99',
  'passwordsalt' => 'xxx',
  'trusted_domains' =>  
  array (
    0 => 'example.com',
    1 => 'www.example.com',
  ),  
  'datadirectory' => '/home/user/example.com/owncloud/data',
  'overwrite.cli.url' => 'https://example.com/owncloud',
  'dbtype' => 'sqlite3',
  'version' => '12.0.4.3',
  'installed' => true,
  'theme' => '', 
  'maintenance' => false,
  'secret' => 'xxx',
  'mail_smtpmode' => 'smtp',
  'mail_smtpsecure' => 'tls',
  'mail_from_address' => 'username',
  'mail_domain' => 'example.com',
  'mail_smtpauthtype' => 'PLAIN',
  'mail_smtphost' => 'mail.example.com',
  'mail_smtpauth' => 1,
  'mail_smtpport' => '587',
  'mail_smtpname' => 'username',
  'mail_smtppassword' => 'xxxxx',
  'loglevel' => 2,
  'trashbin_retention_obligation' => 'auto',
  'defaultapp' => 'calendar',
  'session_lifetime' => 86400,
  'updater.release.channel' => 'stable',
  'updater.secret' => 'xxxxx
);
~   

(And yes, the url is /owncloud – I didn’t want to make my family members update their stored calendar sync settings when I migrated.)

Update: I figured out how to clear the “step”, but I still can’t get past the backup. This is the last thing in my web server error log after it halts:

[Mon Feb 12 21:17:23 2018] [crit] [client 73.xxx.xx.45] (13)Permission denied: /home/abh/brooklynlocal.info/owncloud/data/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable
[Mon Feb 12 21:17:23 2018] [error] [client 73.xxx.xx.45] File does not exist: /home/abh/brooklynlocal.info/forbidden.html
[Mon Feb 12 21:19:40 2018] [error] [client 73.xxx.xx.45] Premature end of script headers: index.php
[Mon Feb 12 21:19:40 2018] [error] [client 73.xxx.xx.45] File does not exist: /home/abh/brooklynlocal.info/internal_error.html

1 Like

I am experiencing the same issue. How did you solve the step problem? I can’t find a .step file in data/updater-xasfnhhios…

First, the .step file is hidden. But second, moving it didn’t help. It allowed me to restart the update process but I got as far as the backup / Step 4, and hit the same wall.

I think the actual solution is to update manually. The process is described at:

https://docs.nextcloud.com/server/13/admin_manual/maintenance/manual_upgrade.html

I am experiencing the same issue, but I cannot access the command line as it is a shared service. Is there a way to complete these steps through the web interface/ updater app ?

The error message when I click on Update reads essentially: “Step 4 currently in progress…”

I had the same issue. Here’s what I did to get the web updater to finish properly…

Edited the config file on the server to remove maintenance mode.

Removed the .step file in the /data/updater…/ folder.

Changed some PHP parameters on the hosting as follows:-

  • note * running PHP 5.6.35 under fastcgi / apache.
  • max_execution_time 120 seconds
  • max_input_time 90 seconds

From the admin page, re-run the update. It then went through without error.

4 Likes

Ran into this today trying to go from 13.0.6 to 14.0.1

It needs to RESUME the download rather than starting over every time. I don’t know what PHP timeout my server needs but 180 seconds wasn’t enough to get the whole zip from the NC servers and I imagine this would happen to anyone when the NC servers are loaded.

1 Like

I just had the same issue.

In my case

  • setting max_execution_time to 3600
  • setting max_input_time to 3600 (both in php.ini)
  • sudo -u www-data php occ maintenance:repair

made it possible to restart and finish the update.

1 Like

Hello,
Where can I find the php.ini file?
Searching for it only brings a result for php.ini in the qownnotes folder!!

Where it is will depend on your OS, in my case it was in:

/etc/php/7.0/apache2/php.ini

You can also try running “locate php.ini” to find where it may be on your system.

1 Like

This was the fix for me. In my case I’m using the linuxserver.io Docker image (https://hub.docker.com/r/linuxserver/nextcloud/), so the file to edit is config/php/php-local.ini, e.g.:

; Edit this file to override php.ini directives and restart the container

; date.timezone =
memory_limit = 512M
max_execution_time = 120
max_input_time = 90
1 Like

Hi,

  • sudo -u www-data php occ maintenance:repair

works for me to, but I need to use:

  • sudo -u www-data php7.2 occ maintenance:repair

Here is the workflow that helped me with this problem.

After the download failed I downloaded the file (in my case nextcloud-18.0.7.zip) manually.
Then I replaced the incomplete file in the directory data/updater-xxxxxxxxxxxxx/downloads/ via FTP with the complete one.
I updated the file data/updater-xxxxxxxxxxxxxxx/.step as follows:
{"state": "end", "step":4}

Afterwards I could reload the page with the update and continue the update at step 5.

4 Likes

Nice. Perhaps in further releases the updater can check the downloads-dir, check the checksum and skip the download.

1 Like

Checking/Modifying the “.step”-file is a good catch. Yet in my case, “.step” contained just that – but re-downloaded the ZIP anyway. The updater really should try to resume prior to reload.

This works for me upgrading from 18.0.4 to 18.0.10. Thanks.

Why is this post marked as “solution”? :slight_smile:

Make sure your webserver gives PHP enough time to download the update file.
For nginx this would be in nginx.conf:

http {
    proxy_connect_timeout  600s;
    proxy_send_timeout  600s;
    proxy_read_timeout  600s;
    fastcgi_send_timeout 600s;
    fastcgi_read_timeout 600s;
}

The PHP settings mentioned above still apply of course.

press F5/reload the page with resubmit form data and it should work as normal as long as the download has finished, that’s what I’ve been doing for years to get around this oddball updater.

I’m realizing that I never accepted a Solution to this! If you’re encountering the problem on a shared webhost like Dreamhost, the solution is definitely to update manually.

I have problems with the updater every time I upgrade. I wonder if no one else has this problem and why it is still an issue. same situation as above, the app stalls at a certain point and I need to do some kind of manual fix to delete a file or other. I have tried increasing time outs where possible, but I am on a shared host so it is not always possible. Why can there not be a simpler solution? just download the new version, put it in a directory and go. I dont need a backup, can skip the version checks on the new version .zip. I just need it to update without taking 2 days to finally luck on to a final step. this time it kaks at extracting, done it 3 times. it has made 6 backups so my storage is full and need to delete with filezilla. really at my end with this. Is there a better way? If need to do manual, what is the point in a update app?