10.0.7 owncloud.log integrity failure

upgrade
10

#1

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


#3

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?


#4

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.