Would be good to have some form of automated testing. Each test should have a different env, one with symlinks, one with separate datadir, etc.
The test would setup a give OC version from a tarball, upload some test files, then run the upgrade code from the updater app API. Then check if the resulting upgrade contains the files, and also whether the backup also contains them
The target OC could also be a local tarball.

Not sure how many changes are needed in the current code for that but it would be good to have.

During web update from 6.0.2 to 6.0.4 i got this error:

{"app":"PHP","message":"rename(): The first argument to copy() function cannot be a directory at \/owncloud\/apps\/updater\/lib\/helper.php#27","level":2,"time":"2014-07-09T19:04:42+00:00"}
{"app":"PHP","message":"rename(\/owncloud\/3rdparty\/Archive,\/geli\/owncloud_data\/\/updater_backup\/tmp\/3rdparty\/Archive): Cross-device link at \/owncloud\/apps\/updater\/lib\/helper.php#27","level":2,"time":"2014-07-09T19:04:42+00:00"}
{"app":"updater","message":"Something went wrong for 3rdparty. Rolling back.","level":3,"time":"2014-07-09T19:04:42+00:00"}
{"app":"updater","message":"Unable to move \/owncloud\/3rdparty\/Archive to \/geli\/owncloud_data\/\/updater_backup\/tmp\/3rdparty\/Archive","level":3,"time":"2014-07-09T19:04:42+00:00"}

The Updater-App makes a backup of the installation before performing the Update. But the ZIP file holding the backup does not contain the .htaccess file.

needed

Message on screen:

"Empfangen des Paketes fehlgeschlagen

Das Update ist fehlgeschlagen. Bitte überprüfen Sie die Logs auf der Administratorseite und melden Sie dieses Problem an die ownCloud Gemeinschaft."

Messages in log:
Error updater /share/Web/e0fe98582f33fefdf2ca9cc0411c748c.zip extraction error 2014-11-21T20:22:47+00:00
Error updater Retrieving http://download.owncloud.org/community/owncloud-7.0.3.zip 2014-11-21T20:22:47+00:00
Error PHP ZipArchive::extractTo() [ziparchive.extractto]: Invalid or unitialized Zip object at /share/MD0_DATA/Web/owncloud/lib/private/archive/zip.php#135 2014-11-21T20:22:46+00:00

Maybe it would also be a good idea to keep the chapter "update" in the docs since there's no documented alternative way to update.
Maybe also updating (and also upgrading) using occ including backup would be a great idea.....

Steps to reproduce:

1. Download the owncloud-6.0.3 tarball
2. Extract it
3. Move it to "/var/www/owncloud"
4. Setup the permissions: mkdir -p data; chgrp www-data apps config data; chmod 0770 data; chmod g+w apps config
5. Run the owncloud setup
6. Go to the "Administration" section
7. Click on "Update center"
8. Click on the "Update" tab

Expected result

Update should be available, for 6.0.4.
If for some reason there is an error, it should show it in the UI.

Actual result

Update tab is empty, looks broken.

Config

<?php
$CONFIG = array (
  'instanceid' => 'oc13964871c3',
  'passwordsalt' => '*** Removed for security reasons',
  'trusted_domains' => 
  array (
    0 => 'test-debian1.local',
  ),
  'datadirectory' => '/var/www/owncloud/data',
  'dbtype' => 'mysql',
  'version' => '6.0.3.1',
  'dbname' => 'owncloud',
  'dbhost' => 'localhost',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'owncloud',
  'dbpassword' => '*** Removed for security reasons',
  'installed' => true,
  'loglevel' => 0
);

Logs

owncloud.log is empty and there are no errors in the web server log.

Environment

On Debian 7 with Apache 2.4

We've received the same error message in General Settings | Updates

"Could not download update. Please click here to download the update manually."

I read that the newer versions contain an auto-update mechanism, but I don't understand why it's not working.

Got stuck on step 3 "replace".
Admin log entry said:
"Cannot redeclare class OC\Security\SecureRandom at /MY_WWW_PATH/owncloud/lib/private/security/securerandom.php#24"

Edit by @LukasReschke: A workaround can be found at #86 (comment)

Edit by @VicDeo: And final fix is #86 (comment)

Hello,
so far I had little success using the updater app ... sometimes it is working sometimes not. But I appreciate the improved error handling. Updating from 7.0.2 --> 7.0.3 went ok. But when I tried updating to 7.0.4 using updater app I got the following error. Installation was not changed though ...

The log says:
[Fri Jan 23 11:04:10 2015] [error] [client xxx.yyy.zzz.aaa] File does not exist: /data/www/.../html/oc/data
[Fri Jan 23 11:06:44 2015] [error] [client xxx.yyy.zzz.aaa] Script timed out before returning headers: index.php, referer: https://<mysite/oc-dirname>/index.php/apps/updater/update.php

But this is fine, because I store the data files NOT under the html tree of the owncloud installation but somewhere else as defined in the config.php and recommended for security reasons in the owncloud documentation under advanced options.

reopened: Having issues with upgrade OC server from 8.0.1 to 8.0.2 via update center:

it stops saying "server errror: look in the webserver logfile for errors".

/var/log/nginx/error.log:

2015/03/13 11:18:10 [error] 2584#0: *87986 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 5.28.69.71, server: xxxx, request: "GET /owncloud/index.php/apps/updater/ajax/backup.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock", host: "xxxx", referrer: "https://xxxx/owncloud/index.php/apps/updater/update.php"

The owncloud directory at /var/www/owncloud as well as the data directory at /mnt/crypt/owncloud have drwxrwx--- www-data www-data permissions and ownership.

This did not fix it. Still running on 8.0.1 with the yellow bar on top.

• client: firefox 36.0.1, OSX 10.7
• server: nginx 1.4.6, mariadb 5.5.41, php 5.5.9, ubuntu 14.04
• apps: Activity, Calendar, Contacts, Deleted Files, External Sites, First Run Wizard, Mail Template Editor, Mozilla Sync, PDF Viewer, Pictures, Share Files, Text Editor, Updater, Versions

Hi, we need a new command for occ.
-"update" for update the version automatically (all update process : download, backup, ...) . Same as the update center but in command line.
With this "update" command , it is necessary to have an option to keep the configuration (theme in particular)

Thank you for the quality of your work ;)
Cédric

I am unable to find where it is, but clicking on the notification message points to owncloud.org. Instead, it should open Update Center.

Updater still uses some strings from core/update.js here.

I have an older Music app version installed but the updater doesn't mention that there is a newer one. How come?

@VicDeo please merge the README file into README.md accordingly.
Thanks.

Hi guys,

In situations where you have to update manually (from OC7 to OC 8) it would be great to trigger a backup manually as well.
At the moment - I think - there is just the automatic update for minor updates like 7.0.3 to 7.0.4.

Thanks in advance for considering

Cheers

I just updated two installations from 7.0.1 to 7.0.4, i.e. I was using a fairly old version of the updater so cannot say if the problems noted here still exist - but I rather expect that the second one does.

• I got only empty messages when things went wrong, same as picture in issue 50
• The updater moves anything unknown in the docroot into its backup directory and leaves it there. This is very annoying - my nginx "owncloud.conf" disappeared, as did a directory "external", under which I keep various external local storage elements. I do this because it allows me to have an empty open_basedir, which is prerequisite for something (I think something in Sabre / Pear, can't remember exactly). So I think that the default action to leave anything unrecognised where it is would be much more user-friendly! At the moment I have to release the external local storages, move my "external" directory out of the docroot, and after the update move it back and reconnect them in ownClouds admin area. What a drag...
  Apart from such smallish annoyances I'm a great fan of ownCloud and use it heavily - many many thanks to all involved!

Hi all!

I just used the automatic updater for the update from 7.0.2 to 7.0.4 and it failed because the updater deleted the /cgi folder that I need in my all-inkl.com webspace to run higher PHP versions. After restoring it, the update went on fine …

Thank you for all the cool work! Owncloud rules!

...or does it update in some other way?

Steps to reproduce

1. Log in into ownCloud, enter Admin panel, open Update Center

Expected behaviour

OwnCloud should offer me to update from Version 7.0.2 to 7.0.4

Actual behaviour

OwnCloud does not offer an update.
Up to date. Checked on 20.02.2015 00:05:18

Server configuration

Operating system: Linux # 1 SMP Debian 3.2.65-1+deb7u1
Machine Type: x86_64
Web server: Apache
Database: MySQL
PHP version: 5.5.21
PHP Integer Size: 64 bits
OwnCloud version: 7.0.2 (stable)
Updated from an older ownCloud or fresh install: Fresh Install
List of activated apps:

• Files Move 0.7.2
• Dashboard 1.3.1
• Superlog 0.6.0

The updater throws an error at stage three - the log reveals this:
Cannot redeclare class OC\Security\SecureRandom at /xxx/xxx/xxx/htdocs/cloud/lib/private/security/securerandom.php#24

I've tried the suggested modification in #86 (comment)

PHP Info: http://goo.gl/uswY27
MD5 Hashes: http://goo.gl/tlCRDb

Expected behaviour

Tell us what should happen

Update to version 8.0.2.0

Actual behaviour

Tell us what happens instead

updater is stuck at step 3.Replace with error:
Server error. Please check web server log file for details

Tried several times but with no success. Backup files are generated in the updater_backup directory:
8.0.0.7-xxxxxx
8.0.2.0.zip

Server configuration

Operating system:
Apache/2.4.10 (Unix) OpenSSL/1.0.2 PHP/5.6.3

Web server:
Look at php info link...

ownCloud version: (see ownCloud admin page)

ownCloud 8.0 (stable)

Updated from an older ownCloud or fresh install:

The error raised when trying to update from 8.0 to 8.0.2 using the owncloud Updater app.

List of activated apps:
External Storage

The content of config/config.php:

Are you using external storage, if yes which one: local/smb/sftp/...

multiple smb shares on localhost

Are you using encryption: yes/no

yes, HTTPS enforced (self signed cert)

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...

no

LDAP configuration (delete this part if not used)

no LDAP

Client configuration

Browser:

Chrome 40

Operating system:

Tiny Core Linux

Logs

Web server error log

[mpm_prefork:error] [pid 6566] AH00161: server reached MaxRequestWorkers setting

When installing an update (from 8.0.0 to 8.0.2) and experiencing an error the loading-small.gif is displayed forever below the "3. Replace" section even though the update process terminated.

Also, should this really be a .gif animation? Suggesting a replacement with a more modern looking css or js loading symbol. (http://cssload.net/ and http://tobiasahlin.com/spinkit/ etc.)

@DeepDiver1975

The updater app should not skip versions.
If you're running on OC 5 the updater should propose updating to OC 6, not OC 7.

Currently on OC 5 it will update to OC 7 which might break because it's unsupported.

One problem now is that we probably don't want to fix/touch the updater shipped with OC 5.
But this issue still needs to be fixed for future OC versions.

@VicDeo

Expected Behavior

Open the updater and get the oC8 version

Actual Behavior

Open the updater and says there is no new version.

Steps to reproduce:

1.- Open the updater and run it.

oC Version

7.0.4 Community edition

Thanks 😃

Consider using IRequest.

Ref owncloud/core#14574

At least for the past two updates the update process shows a misleading message.

"Please fix this and retry." is displayed but there is nothing to fix and actually there is also no way to retry.

The expected output would be this text now showing up if there are no issues to fix. Alternatively if there would be something to fix it should also be more clear of how to do the "retry".

When I try to open the updater app, I get:

Fatal error: Call to a member function getValue() on a non-object in <htdocs>/owncloud8a1/lib/private/updater.php on line 84

@schiesbn is suggesting that for people who use the updater app, the update should be iterative: 6.0.1 then 6.0.2 then 6.0.3, etc to make sure that all update scripts run in the correct order because some scripts might only run for example between 6.0.2 and 6.0.3.

This is mostly assuming that the updater app is used by less tech-savvy people.
Such iterative update path is not possible when using distro package managers.

I'm not convinced that it's a good idea and think that update code needs to support update paths like 6.0.1 to 6.0.4.

But let's discuss @karlitschek

The latest updater design-changes go straight into a good direction.
I want to collect some issues that I noticed doing the last update and provide solutions.

1. It's still not visible whether the updater is actually working on something.
   Solution: Add a spinner to the steps to show that the updater is working
2. Important messages look like every other text on the page.
   Solution: Highlight important notifications like "Everything done." to create a hierarchy between text elements
3. The "Next" button is no button.
   Solution: Make the "Next" button a real button

I think, managing those details would be a good usability optimization.
What do you think about my suggestions?

There are at least two bug reports here from 4.5 days where trying to use the updater would result in a fresh config.php being created if the updater had write access. For some reason, it happened again for me today when I was trying to upgrade from 6.0.4 to 7.0.0.

I'm not sure the updater works correct. The Updater says it's "up to date" but there is a new version of ownCloud (7.0.4). Is there a possibility to point the updater to the new version?

Steps to reproduce

The error raised when trying to update from 8.0 to 8.0.2 using the owncloud Updater app.

Expected behaviour

Tell us what should happen

Update to version 8.0.2.0

Actual behaviour

Tell us what happens instead

updater is stuck at step 3.Replace with error:
Server error. Please check web server log file for details

Tried several times but with no success. Backup files are generated in the updater_backup directory:
Sicherungen

Sicherungverzeichnis: /.../updater_backup/

Sicherung Abgeschlossen am
8.0.0.7-1d5bdf09 March 11 2015 15:31:49
8.0.0.7-25b2a165 March 11 2015 15:42:29
8.0.0.7-ce5adbb3 March 11 2015 15:38:11

Server configuration

Operating system:
Ubuntu Server 14.04.2 LTS

Web server:
Apache/2.4.12 (Ubuntu)

Database:
MySQL Server 5.5.41-0ubuntu0.14.04.1

PHP version:
PHP 5.6.6-1+deb.sury.org~trusty+1 (cli) (built: Feb 20 2015 11:22:10)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
with XCache v3.2.0, Copyright (c) 2005-2014, by mOo
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2015, by Zend Technologies
with XCache Optimizer v3.2.0, Copyright (c) 2005-2014, by mOo
with XCache Cacher v3.2.0, Copyright (c) 2005-2014, by mOo
with XCache Coverager v3.2.0, Copyright (c) 2005-2014, by mOo

ownCloud version: (see ownCloud admin page)

ownCloud 8.0 (stable)

Updated from an older ownCloud or fresh install:
Fresh installed 8.0.0

List of activated apps:
Activity 1.2.0
Bookmarks 0.4
Calendar 0.6.4
Contacts 0.3.0.18
Deleted files 0.6.2
Documents 0.9.0
External Sites 1.2
External storage support 0.2.3
External user support 0.4
File Locking
First Run Wizard 1.1
Full Text Search 0.6.0
Mail Template Editor 0.1
PDF Viewer 0.7
Pictures 0.6.0
Provisioning API 0.2
Share Files 0.6.0
Text Editor 0.4
Video Viewer 0.1.3
WebDAV user backend 1.1.0.1

The content of config/config.php:

I have, on more than one occasion, found core apps such as files_trashbin and files_versions missing after using the updater.

I updated from 7.0.1 to 7.0.2 on 2014-08-30T08:30 and subsequently discovered the apps/files_versions directory was completely missing. There is nothing in owncloud.log about the update, much less anything having gone wrong.

The only indication was an error because code in files_trashbin depended on files_versions being present, and those errors began shortly after the update took place (see owncloud/core#11387).

1. the Updater app should do some logging
2. how could such an important directory be deleted and not replaced during update?

Hello, i have bitnami owncloud and its failed to update automaticaly in admin page.
screenshot.
https://www.evernote.com/shard/s245/sh/b75eb408-f4d0-4a90-a812-7b322e119eb6/321b721cf95e541c9221a02abf275e50

Checking your installation...
Downloading package...
Creating backup...

its create backup in
my data derectory and nothing next!

rights of htdocs
drwxr-xr-x 12 daemon daemon 4096 Jan 13 17:42 htdocs
of updater_backup
drwxr-xr-x 1 daemon daemon 0 Nov 26 01:03 updater_backup

log

{"app":"updater","message":"Backup creation failed. Check permissions.","level":3,"time":"2015-01-12T19:56:28+00:00"}
{"app":"updater","message":"Unable copy /opt/bitnami/apps/owncloud/htdocs/3rdparty/rackspace/php-opencloud/lib/OpenCloud/Common/Exceptions/HttpError.php to /home/s3/data/updater_backup/7.0.2.1-588dba99/3rdparty/rackspace/php-opencloud/lib/OpenCloud/Common/Exceptions/HttpError.php","level":3,"time":"2015-01-12T20:25:02+00:00"}
{"app":"PHP","message":"Division by zero at /opt/bitnami/apps/owncloud/htdocs/lib/private/preview.php#426","level":3,"time":"2015-01-12T23:39:07+00:00"}
{"app":"PHP","message":"copy(/home/s3/data/updater_backup/7.0.2.1-075fc243/3rdparty/phpmailer/phpmailer/examples/gmail.phps): failed to open stream: No such file or directory at /opt/bitnami/apps/owncloud/htdocs/apps/updater/lib/helper.php#56","level":3,"time":"2015-01-13T14:23:45+00:00"}
{"app":"updater","message":"Backup creation failed. Check permissions.","level":3,"time":"2015-01-13T14:23:46+00:00"}
{"app":"updater","message":"Unable copy /opt/bitnami/apps/owncloud/htdocs/3rdparty/phpmailer/phpmailer/examples/gmail.phps to /home/s3/data/updater_backup/7.0.2.1-075fc243/3rdparty/phpmailer/phpmailer/examples/gmail.phps","level":3,"time":"2015-01-13T14:45:32+00:00"}
{"app":"PHP","message":"mkdir(): No such file or directory at /opt/bitnami/apps/owncloud/htdocs/apps/updater/lib/helper.php#69","level":3,"time":"2015-01-13T16:00:28+00:00"}
{"app":"updater","message":"Backup creation failed. Check permissions.","level":3,"time":"2015-01-13T16:00:30+00:00"}

While editing the controller.js file I found four messages that could be displayed to the user while updating that have no visual clue and are therefore difficult to classify at first glance.

I added some formatting classes already "shipped" with ownCloud and took screenshots.
Additionally, I added a short explanations for discussion.

Make the important information Up to date bold and slightly emphasize the subinformation when this was checked. Same goes for A new version is available.

Emphasize the important information All done to make it visible at first glance.

Give a visual clue to show something went wrong during the update. Important information is bold, additional information is in the next line.

Same as the last one.

Maybe the difference between the messages is still too big. The information-messages could be a bit more present, while the error-messages could be a bit more unobtrusive.

Another problem is: For the changes depicted here to be made, html-tags would have to be added to translations. According to this http://doc.owncloud.org/server/6.0/developer_manual/core/translation.html#you-shall-never-split-sentences that's the only way to add the formattings, as splitting of translations is not recommend.

What's your opinion on the suggestions?

I ran into this error while updating from the first 7 stable version (I guess 7.0.0) to 7.0.2 from within the backend. After downloading successfully, the database update crashes with the error below.

I've had this with a different application using Doctrine. Is there any problem with my server setup?

Sincerely
JJ

Unknown column type "objectarray" requested. Any Doctrine type that you use has to be registered with \Doctrine\DBAL\Types\Type::addType(). You can get a list of all the known types with \Doctrine\DBAL\Types\Type::getTypeMap(). If this error occurs during database introspection then you might have forgot to register all database types for a Doctrine Type. Use AbstractPlatform#registerDoctrineTypeMapping() or have your custom types implement Type#getMappedDatabaseTypes(). If the type name is empty you might have a problem with the cache or forgot some mapping information.

As already discussed in the past in owncloud/core#5279 and owncloud-archive/apps#1640

I hope after we merge the style fixes #39 we can look into moving the whole thing directly into admin settings. And making the »Backup« part less confusing.

cc @VicDeo @DeepDiver1975

as per owncloud/core#11037:

If the zipping fails (e.g., due to timeout) the updater could actually degrade gracefully and tell the user in the next request that zipping failed, but that an unzipped backup is kept, delete the "half-zipped" stuff and then move on?

Sadly i cant use the update center

/www/htdocs/MY_ACCOUNT
/www/htdocs/MY_ACCOUNT/cgi-bin
/www/htdocs/MY_ACCOUNT/logs
/www/htdocs/MY_ACCOUNT/usage

I think for these directories the permission check should be disabled since i am on a shared host and have no access to these folder permissions.

I just got told I should report this here (from owncloud-archive/apps#1991 ):

Updating owncloud fails for me. It says:
The update was unsuccessful. Please check logs at admin page and report this issue to the ownCloud community.

This is in the log:
Error PHP Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. at Unknown#0 2014-12-11T20:16:54+00:00
Error PHP Cannot modify header information - headers already sent at /home/hanno/websites/own.hboeck.de/htdocs/lib/private/json.php#17 2014-12-11T20:16:54+00:00
Debug updater Use already downloaded package /home/hanno/websites/own.hboeck.de/data/updater_backup/7.0.4.2.zip. Size is 40173917 bytes. 2014-12-11T20:16:48+00:00
Error PHP Cannot modify header information - headers already sent at /home/hanno/websites/own.hboeck.de/htdocs/lib/private/response.php#219 2014-12-11T20:16:48+00:00
Error PHP Cannot modify header information - headers already sent at /home/hanno/websites/own.hboeck.de/htdocs/lib/private/response.php#216 2014-12-11T20:16:48+00:00
Error PHP Cannot modify header information - headers already sent at /home/hanno/websites/own.hboeck.de/htdocs/lib/private/response.php#203 2014-12-11T20:16:48+00:00
Error PHP Cannot modify header information - headers already sent at /home/hanno/websites/own.hboeck.de/htdocs/lib/private/response.php#198 2014-12-11T20:16:48+00:00
Error PHP Cannot modify header information - headers already sent at /home/hanno/websites/own.hboeck.de/htdocs/lib/private/response.php#197 2014-12-11T20:16:48+00:00
Error PHP Cannot modify header information - headers already sent at /home/hanno/websites/own.hboeck.de/htdocs/lib/base.php#235 2014-12-11T20:16:48+00:00
Error PHP session_start(): Cannot send session cache limiter - headers already sent at /home/hanno/websites/own.hboeck.de/htdocs/lib/private/session/internal.php#21 2014-12-11T20:16:48+00:00

Since activity is separated from the core repository, it does not update the translations from transifex.

@DeepDiver1975

Like the one mentioned here: owncloud/activity#34

There is no log entry from the time I tried this update.

On a previous failed try, I got:

Backup creation failed. Check permissions.

No indication about which permissions and how to change them. So I Googled, not finding much concrete about the permissions except for a blog which advised doing

chown -R www-data:www-data owncloud

which gave me more lines than my ssh history of operation not permitted.

After this, I nevertheless tried the updater again (hoping there had been some successful pre-historical chowns). The result is the screenshot above.

Please advise on further action. (I guess the bug I'm reporting is the lack of concretely useful feedback when the update fails.)

EDIT: I tried it again, got the same error message, went to refresh the list of backups... and then the update started and seems to have finished correctly. Strange, but nice outcome; so no advice on further action is needed.

Test once owncloud/core#10626 is merged

Original code is 7.0.0, Updater shows there is a new update. Once you click on "update" button it disappears and nothing happens.
Please let me know what information you need

Several users have reported that the updater fails and no error message is written to the LOG file.
"Please fix and retry"
Since I have two installations with different behaviour (one is exatly fauling without error log, while the other runs updates just fine), I looked into the Updater code and recognized that it is utilizing PEAR from the 3rd party archive apps. I could not find any check to make sure PEAR is supported though.
Could you pls. check and confirm if a mising PHP config configured '--without-pear' could result in such silent updater issue.
Thanx much in advance.

Steps to reproduce

1. log in as admin user
2. go to the admin panel
3. click Updater in the left panel
4. click the "Open Update Center" button

Expected behaviour

The update center should open, I guess.

Actual behaviour

following error message is shown:
Fatal error: Call to a member function getValue() on a non-object in /usr/local/apache2/htdocs/owncloud8/lib/private/updater.php on line 84

Server configuration

Operating system:
Slackware Linux x64

Web server:
Apache 2.4.10

Database:
MariaDB 5.5.40

PHP version:
5.5.19

ownCloud version: (see ownCloud admin page)
8 alpha 2

Updated from an older ownCloud or fresh install:
updated from OC8 alpha 1 (manual installation)
this updater problem was present in OC8 alpha 1 as well

List of activated apps:
Since I can't enable any app (another issue with OC8),
only the default OC8 apps are active currently.

The content of config/config.php:

<?php
$CONFIG = array (
  'instanceid' => 'octgvzn2tj6m',
  'trusted_domains' => 
  array (
    0 => 'aivpc80',
  ),
  'datadirectory' => '/home/oc8data/',
  'overwrite.cli.url' => 'http://aivpc80/owc8',
  'dbtype' => 'mysql',
  'version' => '8.0.0.2',
  'dbname' => 'oc8',
  'dbhost' => 'localhost',
  'dbtableprefix' => 'oc_',
  'installed' => true,
  'theme' => '',
  'maintenance' => false,
);

Insert your config.php content here
(Without the database password, passwordsalt and secret)

Are you using external storage, if yes which one: local/smb/sftp/...
no

Are you using encryption: yes/no
no

Client configuration

Browser:
Firefox 34

Operating system:
Slackware Linux 14.1

Logs

Web server error log

[Thu Jan 08 15:04:31.807946 2015] [mpm_event:notice] [pid 4705:tid 139653527857024] AH00489: Apache/2.4.10 (Unix) PHP/5.5.19 configured -- resuming normal operations
[Thu Jan 08 15:04:31.808248 2015] [core:notice] [pid 4705:tid 139653527857024] AH00094: Command line: '/usr/local/apache2/bin/httpd'
[Thu Jan 08 15:04:43.154552 2015] [access_compat:error] [pid 4791:tid 139653306423040] [client 134.184.28.151:45403] AH01797: client denied by server configuration: /usr/local/apache2/htdocs/owncloud8/data/htaccesstest.txt
[Tue Jan 13 16:01:21.630074 2015] [access_compat:error] [pid 4791:tid 139653067761408] [client 134.184.28.151:45527] AH01797: client denied by server configuration: /usr/local/apache2/htdocs/owncloud8/data/htaccesstest.txt
[Tue Jan 13 17:00:30.613154 2015] [access_compat:error] [pid 4706:tid 139653298030336] [client 134.184.28.151:45532] AH01797: client denied by server configuration: /usr/local/apache2/htdocs/owncloud8/data/htaccesstest.txt
[Wed Jan 14 11:33:07.159718 2015] [access_compat:error] [pid 4707:tid 139653339993856] [client 134.184.28.151:45634] AH01797: client denied by server configuration: /usr/local/apache2/htdocs/owncloud8/data/htaccesstest.txt

ownCloud log (data/owncloud.log)

{"reqId":"30bdfac704c50c89e71e7f5c1ae7b3fa","remoteAddr":"134.184.28.72","app":"no app in context","message":"Accessing the server container is deprecated. Use type annotations to inject core services instead!","level":2,"time":"2015-01-13T15:56:59+00:00"}
{"reqId":"90903fc14370c0520d76085f9bad3e7f","remoteAddr":"134.184.28.72","app":"no app in context","message":"Accessing the server container is deprecated. Use type annotations to inject core services instead!","level":2,"time":"2015-01-13T15:57:05+00:00"}
{"reqId":"c2941d4583508078db3831ea8b01529f","remoteAddr":"134.184.28.72","app":"no app in context","message":"Accessing the server container is deprecated. Use type annotations to inject core services instead!","level":2,"time":"2015-01-13T15:57:05+00:00"}
{"reqId":"25d07be4228610b90b209457332ee556","remoteAddr":"134.184.28.72","app":"no app in context","message":"Accessing the server container is deprecated. Use type annotations to inject core services instead!","level":2,"time":"2015-01-13T15:57:06+00:00"}
{"reqId":"61ef58d908c959cf11fe4aad922f8e25","remoteAddr":"134.184.28.72","app":"no app in context","message":"Accessing the server container is deprecated. Use type annotations to inject core services instead!","level":2,"time":"2015-01-13T15:57:06+00:00"}
{"reqId":"d24474c9a64d48cfe30750bc8b799734","remoteAddr":"134.184.28.72","app":"PHP","message":"Missing argument 1 for OC\\Updater::__construct(), called in \/usr\/local\/apache2\/htdocs\/owncloud8\/apps\/updater\/update.php on line 27 and defined at \/usr\/local\/apache2\/htdocs\/owncloud8\/lib\/private\/updater.php#46","level":3,"time":"2015-01-13T16:00:48+00:00"}
{"reqId":"d24474c9a64d48cfe30750bc8b799734","remoteAddr":"134.184.28.72","app":"PHP","message":"Missing argument 2 for OC\\Updater::__construct(), called in \/usr\/local\/apache2\/htdocs\/owncloud8\/apps\/updater\/update.php on line 27 and defined at \/usr\/local\/apache2\/htdocs\/owncloud8\/lib\/private\/updater.php#46","level":3,"time":"2015-01-13T16:00:48+00:00"}
{"reqId":"d24474c9a64d48cfe30750bc8b799734","remoteAddr":"134.184.28.72","app":"PHP","message":"Undefined variable: httpHelper at \/usr\/local\/apache2\/htdocs\/owncloud8\/lib\/private\/updater.php#47","level":3,"time":"2015-01-13T16:00:48+00:00"}
{"reqId":"d24474c9a64d48cfe30750bc8b799734","remoteAddr":"134.184.28.72","app":"PHP","message":"Undefined variable: config at \/usr\/local\/apache2\/htdocs\/owncloud8\/lib\/private\/updater.php#49","level":3,"time":"2015-01-13T16:00:48+00:00"}
{"reqId":"d24474c9a64d48cfe30750bc8b799734","remoteAddr":"134.184.28.72","app":"PHP","message":"Call to a member function getValue() on a non-object at \/usr\/local\/apache2\/htdocs\/owncloud8\/lib\/private\/updater.php#84","level":3,"time":"2015-01-13T16:00:48+00:00"}
{"reqId":"ccb602ba6b98dbc814834ae55d8ca5c1","remoteAddr":"134.184.28.72","app":"core","message":"App does not provide an info.xml file","level":3,"time":"2015-01-13T16:12:52+00:00"}
{"reqId":"61438ab0a7088408ef1ed992c402a970","remoteAddr":"134.184.28.72","app":"core","message":"App does not provide an info.xml file","level":3,"time":"2015-01-13T16:12:59+00:00"}
{"reqId":"c7bda8ccd84faaef695b9ba7619539c8","remoteAddr":"134.184.28.72","app":"core","message":"App does not provide an info.xml file","level":3,"time":"2015-01-13T16:13:09+00:00"}
{"reqId":"f5d3d1faf4c8dd70e8b0154c67a5e5ed","remoteAddr":"134.184.28.72","app":"core","message":"App does not provide an info.xml file","level":3,"time":"2015-01-13T16:13:17+00:00"}
{"reqId":"9a22f742ca93e790c40f9dd16cac8d5e","remoteAddr":"134.184.28.72","app":"core","message":"App does not provide an info.xml file","level":3,"time":"2015-01-14T10:19:05+00:00"}
{"reqId":"e619b8556169690b9fca43e61ea89192","remoteAddr":"134.184.28.72","app":"core","message":"App does not provide an info.xml file","level":3,"time":"2015-01-14T10:19:13+00:00"}
{"reqId":"6834795b3838bc4267db2442b463a88c","remoteAddr":"134.184.28.72","app":"PHP","message":"Missing argument 1 for OC\\Updater::__construct(), called in \/usr\/local\/apache2\/htdocs\/owncloud8\/apps\/updater\/update.php on line 27 and defined at \/usr\/local\/apache2\/htdocs\/owncloud8\/lib\/private\/updater.php#46","level":3,"time":"2015-01-14T10:33:21+00:00"}
{"reqId":"6834795b3838bc4267db2442b463a88c","remoteAddr":"134.184.28.72","app":"PHP","message":"Missing argument 2 for OC\\Updater::__construct(), called in \/usr\/local\/apache2\/htdocs\/owncloud8\/apps\/updater\/update.php on line 27 and defined at \/usr\/local\/apache2\/htdocs\/owncloud8\/lib\/private\/updater.php#46","level":3,"time":"2015-01-14T10:33:21+00:00"}
{"reqId":"6834795b3838bc4267db2442b463a88c","remoteAddr":"134.184.28.72","app":"PHP","message":"Undefined variable: httpHelper at \/usr\/local\/apache2\/htdocs\/owncloud8\/lib\/private\/updater.php#47","level":3,"time":"2015-01-14T10:33:21+00:00"}
{"reqId":"6834795b3838bc4267db2442b463a88c","remoteAddr":"134.184.28.72","app":"PHP","message":"Undefined variable: config at \/usr\/local\/apache2\/htdocs\/owncloud8\/lib\/private\/updater.php#49","level":3,"time":"2015-01-14T10:33:21+00:00"}
{"reqId":"6834795b3838bc4267db2442b463a88c","remoteAddr":"134.184.28.72","app":"PHP","message":"Call to a member function getValue() on a non-object at \/usr\/local\/apache2\/htdocs\/owncloud8\/lib\/private\/updater.php#84","level":3,"time":"2015-01-14T10:33:21+00:00"}
{"reqId":"c932899c98b08dac3d43af64a33ba00d","remoteAddr":"134.184.28.72","app":"PHP","message":"Missing argument 1 for OC\\Updater::__construct(), called in \/usr\/local\/apache2\/htdocs\/owncloud8\/apps\/updater\/update.php on line 27 and defined at \/usr\/local\/apache2\/htdocs\/owncloud8\/lib\/private\/updater.php#46","level":3,"time":"2015-01-14T10:35:10+00:00"}
{"reqId":"c932899c98b08dac3d43af64a33ba00d","remoteAddr":"134.184.28.72","app":"PHP","message":"Missing argument 2 for OC\\Updater::__construct(), called in \/usr\/local\/apache2\/htdocs\/owncloud8\/apps\/updater\/update.php on line 27 and defined at \/usr\/local\/apache2\/htdocs\/owncloud8\/lib\/private\/updater.php#46","level":3,"time":"2015-01-14T10:35:10+00:00"}
{"reqId":"c932899c98b08dac3d43af64a33ba00d","remoteAddr":"134.184.28.72","app":"PHP","message":"Undefined variable: httpHelper at \/usr\/local\/apache2\/htdocs\/owncloud8\/lib\/private\/updater.php#47","level":3,"time":"2015-01-14T10:35:10+00:00"}
{"reqId":"c932899c98b08dac3d43af64a33ba00d","remoteAddr":"134.184.28.72","app":"PHP","message":"Undefined variable: config at \/usr\/local\/apache2\/htdocs\/owncloud8\/lib\/private\/updater.php#49","level":3,"time":"2015-01-14T10:35:10+00:00"}
{"reqId":"c932899c98b08dac3d43af64a33ba00d","remoteAddr":"134.184.28.72","app":"PHP","message":"Call to a member function getValue() on a non-object at \/usr\/local\/apache2\/htdocs\/owncloud8\/lib\/private\/updater.php#84","level":3,"time":"2015-01-14T10:35:10+00:00"}

Browser log

Insert your browser log here, this could for example include:

a) The javascript console log
b) The network log 
c) ...

When using updater to go from 7.0.0 to 7.0.1, prior to the DB update, the following appears:

There is no error, but it says "Please fix this and retry."
Then proceed below takes you to the Database update, which is successful.

A follow up on:
owncloud/core#9314
owncloud/core#9290

• Fix empty error https://cloud.githubusercontent.com/assets/2955584/3443342/7a0dcde8-0121-11e4-9824-c4d81cfee53e.png
• Report any files that may need r/w permission

System 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u1 x86_64 GNU/Linux
PHP 5.5.15-1~dotdeb.1 (cli) (built: Jul 24 2014 16:44:04)
Zend Engine v2.5.0 with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies

Well, i had a lot of surprises with Owncloud but this surpasses all:

I just used the internal Updater App in OC 6.0.3 to update to 6.0.4 and this is what happened

• All files on the server (owncloud/data) where deleted.
• The Sync Client then deleted all local files.
• No Backup was created.
• Owncloud.log is empty.

The only "special" part of my installation was that i had the data directory on a different drive, as per config.php:

'datadirectory' => '/media/owncloud_DATA',

Fortunately i have the OC Data synced with two computers and one is turned off right now, so i hope i can restore the data from that one.

Since there is no log, i dont think i can help with anymore information how to solve this, but i just want to express my disappointment in this, since it makes you feel owncloud should never have left the Beta phase.