NO free space left on /dev/root -- why use a local external hard disk?

Steps to reproduce

  1. check unused space on /dev/root
  2. upload a file with server web interface
  3. data dir is /media/ext-hdd
  4. check unused space on /dev/root
    5 /dev/root unused has shrunk with size of uploaded file

Expected behaviour

a few bytes less of unused space on /dev/root

Actual behaviour

/dev/root unused has shrunk with size of uploaded file
What is the use of an external hard disk then?

Server configuration

raspbian 3.1 september 2019

Web server:


PHP version:

ownCloud version: (see ownCloud admin page)

Updated from an older ownCloud or fresh install:
older fresh

Where did you install ownCloud from:
can not remember, do not know
Signing status (ownCloud 9.0 and above):
No idea what is meant.

This is known and intended.
During an upload PHP will use system temp folders to store the chunks and files.
Make sure to move the temp folder off the system partition:

1 Like

Thanks for your reply. Thing is you point to ‘big_file_upload_configuration’ though the file I sent was less than 512 MB. O.K. I followed the pointers there.
Should these directives in .user.ini really be preceded with php_value?
php_value upload_max_filesize = 16G
php_value post_max_size = 16G

Adjust these values for your needs. If you see PHP timeouts in your logfiles, increase the timeout values, which are in seconds:

php_value max_input_time 3600
php_value max_execution_time 3600

Some of these directives were already present, but without the php_value.
But I am stumped by the upload_tmp_dir = /var/big_temp_file/ because it confuses me if I have to use “quotes” or no quotes?
I used quotes.
When all was set (?) I tried it and got a message about Chunks on server do not sum up….
Well after researching it a bit, putting the casting (string) in the function, it is not only when using big files, it is with small files as well.
I welcome any advice.

I don’t think it will hurt to adjust these settings to also allow for larger uploads. I linked this because it mentions where to adjust the temp folders.

This is how you adjust these values from within the .user.ini, otherwise you’ll have to adjust your pool config.

Do you mean in the PHP ini? I would try to just copy paste, if that is incorrect you could try to make a pull-request on the docs to fix.

This means you’re using PHP-FPM. Make sure that you’re using a recent version and are patched against the recent remote code execution vulnerability. Because otherwise the installation might be vulnerable to the NextCry malware.

1 Like

It was quite a puzzle, but the urgent problems were solved.
For the external temporary file I had created a partition that was mounted on /media/pi/tmp. At first I gave access rights to www-data, user and group. Other users and groups seemed not to make a difference. So I replaced the mount to /media/tmp, with access user:group for root, rwxrwxrwt.

The upload_tmp_dir = /media/tmp (without quotes) in php.ini finally worked for syncing with the client, after I removed the variable (cast) in the owncloud/apps/dav/lib/Upload/ChunkingPlugin.php function. No longer the error: Chunks on server do not sum up…

But with every upload /dev/root used still grew. Deleting an owncloud file did not reduce the used percentage.
Eventually I did find the delete option in the webinterface and that helped a bit.

But how could it be that my /dev/root was still around the 90%?

With find I started digging where the files for the group www-data resided. To my relief I did find them in the /media/owncloud-partition. And what I also saw were a lot of files in an uploads folder. These seemed superfluous, so I cleaned the map out. I am rather amazed these files are not removed automagically.

/dev/root is now on a nice 52% used, with more than 5GB available.
But the main question remains, what is the use of a huge external hard drive if it counts in /dev/root where I have only 5 GB left??

And thanks for the tip on NextCry.


this looks quite outdated to me. Maybe you could update to the more recent ownCLoud 10.3.2 to see if this brings any improvements, especially for the following here:

1 Like