Erroneous 'Not enough disk space' error when uploading via web interface

Nextcloud version (eg, 12.0.2):
Operating system and version (eg, Ubuntu 17.04):
CentOS 7 64-bit
Apache or nginx version (eg, Apache 2.4.25): nginx-1.12.2
PHP version (eg, 7.1): 7.2

The issue you are facing:
When I try to upload files via the web interface, the upload fails with the error ‘Not enough free space’. This error is a misdiagnosis; the data directory is mounted on a dedicated 2TB drive with only ~50GB used. Even small files (20 bytes) fail. Uploading via the desktop client works fine. Research lead me to some past posts here but none seemed to end in a resolution.

Is this the first time you’ve seen this error? (Y/N):
Steps to replicate it:

  1. Install Nextcloud under CentOS/ MariaDB / PHP 7.2
  2. Attempt to upload a file of any size via the web interface (files -> + -> upload file).

The output of your Nextcloud log in Admin > Logging:

No server logs

Everything is working fine

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

$CONFIG = array (
  'instanceid' => '***REDACTED***',
  'passwordsalt' => '***REDACTED***',
  'secret' => '***REDACTED***',
  'trusted_domains' => 
  array (
    0 => '',
'apps_paths' => array(
		'path'=> '/home/nextcloud/nextcloud/apps',
		'url' => '/apps',
		'writable' => true,
'simpleSignUpLink.shown' => false,
 'datadirectory' => '/home/nextcloud/data',
  'version' => '',
  'dbtype' => 'mysql',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost:3306',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'nextcloud',
  'dbpassword' => '***REDACTED***',
  'installed' => true,
  'mail_smtpmode' => 'smtp',
  'mail_sendmailmode' => 'smtp',
  'mail_from_address' => 'cloud',
  'mail_domain' => '',
  'mail_smtphost' => '',
  'mail_smtpport' => '587',
  'mail_smtpsecure' => 'tls',
  'mail_smtpauthtype' => 'PLAIN',
  'mail_smtpauth' => 1,
  'mail_smtpname' => '',
  'mail_smtppassword' => '***REDACTED***',
'memcache.local' => '\OC\Memcache\Redis',
'redis' => [
	'host' => 'localhost', // can also be a unix domain socket: '/tmp/redis.sock'
	'port' => 6379,
	'timeout' => 0.0,
	'password' => '***REDACTED***', // Optional, if not defined no password will be used.
  'maintenance' => false,

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

***No events generated in /var/log/nginx/error.log***

Some other details you might find useful:
Definitely not a capacity issue:

[root@caturria ~]# df -h /home/nextcloud/data
Filesystem      Size  Used Avail Use% Mounted on
/dev/vdb1       1.8T   62G  1.7T   4% /home/nextcloud/data
[root@caturria ~]# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       394G   75G  300G  20% /
[root@caturria ~]# 

I’ve also included the Nginx server block configuration:

listen 80;
        add_header Strict-Transport-Security "max-age=15552000; includeSubDomains;" always;
        add_header Cache-Control "public, max-age=15778463";
        add_header X-Content-Type-Options nosniff;
        add_header X-XSS-Protection "1; mode=block";
        add_header X-Robots-Tag none;
        add_header X-Download-Options noopen;
        add_header X-Permitted-Cross-Domain-Policies none;
        add_header Referrer-Policy no-referrer;
return 301 https://$host$uri;

listen 443 ssl http2;
ssl_certificate /etc/letsencrypt/live/;
ssl_certificate_key /etc/letsencrypt/live/;
ssl_protocols TLSv1.2;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 10m;
ssl_prefer_server_ciphers on;
        add_header Strict-Transport-Security "max-age=15552000; includeSubDomains;" always;
     add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Robots-Tag none;
    add_header X-Download-Options noopen;
    add_header X-Permitted-Cross-Domain-Policies none;
    add_header Referrer-Policy no-referrer;
add_header X-Frame-Options SAMEORIGIN;
root /home/nextcloud/nextcloud;
    fastcgi_hide_header X-Powered-By;
    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
    rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;
    rewrite ^/.well-known/webfinger /public.php?service=webfinger last;
    location = /.well-known/carddav {
      return 301 $scheme://$host:$server_port/remote.php/dav;
    location = /.well-known/caldav {
      return 301 $scheme://$host:$server_port/remote.php/dav;
    client_max_body_size 512M;
    fastcgi_buffers 64 4K;
    gzip on;
    gzip_vary on;
    gzip_comp_level 4;
    gzip_min_length 256;
    gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
    gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/ application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;
    location / {
        rewrite ^ /index.php$request_uri;
    location ~ ^\/(?:build|tests|config|lib|3rdparty|templates|data)\/ {
        deny all;
    location ~ ^\/(?:\.|autotest|occ|issue|indie|db_|console) {
        deny all;
location ~ ^(.+\.php)(.*)$ {
fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_pass unix:/var/run/php-fpm-cloud.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $request_filename;
include fastcgi_params;
        fastcgi_param HTTPS on;
        # Avoid sending the security headers twice
        fastcgi_param modHeadersAvailable true;
        # Enable pretty urls
        fastcgi_param front_controller_active true;
        fastcgi_intercept_errors on;
        fastcgi_request_buffering off;
    location ~ ^\/(?:updater|oc[ms]-provider)(?:$|\/) {
        try_files $uri/ =404;
        index index.php;

    # Adding the cache control header for js, css and map files
    # Make sure it is BELOW the PHP block
    location ~ \.(?:css|js|woff2?|svg|gif|map)$ {
        try_files $uri /index.php$request_uri;

        # Optional: Don't log access to assets
        access_log off;

    location ~ \.(?:png|html|ttf|ico|jpg|jpeg|bcmap)$ {
        try_files $uri /index.php$request_uri;
        # Optional: Don't log access to other assets
        access_log off;

Lastly, the php-fpm configuration:

user = nextcloud
group = nextcloud
listen = /var/run/php-fpm-cloud.sock
listen.owner = nginx = nginx
php_admin_value[session.save_handler] = files
php_admin_value[session.save_path] = /home/nextcloud/.session
php_admin_value[disable_functions] = 
php_admin_value[memory_limit] = 512M
php_admin_value[opcache.interned_strings_buffer] = 8
php_admin_value[opcache.max_accelerated_files] = 10000
php_admin_value[opcache.memory_consumption] = 128
php_admin_flag[opcache.save_comments] = 1
php_admin_flag[opcache.revalidate_freq] = 1
php_admin_flag[allow_url_fopen] = off
pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
chdir = /home/nextcloud/nextcloud
clear_env = no

I’ve been attempting to troubleshoot this and researching for the last two days to no avail. Thank you very much for your time.


The quota of the user is not reached (personal page)?

There is no quota on the linux system?

No and no. There are no quotas configured at all. I can upload data freely via the desktop client, just not the web interface. It has to be misreporting the error as being related to capacity when it’s really something else. From what I can find on Google, this issue has been around since at least Nextcloud 14.X.

Please see this system report:
Password: A5n+Q9BabWf3+0QRMK4/
This affects Owncloud too. Nobody’s gotten a working solution over there either.

Do you have other disks mounted? Could be a php or webserver tmp folder that is full.
We had a few cases where SELinux created a few strange effects, perhaps check that logfile.

Shouldn’t this be with a capital G?

There are only two disks mounted, one is / and the other is /home/nextcloud/data. The disk which is mounted at / is 20 percent used while the Nextcloud disk is 4 percent used.
Selinux is turned off actually. I’m just using ACLs to manage access rights. Nginx is granted execute only on /home and /home/nextcloud, while read and execute permissions are granted on /home/nextcloud/nextcloud (as this is where the actual web files are). Nginx has no access to the data folder, but PHP does as its running via a pool as the Nextcloud user.
So far I’ve managed to track the problem to this snippet of javascript in apps/files/js/file-upload.js:

					// check free space
					freeSpace = $('#free_space').val();
					if (freeSpace >= 0 && selection.totalBytes > freeSpace) {
						data.textStatus = 'notenoughspace';
						data.errorThrown = t('files',
							'Not enough free space, you are uploading {size1} but only {size2} is left', {
							'size1': humanFileSize(selection.totalBytes),
							'size2': humanFileSize($('#free_space').val())

At this point in the code, the freeSpace variable is an empty string. I guess I have to poke around some more to try and find out why.