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.
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??
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: