There’s no free space, and it’s unclear what’s occupying it

ℹ️ Support
, , ,
1
Support intro

The Basic

  • Nextcloud Server version (e.g., 29.x.x):
  • Operating system and version (e.g., Ubuntu 24.04):
    • Debian GNU/Linux 13 (trixie)
  • Web server and version (e.g, Apache 2.4.25):
    • nginx/1.26.3
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • there is no proxy
  • PHP version (e.g, 8.3):
    • 8.4.23
  • Is this the first time you’ve seen this error? (Yes / No):
    • Yes
  • When did this problem seem to first start?
    • 20.08.2026
  • 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:

Hello everyone. I’m facing a problem where the /dev/mapper/NextCloud–vg-root partition is 100% full. I don’t understand why the quota is set to 28GB and how to fix the situation. There are disks in mnt, and the disk containing the data/nextcloud folder is also mounted there. I’m attaching screenshots. I’d be grateful for any help.

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

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.

Ошибка
no app in context
InsufficientStorage
Insufficient space in /Photos/Сочи 2024/IMG_20240929_223601.jpg

20 авг. 2026 г., 23:52:14

Ошибка
webdav
InsufficientStorage
Insufficient space in /Photos/Сочи 2024/IMG_20240929_223601.jpg

20 авг. 2026 г., 23:52:14

Предупреждение
no app in context
Temporary directory /mnt/sdc1/data/tmp is not present or writable

20 авг. 2026 г., 23:52:14

Предупреждение
no app in context
Temporary directory /mnt/sdc1/data/tmp is not present or writable

20 авг. 2026 г., 23:52:11

Ошибка
webdav
EntityTooLarge
Недостаточно места

20 авг. 2026 г., 23:52:11

Ошибка
no app in context
NotEnoughSpaceException
Exception thrown: OCP\Files\NotEnoughSpaceException

20 авг. 2026 г., 23:52:11

Предупреждение
no app in context
Temporary directory /mnt/sdc1/data/tmp is not present or writable

20 авг. 2026 г., 23:52:11

Предупреждение
no app in context
Temporary directory /mnt/sdc1/data/tmp is not present or writable

20 авг. 2026 г., 23:52:11

Предупреждение
no app in context
Temporary directory /mnt/sdc1/data/tmp is not present or writable

20 авг. 2026 г., 23:52:11

Предупреждение
no app in context
Temporary directory /mnt/sdc1/data/tmp is not present or writable

20 авг. 2026 г., 23:52:06

Ошибка
webdav
EntityTooLarge
Недостаточно места

20 авг. 2026 г., 23:52:06

Ошибка
no app in context
NotEnoughSpaceException
Exception thrown: OCP\Files\NotEnoughSpaceException

20 авг. 2026 г., 23:52:06

Web Browser

If the problem is related to the Web interface, open your browser inspector Console and Network tabs while refreshing (reloading) and reproducing the problem. Provide any relevant output/errors here that appear.

PASTE

Web server / Reverse Proxy

The output of your Apache/nginx/system log in /var/log/____:

2026/08/21 02:43:07 [error] 1025#1025: *118 FastCGI sent in stderr: "PHP message: PHP Notice:  fwrite(): Write of 579 bytes failed with errno=28 No space left on device in /var/www/nextcloud/lib/private/Log/File.php on line 56" while reading response header from upstream, client: 10.100.1.1, server: hek08vgkkc3.sn.mynetname.net, request: "GET /ocs/v2.php/apps/updatenotification/api/v1/applist/34.0.3.2 HTTP/2.0", upstream: "fastcgi://unix:/run/php/php8.4-fpm.sock:", host:

3
3775×237 8.15 KB

2
2483×258 5.29 KB

1
1768×171 3.8 KB

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!):

<?php

/*
 * WARNING
 *
 * This file gets modified by automatic processes and all lines that are not
 * active code (ie. comments) are lost during that process.
 *
 * If you want to document things with comments or use constants add your settings
 * in a '<NAME>.config.php' file which will be included and rendered into this file.
 *
 * Example:
 *   <?php
 *   $CONFIG = [];
 *
 * See also: https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/config_sample_php_parameters.html#multiple-merged-configuration-files
 */
$CONFIG = array (
  'instanceid' => '',
  'passwordsalt' => '',
  'secret' => '',
  'trusted_domains' => 
  array (
    0 => '10.100.1.234',
    1 => '',
  ),
  'datadirectory' => '/mnt/sdc1/data',
  'tempdirectory' => '/mnt/sdc1/data/tmp',
  'dbtype' => 'pgsql',
  'version' => '34.0.2.1',
  'overwrite.cli.url' => 'https://10.100.1.234',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'nextcloud',
  'dbpassword' => '',
  'installed' => true,
  'maintenance' => false,
  'config_preset' => 1,
  'maintenance_window_start' => 2,
  'memcache.local' => '\\OC\\Memcache\\Memcached',
  'memcache.distributed' => '\\OC\\Memcache\\Memcached',
  'memcache.locking' => '\\OC\\Memcache\\Memcached',
  'redis' => 
  array (
    'host' => 'localhost',
    'port' => 6379,
  ),
  'memcached_servers' => 
  array (
    0 => 
    array (
      0 => 'localhost',
      1 => 11211,
    ),
  ),
  'default_phone_region' => 'RU',
  'app_install_overwrite' => 
  array (
  ),
  'updater.secret' => '',
);
2

hello,

I’d first check what is actually using the disk space instead of deleting files randomly. Usually, things like old backups, log files, temporary files, cache, or unused applications can take up more space than expected.

If you’re using a VPS, you can check disk usage from the server and identify which folders are taking the most space. Once you find the cause, you can safely remove unnecessary files or move backups to another location.

I’d also recommend setting up regular cleanup and monitoring, so the disk doesn’t suddenly become full again.

3

Thank you for the response. I have a local server at home. For some reason, everything in /mnt/ is added to the mount point /. The root partition itself doesn’t have that much data. Here’s my question: why does everything in /mnt/ affect the partition size /?

4

The root filesystem is full, not necessarily the Nextcloud data volume

From the information provided, the immediate failure is caused by the filesystem containing / reaching 100% usage.

The most important error is:

fwrite(): Write of 579 bytes failed with errno=28 No space left on device

This is an operating-system-level ENOSPC error. Nextcloud subsequently reports NotEnoughSpaceException, InsufficientStorage, and EntityTooLarge because it cannot complete the required filesystem writes.

Your configuration shows that the Nextcloud data directory is on a separate filesystem:

'datadirectory' => '/mnt/sdc1/data',

while the affected filesystem is:

/dev/mapper/NextCloud-vg-root

Therefore, the first step is to determine what is consuming space on the root filesystem rather than deleting data from the Nextcloud data directory.

1. Check all filesystem usage

Please run:

df -hT
df -ih
findmnt /mnt/sdc1
df -h /mnt/sdc1

This confirms whether /mnt/sdc1 is actually mounted and whether the 28 GB root filesystem is the filesystem that is exhausted.

2. Find what is consuming the root filesystem

Use du with -x so that the separate /mnt/sdc1 filesystem is not included:

sudo du -xhd1 / | sort -h
sudo du -xhd1 /var | sort -h
sudo du -xhd1 /var/log | sort -h

Pay particular attention to:

  • /var/log

  • /var/lib

  • /var/cache

  • /tmp

  • PHP-FPM logs

  • Nginx logs

  • systemd journal

  • database storage

Do not remove files from /mnt/sdc1/data simply because Nextcloud reports insufficient storage. First establish which filesystem is full.

3. Check for deleted files still consuming disk space

A common cause of a filesystem remaining full after log rotation or file deletion is a process keeping a deleted file open.

Run:

sudo lsof +L1

If large deleted files are shown, identify the associated service/process before restarting it. Do not blindly delete files reported by lsof.

4. Verify the Nextcloud temporary directory

Your configuration contains:

'tempdirectory' => '/mnt/sdc1/data/tmp',

However, Nextcloud reports:

Temporary directory /mnt/sdc1/data/tmp is not present or writable

Verify both its existence and the mount:

findmnt /mnt/sdc1
sudo ls -ld /mnt/sdc1/data/tmp
sudo -u www-data test -w /mnt/sdc1/data/tmp && echo "Writable" || echo "Not writable"

If the directory is missing and /mnt/sdc1 is confirmed to be correctly mounted, it can be recreated with the appropriate ownership:

sudo mkdir -p /mnt/sdc1/data/tmp
sudo chown www-data:www-data /mnt/sdc1/data/tmp
sudo chmod 750 /mnt/sdc1/data/tmp

If the directory exists but is not writable, correct its ownership/permissions according to the permissions used by the rest of the Nextcloud data directory.

5. Check the mount before making permission changes

This is particularly important.

If /mnt/sdc1 is not mounted, /mnt/sdc1/data may simply be a directory on the root filesystem. In that situation, creating files there could make the root filesystem problem worse and could also hide the underlying mount issue.

Therefore, verify:

findmnt /mnt/sdc1
mountpoint /mnt/sdc1
df -h /mnt/sdc1

before making changes under /mnt/sdc1.

6. Check the database and system logs

Because the root filesystem is only 28 GB, also check whether logs or database files are consuming unexpected space:

sudo journalctl --disk-usage
sudo du -sh /var/lib/postgresql
sudo du -sh /var/log/*

Do not manually delete PostgreSQL files from /var/lib/postgresql. If the database is consuming significant space, investigate it using PostgreSQL’s own maintenance and retention mechanisms.

7. Free or increase root filesystem capacity

Once the source of the usage has been identified, safely reclaim space or extend the root logical volume/filesystem if the underlying storage has available capacity.

For an LVM-based installation, first inspect the layout:

sudo pvs
sudo vgs
sudo lvs
lsblk -f

Do not run lvextend or filesystem resize commands until the LVM layout and available free space have been confirmed.

Conclusion

The evidence currently points to two separate issues:

  1. /dev/mapper/NextCloud-vg-root is 100% full, causing the errno=28 No space left on device failures.

  2. Nextcloud’s configured temporary directory /mnt/sdc1/data/tmp is reported as missing or not writable.

The 28 GB size of the root filesystem should not be interpreted as a Nextcloud storage quota. Since the actual Nextcloud data directory is configured under /mnt/sdc1/data, the root filesystem and data filesystem should be investigated independently.

I would recommend posting the output of the following commands if further analysis is required:

df -hT
df -ih
findmnt /mnt/sdc1
sudo du -xhd1 / | sort -h
sudo du -xhd1 /var | sort -h
sudo lsof +L1
sudo journalctl --disk-usage

With those results, it should be possible to identify exactly what is consuming the root filesystem and determine the safest corrective action without risking the Nextcloud data.

Regards,

Ryan P.

Cloud & DevOps Engineer

AccuWeb.cloud

5

And:

LVM can be confusing (even if you use it daily).

You appear to have one VG (Volume Group) provisioned: Nextcloud--vg

And several LVs (Logical Volumes) located on that VG:

  • root
  • var
  • swap_1
  • srv

Your LVs are mounted as follows from the operating system perspective:

  • root → /
  • var → /var
  • swap_1 → (swap so not a traditional mount point)
  • srv → /srv

I don’t see anything mounted as /mnt. So /mnt is just an arbitrary folder that exists on the parent mount point (which is /).

That mount point is ultimately located on /dev/mapper/NextCloud--vg-root.

So anything pointed at /mnt/[...] ends up on your root LV mounted /.

6

Thank you all for your responses. I figured out the situation: it turned out that a folder was actually created in /mnt/, even though the disk was mounted there. As a result, I expanded the partition, moved the data to another disk, and mounted it via fstab. I also deleted the directories in /mnt/ or renamed them. I also thought the data was lost, but after scanning the RAID for file recovery, I didn’t find any there. That’s when I realized that everything in /mnt/ was treated as a folder, not as a disk.