NGINX reverse proxy upload error "Not enough free space"

Nextcloud version: 15.0.4 (Snap Install)
Operating system and version (eg, Ubuntu 17.04): Ubuntu Server 18.10

Nextcloud is running fine from a snap install. I am trying to set it up behind an NGINX reverse proxy.

The issue you are facing:
Trying to upload anything will immediately give the error: Capture

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

Steps to replicate it:

  1. Try to upload any file

Nextcloud log does not show anything related to uploading

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

<?php
$CONFIG = array (
'apps_paths' => 
array (
0 => 
array (
'path' => '/snap/nextcloud/current/htdocs/apps',
'url' => '/apps',
'writable' => false,
),
1 => 
array (
'path' => '/var/snap/nextcloud/current/nextcloud/extra-apps',
'url' => '/extra-apps',
'writable' => true,
),
),
'supportedDatabases' => 
array (
0 => 'mysql',
),
'memcache.locking' => '\\OC\\Memcache\\Redis',
'memcache.local' => '\\OC\\Memcache\\Redis',
'redis' => 
array (
'host' => '/tmp/sockets/redis.sock',
'port' => 0,
),
'instanceid' => '####',
'passwordsalt' => '####',
'secret' => '####',
'trusted_domains' => 
array (
0 => '192.168.1.97',
),
'datadirectory' => '/var/snap/nextcloud/common/nextcloud/data',
'dbtype' => 'mysql',
'version' => '15.0.4.0',
'dbname' => 'nextcloud',
'dbhost' => 'localhost:/tmp/sockets/mysql.sock',
'dbport' => '',
'dbtableprefix' => 'oc_',
'mysql.utf8mb4' => true,
'dbuser' => 'nextcloud',
'dbpassword' => '####',
'installed' => true,
'maintenance' => false,
'overwritehost' => '####',
'overwriteprotocol' => 'https',
'overwritewebroot' => '/nextcloud',
'overwrite.cli.url' => 'https://####/nextcloud',
'htaccess.RewriteBase' => '/nextcloud',
);

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

No errors while trying to upload, in both NGINX reverse proxy and Apache snap logs…

Uploading works as intended without the reverse proxy.

Any help is greatly appreciated

1 Like

I have the same issue, my nextcloud installation is exposed bheind a reverse proxy, both (webserver and proxy) are Centos 7 with nginx and i use php 7.3 (from remi repository).
If I upload file from shared links, webdav or mobile app everything works well, but from the webui I recive the message “Not enough space”.
I don’t have any error in the nginix, nextcloud or php log, and I have applied all tips suggested in the summary page (DB, xforwarder, cache, etc…)

Bump? Still not having any luck

Hello,

I’ve the same behavious with an install using Nginx and netxcloud 15.0.5.

Same exactly siuation here (I Can upload files using desktop client but from web interface i,m getting the space error), tried with custom server configuration block and the official guide proposed config. None works. Also checked persissions, quotas etc., space in volume… everything looks to be ok.

My config:
Debian 9
Nginx 1.10.3
PHP 7.0.33
NextCloud 15.0.7

Struggled with this :frowning:

me too. anyone can help this issue?

I had the same problem and it took me way too long to figure it out. In my case it was an error in my NGINX conf which deviated from the suggested NGINX conf at the following location:

My version:

location ~ ^\/nextcloud\/(?:index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+)\.php(?:$|\/) {
            fastcgi_split_path_info ^(.+\.php)(\/.*|)$;
...
}

Suggested from the link above:

location ~ ^\/nextcloud\/(?:index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+)\.php(?:$|\/) {
            fastcgi_split_path_info ^(.+?\.php)(\/.*|)$;
...
}

I used Firefox Web developer tools whcih showed me that

https://<host>/nextcloud/index.php/apps/files/ajax/getstoragestats.php?dir=%2F

was yielding 404 errors. If the regex above is greedy for the .php-part, a completely different script-location is requested which does not exist. The getstoragestats.php-request fills in the actual free space via an ajax call after the page has loaded and replaces the 0 bytes free with the actual bytes. Only then uploading is actually possible.

As a consequence I cross checked my conf with theirs and found a lot more errors, I suggest you do the same.