"Not enough free space" error

Nextcloud version (eg, 20.0.5): 22.2.3
Operating system and version (eg, Ubuntu 20.04): Ubuntu 20.04
Apache or nginx version (eg, Apache 2.4.25): nginx 1.18.0
PHP version (eg, 7.4): 7.4

The issue you are facing:
When I try and upload a file using the web interface I get a “Not enough free space” error. However I only get it by dragging and dropping into the parent folder, or by clicking the upload button. If I click and drag the file into a folder within the folder I’m currently viewing, it will upload it no problem.

So the problem isn’t a space issue as I’ve found a workaround that doesn’t produce the error.

I have tried this solution [SOLVED] Not enough free space ?! - #27 by dec0de with no luck.

Is this the first time you’ve seen this error? (Y/N): It has been happening for about a month.

Steps to replicate it:

  1. Try and upload a file

The output of your Nextcloud log in Admin > Logging:

[user_sql] Fatal: Could not execute the query: An exception occurred while executing a query: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'u.admin2' in 'field list'

GET /index.php/settings/admin/logging
from by Bobb at 2021-12-08T23:15:09+00:00

[documentserver_community] Error: Error while applying changes for document 3891541106

GET /cron.php
from at 2021-12-08T23:13:47+00:00

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

$CONFIG = array (
  'instanceid' => 'senstive data removed by Mod/JK',
  'passwordsalt' => 'senstive data removed by Mod/JK',
  'secret' => 'senstive data removed by Mod/JK',
  'trusted_domains' =>
  array (
    0 => 'mail.hostname.org.au',
    1 => '',
    2 => 'hostname.org.au',
  'datadirectory' => '/mnt/data/nextcloud',
  'dbtype' => 'mysql',
  'version' => '',
  'overwrite.cli.url' => 'https://mail.hostname.org.au',
  'dbname' => 'nextcloud_db',
  'dbhost' => 'localhost:3306',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'nextclouddb',
  'dbpassword' => 'password',
  'installed' => true,
  'allow_local_remote_servers' => true,
  'app_install_overwrite' =>
  array (
    0 => 'occweb',
    1 => 'user_sql',
    2 => 'twofactor_webauthn',
  'onlyoffice' =>
  array (
    'verify_peer_off' => true,
  'maintenance' => false,
  'updater.secret' => '$2y$10$5GOS3rcXy6fuqpQe9UxnPOzE3E2aiemkqEzMcCtdsbAnsKXLOYyiO',
  'theme' => '',
  'loglevel' => 2,

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

2021/12/09 10:14:49 [error] 2305218#2305218: *6946 FastCGI sent in stderr: "Unable to open primary script: /var/www/html/nextcloud/index.php/apps/files/ajax/getstoragestats.php (No such file or directory)" while reading response header from upstream, client:
2, server: hostname.org.au, request: "GET /index.php/apps/files/ajax/getstoragestats.php?dir=%2F HTTP/2.0", upstream: "fastcgi://unix:/var/run/php/php7.4-fpm.sock:", host: "hostname.org.au"

So the problem appears to be in that last error message. Does anyone know what would be causing that?

Many thanks,

pls regard your instance as being officially corrupted from now on, though I removed some senstive data from your posting. You might wanna change those in your instance.

Further on… Your problems could come from the fact that your datadirectory might be stored in a different location apart from your installing path. maybe your installing directory/partition is full?

The problem isn’t that the drive is full, either the installation or the data directory. If that were the case then how would I be able to upload exactly the same file, or much bigger files, using alternative methods?

using df:

Filesystem     1M-blocks  Used Available Use% Mounted on
udev                3843     0      3843   0% /dev
tmpfs                776     3       773   1% /run
/dev/sdb2         233202 15892    205397   8% /
tmpfs               3876     0      3876   0% /dev/shm
tmpfs                  5     1         5   1% /run/lock
tmpfs               3876     0      3876   0% /sys/fs/cgroup
/dev/loop0            56    56         0 100% /snap/core18/2246
/dev/loop1             1     1         0 100% /snap/bare/5
/dev/loop3            66    66         0 100% /snap/gtk-common-themes/1515
/dev/md0         1876634  5905   1775334   1% /mnt/data
/dev/sdb1            511     6       506   2% /boot/efi
/dev/loop7           219   219         0 100% /snap/gnome-3-34-1804/72
/dev/loop8            51    51         0 100% /snap/snap-store/547
/dev/loop9            66    66         0 100% /snap/gtk-common-themes/1519
/dev/loop10           33    33         0 100% /snap/snapd/13640
tmpfs                776     1       776   1% /run/user/125
/dev/loop5            56    56         0 100% /snap/core18/2253
/dev/loop4            62    62         0 100% /snap/core20/1242
/dev/loop12          219   219         0 100% /snap/gnome-3-34-1804/77
/dev/loop2            55    55         0 100% /snap/snap-store/558
/dev/loop13          248   248         0 100% /snap/gnome-3-38-2004/87
/dev/loop6            43    43         0 100% /snap/snapd/14066
/dev/loop11           62    62         0 100% /snap/core20/1270
tmpfs                776     1       776   1% /run/user/1001

We can see that sdb1 and sdb2 (the install drive) has plenty of space on it. Likewise the data directory: /dev/md0 is only 1% full.

I’m sorry, but can anyone give me some insight? I think I have the problem located to that error message in my nginx log but I’m not sure how to fix it. As I said, it’s not a problem of either drive actually being full.

I should mention that I can also upload via the Windows app. So again, not a storage issue, a webapp issue.

How big are those files that could not be uploaded?
What is your PHP memory limit and max upload size? You can check it under Settings/System (.../index.php/settings/admin/serverinfo), e.g.:

Just tested drag and drop and even can upload 1,5 GB file with PHP limit 1 GB.
This is because of chunking, you can check during the upload if file piece by piece being uploaded to your user folder in: .../nextcloud/data/USERNAME/uploads/web-file-upload-UUID/, e.g. many 10 MB pieces will be collected in 1 files afterwards:

ls -lahr /var/nextcloud/data/gas/uploads/web-file-upload-c51192307f344f0bf6e0170a0d1f7d9a-1639728856821/
total 1.1G
-rw-r--r-- 1 www-data www-data 160K Dec 17 09:27 985661440.ocTransferId1293616986.part
-rw-r--r-- 1 www-data www-data  10M Dec 17 09:27 975175680
-rw-r--r-- 1 www-data www-data  10M Dec 17 09:26 964689920
-rw-r--r-- 1 www-data www-data  10M Dec 17 09:26 954204160
-rw-r--r-- 1 www-data www-data  10M Dec 17 09:26 943718400
-rw-r--r-- 1 www-data www-data  10M Dec 17 09:16 94371840

You can define a temporary folder in your config-file:

I don’t know where this location is by default but if that is full you can get the same errors.

Thank you for the suggestion. I gave that a go, I tried setting the temp folder to the RAID array with plenty of space. No go.

The size of the file has no effect on it. I try and drag and drop a 4kB file into the parent folder, no go. I drop it directly onto a folder, it works. Same with a 2.8 GB file.

Can you check if that file is present? Or you have some permission settings that prevent the access?

sudo -u www-data cat /var/www/html/nextcloud/index.php/apps/files/ajax/getstoragestats.php

How do you run the cronjob, as www-data user?

That’s one thing that I don’t understand. index.php is not a folder so no, that path does not in fact exist. But why would it go looking as if a file is a folder?

However, in var/www/html/nextcloud/apps/files/ajax/ then yeah, getstoragestates.php does not exist.

It would appear that I am running into similar problems to this one, that never really got satisfactorily solved for some users:

I’ve tried multipl different variants of the fastcgi_split_path_info to no avail.

Oh, I didn’t see that at all. index.php is indeed no folder but the stuff behind it is like an argument that needs to be unwrapped correctly which in your case isn’t done. Did you use the default nginx configuration?

1 Like

Thank you everyone for your help. I’ve figured out the problem, and as suggested by tflidd it did come down to the nginx configuration.

For the benefit of people in the future, it is a conflict in the nginx configurations for NextCloud and iRedmail that I am also running on that box. The problem is in /etc/nginx/templates/php-catchall.tmpl which is created by iRedmail. It has a location ~ .php$ that conflicts with Nextcloud. Comment out that whole section and it all works correctly.