Nextcloud Logs: Where They Live and How to Read Them

Nextcloud logs capture every event your server encounters: from file access to authentication failures to system errors. They live in /var/www/nextcloud/data/nextcloud.log by default, and learning to read them is essential for troubleshooting, security audits, and understanding what is actually happening inside your Nextcloud instance.

You do not need to be a Linux expert to work with Nextcloud logs. This guide walks you through finding them, configuring what gets logged, viewing them in the admin panel, and interpreting the entries to fix real problems.

Where Are Nextcloud Logs Stored?

Nextcloud writes logs to a single file on your server by default. The exact location depends on how you installed Nextcloud. Understanding these paths is your first step to finding and examining your logs when something breaks.

For a standard Linux installation (Apache or Nginx on Ubuntu/Debian), logs go to /var/www/nextcloud/data/nextcloud.log. This is inside your Nextcloud data directory, the same place where user files are stored. The file starts small but grows over time as Nextcloud records events.

If you used the Nextcloud Snap package, logs are typically in /var/snap/nextcloud/common/nextcloud/data/nextcloud.log. Snap isolates the application into a confined environment, so log paths differ from manual installs.

For Docker deployments, the situation is different. Nextcloud inside a container can write logs to /var/www/nextcloud/data/nextcloud.log inside the container, which may be volume-mounted to your host. You can also configure Nextcloud to send logs to stderr or stdout, making them visible via docker logs <container-name>.

Beyond Nextcloud's application logs, you should also know where your web server and PHP logs live, because errors often appear there before Nextcloud even starts. Apache logs are usually in /var/log/apache2/error.log or /var/log/apache2/ssl_error.log. Nginx logs go to /var/log/nginx/error.log. PHP-FPM logs (if you run PHP-FPM) are in /var/log/php-fpm.log or /var/log/php-fpm.9.x.log depending on your PHP version. When Nextcloud will not start at all, your web server or PHP-FPM log is where the actual error appears.

To verify you are looking at the right file, log into your Nextcloud admin panel, go to Settings > Administration > Logging, and trigger a test action (like uploading a small file). Then check your log file and look for the timestamp. If you see a recent entry, you have the right file.

Understanding Nextcloud Log Levels

Nextcloud logs can be verbose or silent depending on the level you set. Log levels control what information gets written, balancing detail against disk space and performance. There are five levels, numbered 0 to 4.

Level 0 is DEBUG: the most verbose. DEBUG logs every action: database queries, file operations, authentication attempts, cache hits, configuration reads. This is invaluable for troubleshooting because you see exactly what Nextcloud is doing, but it fills the disk fast. A busy instance can generate dozens of MB per day at DEBUG level.

Level 1 is INFO: still verbose, but filters out routine operations. INFO logs successful actions like file syncs, user logins, app enablements, scheduled job completions. It is less noisy than DEBUG but still detailed enough for understanding user behavior.

Level 2 is WARN: the default. WARN logs only concerning events: deprecated config options, recoverable errors, permission issues, slow queries. Most of the time nothing is logged at WARN level because Nextcloud handles routine tasks silently. WARN is suitable for production systems where you want warnings without spam.

Level 3 is ERROR: logs only failures. A file could not be synced. A database query crashed. An app refused to load. Errors indicate something went wrong but the instance kept running. ERROR level is useful when you need a clean picture of what broke but do not care about routine operations.

Level 4 is FATAL: only catastrophic failures that shut down the instance. In practice, FATAL entries are rare because Nextcloud typically handles most problems gracefully. You might see FATAL logs if the database is unreachable or disk space is exhausted.

For day-to-day operations, WARN (level 2) is standard. When you are troubleshooting, switch to DEBUG (level 0) to see everything. Do not leave it on DEBUG permanently: the logs will bloat and slow performance.

How to View Logs in the Nextcloud Admin Panel

Nextcloud provides a built-in log viewer in the web interface, which is the easiest way to read your logs if the file is not too large. Navigate to Settings (the gear icon in the top right) > Administration > Logging. You will see a live view of your Nextcloud log entries.

The log viewer shows each entry with a timestamp, severity level (shown as a colored badge), component (the part of Nextcloud that generated the log), and the message. Blue entries are DEBUG. Gray is INFO. Yellow is WARN. Red is ERROR. Purple is FATAL.

You can scroll through the log viewer to see past entries. There is also a search field: type a keyword (like a username, filename, or error code) and the viewer filters to matching entries. This is much faster than grepping the raw log file if you are looking for something specific.

One caveat: the log viewer works best with small to medium log files. If your nextcloud.log file is very large (over 50 MB), the browser may freeze or time out trying to load and display all entries. If this happens, you have reached the limits of the web interface. Switch to command-line tools instead (see the section on reading logs via terminal below).

You can also download the raw log file from the admin interface by clicking a download button if available, or by directly accessing the file via SFTP or SSH.

How to Configure Log Levels in config.php

Log level is set in your Nextcloud configuration file, not in the admin panel. You need direct access to the server (SSH or file manager) to change it. The file is config/config.php, located in your Nextcloud root directory (e.g., /var/www/nextcloud/config/config.php).

Open the file in a text editor. Look for the line starting with 'loglevel'. If it does not exist, you can add it. Set it to a number 0 through 4:

'loglevel' => 2,  // WARN level (default)

To enable DEBUG logging for troubleshooting:

'loglevel' => 0,  // DEBUG level (verbose)

After you change the value, save the file. The change takes effect immediately: new log entries will be written at the new level. You do not need to restart Nextcloud.

You can also configure where logs are written using the 'log_type' setting. The default is 'file', which writes to the log file on disk. Other options include:

'log_type' => 'errorlog' sends logs to the system error log (syslog or journalctl).

'log_type' => 'syslog' sends logs to the system's syslog daemon.

'log_type' => 'systemd' sends logs to systemd journal, viewable via journalctl.

For most setups, 'file' is sufficient. Syslog and systemd are useful if you are aggregating logs from multiple services.

Reading and Interpreting Nextcloud Log Entries

A Nextcloud log entry follows a standard format. Understanding it helps you diagnose issues quickly. Here is an example:

2026-11-05T14:32:18+00:00 Error Core: SQLSTATE[HY000]: General error: 1030 Got error 28 from storage engine (INSERT INTO `oc_activity`...) at /var/www/nextcloud/lib/DB/Connection.php:274

Breaking this down:

2026-11-05T14:32:18+00:00 is the timestamp in ISO 8601 format. This tells you exactly when the error occurred.

Error is the severity level (one of DEBUG, INFO, WARN, ERROR, FATAL).

Core is the component that generated the log. It could also be User Authentication, Files, Calendar, Talk, the name of an app, or another module.

SQLSTATE[HY000]... is the message. In this case, it is a database error: the storage engine ran out of disk space (error 28). The full SQL query is sometimes included (truncated here for brevity).

at /var/www/nextcloud/lib/DB/Connection.php:274 tells you which PHP file and line number triggered the error. This helps developers pinpoint the issue.

Common error codes you will encounter:

SQLSTATE[HY000] with "error 28" means the disk is full. Free up space immediately.

SQLSTATE[HY000] with "error 13" or "Permission denied" means a file or directory has the wrong ownership or permissions. The web server user (www-data, apache, nginx) cannot read or write it.

`Exception: Not a data folder" indicates Nextcloud cannot write to its data directory. Check permissions and disk space.

OAuthException or similar means an authentication provider (LDAP, OIDC, OAuth) is misconfigured or unreachable.

When you see an error, look at the component and message to understand what failed. If it is a database error, check disk space and permissions. If it is an auth error, verify your LDAP or OAuth settings. If it is a file error, check data directory permissions.

For more granular troubleshooting, use command-line tools. The tail command shows the last N lines:

tail -50 /var/www/nextcloud/data/nextcloud.log

To watch new entries in real time as they are written, use:

tail -f /var/www/nextcloud/data/nextcloud.log

To search for entries matching a pattern (e.g., a specific error code or username), use grep:

grep "OAuthException" /var/www/nextcloud/data/nextcloud.log

If you need to count how many errors of each type occurred, pipe to sort and uniq:

grep "Error" /var/www/nextcloud/data/nextcloud.log | cut -d: -f3 | sort | uniq -c | sort -rn

Troubleshooting Common Nextcloud Log Issues

Sometimes the logs themselves are the problem. Here are the most common issues and fixes.

Logging page is blank or frozen. This almost always means the log file is too large to load in the browser. The admin panel is trying to read and display thousands of entries, and the browser runs out of memory. Solution: delete or truncate the log file. Connect via SSH and run:

sudo truncate -s 0 /var/www/nextcloud/data/nextcloud.log

This empties the file without deleting it. Then refresh the Logging page in the admin panel. It should now load instantly because there is nothing in it. As new events occur, entries will appear again.

Alternatively, if truncating does not work, delete the file:

sudo rm /var/www/nextcloud/data/nextcloud.log

Nextcloud will create a new, empty log file on the next event.

Permission denied when trying to read or delete the log file. The log file is owned by the web server user (www-data for Apache on Debian/Ubuntu). Your SSH user may not have permission to edit it. Solution: use sudo to change ownership:

sudo chown www-data:www-data /var/www/nextcloud/data/nextcloud.log
sudo chmod 640 /var/www/nextcloud/data/nextcloud.log

The first command makes www-data the owner and group. The second allows the owner and group to read, and the owner to write, but prevents others from reading the sensitive log file. If you own the SSH user, you can also add yourself to the www-data group or give the file broader permissions, but 640 is more secure.

Logs are not appearing even after an error occurs. Check the log level. If it is set to ERROR (level 3) and you are triggering WARN-level events, they will not be logged. Temporarily set it to DEBUG in config.php, reproduce the issue, and look again. Also verify that Nextcloud actually owns and can write to the log file and its parent directory (/var/www/nextcloud/data).

Web server logs show an error but Nextcloud logs do not. This means the error happened before Nextcloud started. Check your Apache or Nginx error log and your PHP-FPM log. Look for issues like PHP syntax errors in config.php, missing PHP extensions, or database connection failures. These will show up in the web server log first.

Docker: logs are not persisting after container restart. By default, Docker container logs are lost when the container stops. Solution: volume-mount the Nextcloud data directory (which includes the log file) to your host. In your docker-compose.yml or docker run command, add a volume:

volumes:
  -./nextcloud_data:/var/www/nextcloud/data

This maps the container's /var/www/nextcloud/data to a nextcloud_data folder on your host. Logs will persist there. Alternatively, configure Nextcloud to log to Docker stdout using 'log_type' => 'errorlog' so logs appear in docker logs.

Managing Large Nextcloud Log Files

Logs grow over time. A busy instance running at DEBUG level can generate hundreds of MB per month. If left unchecked, logs will consume disk space, slow down backups, and eventually fill the disk and crash Nextcloud.

The first step is to set an appropriate log level for your environment. For production, use WARN (level 2) or ERROR (level 3). This keeps logging minimal. Reserve DEBUG (level 0) for active troubleshooting, then switch back to WARN when done.

Next, implement log rotation. Without rotation, a single log file grows indefinitely. The Linux tool logrotate solves this by periodically compressing old logs and creating a fresh log file. Most Linux distributions have logrotate installed by default.

Create a file /etc/logrotate.d/nextcloud with these contents:

/var/www/nextcloud/data/nextcloud.log {
  size 50M
  rotate 10
  missingok
  notifempty
  compress
  delaycompress
  copytruncate
}

This configuration:

• Rotates the log file when it reaches 50 MB (size 50M)
• Keeps 10 old rotated logs and deletes older ones (rotate 10)
• Ignores missing log files (missingok)
• Does not rotate empty files (notifempty)
• Compresses rotated logs to save space (compress)
• Delays compression by one day to allow processes to finish writing (delaycompress)
• Truncates the original file instead of moving it, which is better for applications writing to the same file path (copytruncate)

Save the file and logrotate will run it automatically (usually daily) via cron. You can test it manually:

sudo logrotate -f /etc/logrotate.d/nextcloud

After rotation runs, you will see files like nextcloud.log.1.gz, nextcloud.log.2.gz, etc., in the data directory. Compressed old logs take up far less space.

Alternatively, if you do not have logrotate or prefer a simpler approach, run a cron job to truncate the log file weekly:

0 2 * * 0 truncate -s 0 /var/www/nextcloud/data/nextcloud.log

This truncates the log file every Sunday at 2 AM.

For large log files that already exist, manually truncate or delete them:

sudo truncate -s 0 /var/www/nextcloud/data/nextcloud.log

Or delete and let Nextcloud create a new one:

sudo rm /var/www/nextcloud/data/nextcloud.log

Why Managed Nextcloud Hosting Simplifies Log Management

Managing Nextcloud logs on your own requires ongoing vigilance. You must monitor file size, configure log levels appropriately, set up rotation, track permissions, and troubleshoot when things go wrong. It is time-consuming and easy to miss.

With Opsily's managed Nextcloud hosting, log management is handled for you. Log rotation is pre-configured. Disk space is monitored automatically. Configuration is optimized for your workload. When errors occur, our team helps you troubleshoot using the logs, not just leaving you to interpret them alone.

Opsily runs the entire log infrastructure: from configuration in config.php through collection, rotation, storage, and retention. You focus on using Nextcloud. We handle the ops.

Ready to eliminate log management headaches? Explore our managed Nextcloud hosting and let us handle the infrastructure while you focus on collaboration.

Frequently Asked Questions

Where is the Nextcloud log file located?

For most Linux installations, the log file is at /var/www/nextcloud/data/nextcloud.log. For Snap packages, it is in /var/snap/nextcloud/common/nextcloud/data/nextcloud.log. For Docker containers, it depends on your volume mounts, but is usually /var/www/nextcloud/data/nextcloud.log inside the container.

What are Nextcloud log levels?

Nextcloud has five log levels: 0 (DEBUG, most verbose), 1 (INFO), 2 (WARN, default), 3 (ERROR), and 4 (FATAL, least verbose). Set the level in config.php using 'loglevel' => 0 (replace 0 with the desired level). Use DEBUG when troubleshooting, WARN or ERROR in production.

How do I view Nextcloud logs in the web interface?

Go to Settings > Administration > Logging to see a live view of log entries. You can scroll through entries, search by keyword, and download the raw log file. This works best for smaller log files; very large files may freeze the browser.

Why is my logging page showing nothing or frozen?

The log file is too large for the browser to load. Truncate it with sudo truncate -s 0 /var/www/nextcloud/data/nextcloud.log and refresh the page. Then implement log rotation to prevent the file from growing too large again.

How do I change the Nextcloud log level?

Edit /var/www/nextcloud/config/config.php and set 'loglevel' => 0 (where 0-4 is the desired level). Save the file. The change takes effect immediately without restarting Nextcloud.

How do I fix permission errors on nextcloud.log?

Run sudo chown www-data:www-data /var/www/nextcloud/data/nextcloud.log and sudo chmod 640 /var/www/nextcloud/data/nextcloud.log to ensure the web server user owns the file and can write to it.

What is the difference between Nextcloud logs and web server logs?

Nextcloud application logs (in nextcloud.log) capture events that occurred after Nextcloud started. Web server logs (Apache error.log, Nginx error.log) capture errors that happen before Nextcloud loads, such as PHP syntax errors or database connection failures. Check web server logs first if Nextcloud will not start at all.

How do I set up automatic log rotation?

Create /etc/logrotate.d/nextcloud with a rotation policy (size, compress, retain count) and logrotate runs it automatically. Alternatively, use cron to run truncate -s 0 on the log file weekly or monthly.

The Bottom Line

Nextcloud logs are your window into what is happening inside your instance. They tell you when files sync, when errors occur, and when something needs your attention. Finding them (/var/www/nextcloud/data/nextcloud.log), configuring the right log level in config.php, and reading entries through the admin panel or command-line tools are essential skills.

The most common issues--frozen logging pages, permission errors, disk bloat--are easily prevented with log rotation and careful permission management. Start with WARN level in production, switch to DEBUG when troubleshooting, then rotate and archive old logs.

If log management becomes overwhelming, consider letting Opsily's managed Nextcloud hosting handle it. Explore our managed hosting plans to see how we simplify the entire deployment and operational side of Nextcloud.