Moving Nextcloud log file to /var/log/apache2 fails

Support intro

Sorry to hear you’re facing problems. :slightly_frowning_face:

The community help forum (help.nextcloud.com) is for home and non-enterprise users. Support is provided by other community members on a best effort / “as available” basis. All of those responding are volunteering their time to help you.

If you’re using Nextcloud in a business/critical setting, paid and SLA-based support services can be accessed via portal.nextcloud.com where Nextcloud engineers can help ensure your business keeps running smoothly.

Getting help

In order to help you as efficiently (and quickly!) as possible, please fill in as much of the below requested information as you can.

Before clicking submit: Please check if your query is already addressed via the following resources:

(Utilizing these existing resources is typically faster. It also helps reduce the load on our generous volunteers while elevating the signal to noise ratio of the forums otherwise arising from the same queries being posted repeatedly).

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can. :heart:

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • 31.0.5
  • Operating system and version (e.g., Ubuntu 24.04):
    • Debian 12
  • Web server and version (e.g, Apache 2.4.25):
    • Apache/2.4.62 (Debian)
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • no
  • PHP version (e.g, 8.3):
    • 8.2
  • Is this the first time you’ve seen this error? (Yes / No):
    • Yes
  • When did this problem seem to first start?
    • replace me
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • Archive
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • No

Summary of the issue you are facing:

I want to move the log file ‘nextcloud.log’ from ‘data’ to ‘/var/log/apache/nextcloud.log’. However, the entries I made in ‘config.php’ do not result in logging to ‘/var/log/apache2/nextcloud.log’ in the desired format. #data/nextcloud.log’ is still used in the old format.

Steps to replicate it (hint: details matter!):

  1. touch /var/log/apache2/nextcloud.log
  2. touch /var/log/apache2/nextcloud-fail.log
  3. chown www-data:www-data /var/log/apache2/nextcloud.log
  4. chown www-data:www-data /var/log/apache2/nextcloud-fail.log
  5. chmod 640 /var/log/apache2/nextcloud.log
  6. chmod 640 /var/log/apache2/nextcloud-fail.log
  7. rm /srv/www/nextcloud/data/nextcloud.log
  8. systemctl restart apache2

Log entries

Nextcloud

Please provide the log entries from your Nextcloud log that are generated during the time of problem (via the Copy raw option from Administration settings->Logging screen or from your nextcloud.log located in your data directory). Feel free to use a pastebin/gist service if necessary.

 # ls -l /var/log/apache2/nextcloud*.log
-rw-r----- 1 www-data www-data 0 22. Mai 09:51 /var/log/apache2/nextcloud-fail.log
-rw-r----- 1 www-data www-data 0 21. Mai 15:57 /var/log/apache2/nextcloud.log

Configuration

Nextcloud

The output of occ config:list system or similar is best, but, if not possible, the contents of your config.php file from /path/to/nextcloud is fine (make sure to remove any identifiable information!):

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "cloud.germany.com"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "31.0.5.1",
        "overwrite.cli.url": "https:\/\/cloud.germany.com",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "mail_smtpmode": "smtp",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_sendmailmode": "smtp",
        "mail_smtpport": "587",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauth": 1,
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "log_type": "file",
        "logfile": "\/var\/log\/apache2\/nextcloud.log",
        "loglevel": 1,
        "logdateformat": "F d, Y H:i:s",
        "maintenance": false
    }
}

Apps

The output of occ app:list (if possible).

Enabled:

  • activity: 4.0.0
  • app_api: 5.0.2
  • appointments: 2.4.4
  • bruteforcesettings: 4.0.0
  • calendar: 5.2.4
  • circles: 31.0.0
  • cloud_federation_api: 1.14.0
  • comments: 1.21.0
  • contacts: 7.1.1
  • contactsinteraction: 1.12.0
  • dashboard: 7.11.0
  • dav: 1.33.0
  • deck: 1.15.1
  • federatedfilesharing: 1.21.0
  • federation: 1.21.0
  • files: 2.3.1
  • files_downloadlimit: 4.0.0
  • files_pdfviewer: 4.0.0
  • files_reminders: 1.4.0
  • files_sharing: 1.23.1
  • files_trashbin: 1.21.0
  • files_versions: 1.24.0
  • firstrunwizard: 4.0.0
  • logcleaner: 1.1.4
  • lookup_server_connector: 1.19.0
  • mail: 5.1.0
  • music: 2.1.4
  • nextcloud_announcements: 3.0.0
  • notes: 4.12.0
  • notifications: 4.0.0
  • oauth2: 1.19.1
  • officeonline: 3.1.0
  • password_policy: 3.0.0
  • photos: 4.0.0-dev.1
  • privacy: 3.0.0
  • profile: 1.0.0
  • provisioning_api: 1.21.0
  • recommendations: 4.0.0
  • related_resources: 2.0.0
  • serverinfo: 3.0.0
  • settings: 1.14.0
  • sharebymail: 1.21.0
  • spreed: 21.0.4
  • support: 3.0.0
  • survey_client: 3.0.0
  • systemtags: 1.21.1
  • text: 5.0.0
  • theming: 2.6.1
  • twofactor_backupcodes: 1.20.0
  • updatenotification: 1.21.0
  • user_status: 1.11.0
  • viewer: 4.0.0
  • webhook_listeners: 1.2.0
  • workflowengine: 2.13.0
    Disabled:
  • admin_audit: 1.21.0
  • encryption: 2.19.0
  • files_external: 1.23.0
  • logreader: 4.0.0 (installed 4.0.0)
  • suspicious_login: 9.0.1
  • twofactor_nextcloud_notification: 5.0.0
  • twofactor_totp: 13.0.0-dev.0
  • user_ldap: 1.22.0
  • weather_status: 1.11.0 (installed 1.11.0)

My specific question is how I can get the logging in the desired format to ‘/var/log/apache2/’ so that Logrotate includes the log files and “data” isn’t unnecessarily “abused.” I don’t use web space with an internet host, but can configure everything myself as root.

Best regards and thank you!

Mpenzi

Just to clarify:

Logging to /var/log/apache2 works but the date is still in the old format?

Or does both not work, i.e, it stil uses …/data/nextcloud.log and the date is still in the old format?

Or maybe it would be better to put the Nextcloud logs into a separate folder, instead of using /var/log/apache2.

Here my notes on how I configured it, including the audit.log:

mkdir /var/log/nextcloud
chown -R www-data:www-data /var/log/nextcloud
occ config:system:set logfile --value="/var/log/nextcloud/nextcloud.log"
occ app:enable admin_audit
occ config:app:set admin_audit logfile --value="/var/log/nextcloud/audit.log"
nextcloud_occ config:system:set log.condition apps 0 --value admin_audit
cat <<EOF >>/etc/logrotate.d/nextcloud
/var/log/nextcloud/*.log {
size 100M
missingok
rotate 30
compress
delaycompress
notifempty
sharedscripts
}
EOF
occ config:system:set log_rotate_size --value="0"

I never fiddled around with the logdateformat parameter, but that seems like a separate issue. If I had to guess, I’d say it didn’t change because you configured the value shown in the docs, which is usually the default value.

1 Like

Your suggestions aren’t working. I would have appreciated knowing what these three commands are supposed to do.

su -s /bin/bash www-data -c 'php /srv/www/nextcloud/occ app:enable admin_audit'
su -s /bin/bash www-data -c 'php /srv/www/nextcloud/occ app:set admin_audit logfile --value="/var/log/apache2/nextcloud.log'
su -s /bin/bash www-data -c 'php /srv/www/nextcloud/occ app:set admin_audit logfile --value="/var/log/apache2/nextcloud.log"'

And I think it’s sufficient to store the log file with a unique name under “/var/log/apache2.” This is unambiguous and saves additional configuration of logrotate.

Sorry, not sure why that’s the case. I’ve configured it exactly like this on my instance, and it’s working for me (except for the part with the logdateformat. I’ve never tried that, as I mentioned).

They enable the admin audit log, which gives you additional information about various events. But that’s entierly optional.

Yeah, maybe, I’ve never tried it.

However, what I seem to remember (though I’m not a 100% sure) is that the directory Nextcloud is supposed to write logs to must also be owned by www-data, not just the file itself. If that’s the case, it would explain why your approach isn’t working, and using a dedicated directory with the correct ownership might solve the issue.

Well, that’s funny. That’s exactly what happens with /var/log/apache2 on Debian/Ubuntu; otherwise, all the Apache logs would also remain empty.

I can delete data/nextcloud.log, and after every systemctl reload/restart, apache2 is back and writing. The problem lies somewhere other than the permissions in the existing log directory.

Well, at least by default, /var/log/apache2 isn’t owned by www-data on Debian.

ls -al /var/log/apache2
total 880
drwxr-x---  2 root adm    4096 May 26 16:27 .
drwxr-xr-x 12 root root   4096 May 26 16:28 ..
-rw-r-----  1 root adm  772571 May 27 10:53 access.log
-rw-r-----  1 root adm   22745 May 27 09:05 error.log
-rw-r-----  1 root adm   79032 May 27 11:24 other_vhosts_access.log

adm: Group adm is used for system monitoring tasks. Members of this group can read many log files in /var/log, and can use xconsole. Historically, /var/log was /usr/adm (and later /var/adm), thus the name of the group.

None of this solves the problem.

Then you have to try narrowing down the problem:

First, remove the logdateformat parameter from config.php, and then create a new folder under /var/log/ with www-data ownership.

mkdir -p /var/log/nextcloud
chown -R www-data:www-data /var/log/nextcloud

Next, update the path in config.php

occ config:system:set logfile --value="/var/log/nextcloud/nextcloud.log"

…and trigger a log event. Nextcloud should then automatically create a new log file at the new location.

Once that works, re-add the logdateformat parameter and start experimenting with it until your log events are formatted the way you want. Only after that I would try setting up logrotate.

As for using /var/log/apache2 as the location for the Nextcloud log, I’m not sure if that’s possible without adjusting the defult ownership, which carries the risk of breaking Apache logging. So unless you know exactly what you’re doing, I wouldn’t recommend it.

But maybe others have some more ideas.

1 Like

Your idea is harder than logs need to be, and possibly messy. Go the extra quarter mile and use logrotate the way @bb77 explained, or the way @ernolf explains here.

Either way, if you are using Nextcloud’s optional audit logging you can append it to nextcloud.log for easier reading.

2 Likes

Btw, if you look in the file /etc/logrotate.d/apache2, you’ll see that here are some Apache specific parameters like e.g.:

create 640 root adm

This applies to all .log files in that directory, including the Nextcloud log if it is placed there. It tells logrotate to create files with permissions 640 and ownership root:adm after each rotation, and then Nextcloud won’t have access anymore.

However, you should be able to apply the same configuration as for Apache to a dedicated folder, such as /var/log/nextcloud, simply by creating a file called /etc/logrotate.d/nextcloud and copying over the relevant parts of the Apache logrotate configuration.

Example:

/var/log/nextcloud/*.log {
        daily
        missingok
        rotate 14
        compress
        delaycompress
        notifempty
        create 640 www-data www-data
}

And don’t forget to set log_rotate_size to 0 in config.php so that Nextcloud doesn’t attempt its own rotation:

occ config:system:set log_rotate_size --value="0"