10.0.7 owncloud.log integrity failure

Steps to reproduce

  1. Upgrade 10.0.6 to 10.0.7 using web ui updater on ubuntu 16.04.3 LTS x86_64 with PHP 7.2.2

Expected behaviour

Normal upgrade behaviour

Actual behaviour

Integrity check failure on owncloud.log:

Results
=======
- core
	- EXTRA_FILE
		- owncloud.log

Raw output
==========
Array
(
    [core] => Array
        (
            [EXTRA_FILE] => Array
                (
                    [owncloud.log] => Array
                        (
                            [expected] => 
                            [current] => be688838ca8686e5c90689bf2ab585cef1137c999b48c70b92f67a5c34dc15697b5d11c982ed6d71be1e1e7f7b4e0733884aa97c3f7a339a8ed03577cf74be09
                        )

                )

        )

)

If I delete the log, the log is recreated by owncloud when I issue a rescan so it always fails the checksum even if the log is empty.

Server configuration

Operating system: Ubuntu 16.04.3 LTS

Web server: nginx/1.13.8

Database: mysql Ver 15.1 Distrib 10.2.13-MariaDB

PHP version: 7.2.2-3+ubuntu16.04.1+deb.sury.org+1

ownCloud version: (see ownCloud admin page) 10.0.7.2

Updated from an older ownCloud or fresh install: 10.0.6

Where did you install ownCloud from: Can't remember I've had it for years, pre v8.

Signing status (ownCloud 9.0 and above): See issue above.

Login as admin user into your ownCloud and access 
http://example.com/index.php/settings/integrity/failed 
paste the results into https://gist.github.com/ and puth the link here.

Integrity failure is part of the issue so not creating gist.

The content of config/config.php:

Log in to the web-UI with an administrator account and click on
'admin' -> 'Generate Config Report' -> 'Download ownCloud config report'
This report includes the config.php settings, the list of activated apps
and other details in a well sanitized form.

or 

If you have access to your command line run e.g.:
sudo -u www-data php occ config:list system
from within your ownCloud installation folder

*ATTENTION:* Do not post your config.php file in public as is. Please use one of the above
methods whenever possible. Both, the generated reports from the web-ui and from occ config:list
consistently remove sensitive data. You still may want to review the report before sending.
If done manually then it is critical for your own privacy to dilligently
remove *all* host names, passwords, usernames, salts and other credentials before posting.
You should assume that attackers find such information and will use them against your systems.

List of activated apps:

If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your ownCloud installation folder.

Enabled:
- comments: 0.3.0
- configreport: 0.1.1
- dav: 0.3.2
- federatedfilesharing: 0.3.1
- federation: 0.1.0
- files: 1.5.1
- files_external: 0.7.1
- files_sharing: 0.10.1
- files_trashbin: 0.9.1
- files_versions: 1.3.0
- files_videoplayer: 0.9.8
- firstrunwizard: 1.1
- market: 0.2.3
- notifications: 0.3.2
- provisioning_api: 0.5.0
- systemtags: 0.3.0
- templateeditor: 0.2
- updatenotification: 0.2.1
Disabled:
- encryption
- external
- theme-example
- user_external

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

Are you using encryption: yes/no
Only in transit (TLS), not at rest (filesystem).

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

Client configuration

Browser:

Operating system:

Logs

Web server error log

Insert your webserver log here

ownCloud log (data/owncloud.log)

Insert your ownCloud log here

Log is empty

Can you try to define the log file location in your config.php and try again?

https://doc.owncloud.com/server/10.0/admin_manual/configuration/server/config_sample_php_parameters.html?highlight=config#logging

Help me understand:

You have the owncloud.log for some reason in the core dir. You delete it, and ownCloud creates it in core again?

Ah you're right, for some reason there was an owncloud.log in the core dir as well as the default in the data dir. Must have been an artefact from a previous upgrade, I guess.

Once I deleted the log in the core dir and did a rescan, the integrity check passed.

Thanks for your help.