Log size huge and how to fix it

I recently updated OC to v10, at which point I noticed the log was almost 400 MB...

[root@cyndane logrotate.d]# ls -lh /home/owncloud/data/owncloud.log
-rw-r-----. 1 apache apache 368M Jun 9 09:15 /home/owncloud/data/owncloud.log

Searching the web and testing the log_rotate_size in config.php didn't do it for my install. I kept getting CSRF-errors which were only resolved by temporarily disabling the files_sharing module from the CLI.
So I turned to the built-in logrotate daemon, and this is how I did it. Hopefully it may be of help to others.

Assuming root access is available.
This is on CentOS 6.9 x64.
Owncloud data-folder is located in /home/owncloud, ie /home/owncloud/data/owncloud.log

  1. Create a file called owncloud in /etc/logrotate.d.
  2. Enter the below.

rotate 3
create 644 apache apache
/usr/bin/killall -HUP rsyslogd

  1. Save and close the file.
  2. Test the logrotation manually.

logrotate -f /etc/logrotate.d/owncloud

[root@cyndane logrotate.d]# ls -lh /home/owncloud/data/owncloud.log
-rw-r--r-- 1 apache apache 0 Jun 9 09:23 /home/owncloud/data/owncloud.log

That's it.


@adrianvg thanks for this info... I am on a shared hosted web server and I do have access to the folders you refer to and I can create the file where you state but after that I'm not really sure what to do... I am sure my log file is just way to big its now almost 600M and I really want to either delete or archive it or something

EDIT: I did delete the file and let it create a new one until I can figure this out

Sorry for the incredibly late reply, but for some reason I don't get any alerts to my posts.

After having created the file /etc/logrotate.d/owncloud, that should be it.
The log will be rotated automagically in the background.

Just in case, check that /etc/logrotate.d/owncloud has permissions set to 644.

See the docs https://doc.owncloud.org/server/latest/admin_manual/configuration/server/config_sample_php_parameters.html?highlight=log_rotate_size#logging

There is log_rotate_size which will rotate the log based on it's size

Yeah, that didn't work for me for some reason. I just got loads of CSRF-errors. :frowning:

I see - good to know .... we will test this .... THX

I've tried logrotation with 10.0.2 , 10.0.3beta and the current git version and cannot reproduce that issue
So here is how I've tested:
1. in the config.php set

  'log_rotate_size' => 10485760,
  'loglevel' => 0,
  1. copied 10480760 bytes of random data into the log file
  2. run UI tests to simulate all kind of user activity

After a while the log gets rotated and I have messages like this in the logfile:

{"reqId":"fE3gDwW0lmgi22cuVF1H","level":0,"time":"2017-08-21T11:50:25+00:00","remoteAddr":"::1","user":"--","app":"cron","method":"GET","url":"\/owncloud-core\/cron.php","message":"Finished background job, the job took : 0 seconds, this job is an instance of class : OC\\Log\\Rotate with arguments : \/home\/artur\/www\/owncloud-core\/data\/owncloud.log"}

would you mind tell me the exact version you are using or even fill the github issue template: https://github.com/owncloud/core/issues/new

1 Like


Was yours a fresh OC install?
I'm thinking my non-fresh installs (ie updates over previous installs) and certificate tinkering to harden stuff, may have done something.

My current version:

System Status
installed true
maintenance false
needsDbUpgrade false
versionstring 10.0.2
edition Community
productname ownCloud

Could you also please post 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.


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.

Real url replaced with "fqdn.com".

[root@cyndane owncloud]# sudo -u apache php occ config:list system
"system": {
"instanceid": "ocfdfc96a2a2",
"passwordsalt": "REMOVED SENSITIVE VALUE",
"trusted_domains": [
"datadirectory": "\/home\/owncloud\/data",
"dbtype": "mysql",
"version": "",
"installed": true,
"maxZipInputSize": 5261334937.6,
"allowZipDownload": true,
"forcessl": false,
"theme": "",
"maintenance": false,
"mail_smtpmode": "php",
"loglevel": 1,
"dbname": "owncloud",
"dbhost": "localhost",
"mail_from_address": "webmaster",
"mail_domain": "fqdn.com",
"has_internet_connection": true,
"memcache.local": "\OC\Memcache\APCu",
"memcache.locking": "\OC\Memcache\Redis",
"redis": {
"host": "localhost",
"port": 6379
"trashbin_retention_obligation": "15, auto",
"updatechecker": true,
"updater.server.url": "https:\/\/updates.owncloud.com\/server\/",
"preview_libreoffice_path": "\/usr\/bin\/libreoffice",
"enable_previews": true,
"overwrite.cli.url": "http:\/\/www.fqdn.com\/owncloud"
[root@cyndane owncloud]#

But that is not the config that gives you trouble because it does not have any log_rotate_size set. Or do I misunderstand something?

Probably a misunderstanding
In my first post I wrote that the log_rotate thing in the config-file didn't work for me. :slight_smile:
Or maybe I misunderstood you?
The script works for me now. The log_rotate command did not. I'm satisfied that it works now. I don't neccesarily need the setting in the config-file.

I would like to find out why the internal log rotate does not work for you and possible fix it.
Because I could not reproduce the log_rotate problem you described in the beginning I would appreciate your help to find out how to reproduce that issue

1 Like

I'll try it again this weekend.
I'll be back!

1 Like