64-bit server, wrong file size shown for files over ~4GB and can't download whole file

Nextcloud version:
Operating system and version: Ubuntu 16.04 LTS
Apache version: 2.4.18
PHP version: PHP 7.0.22-0ubuntu0.16.04.1

The issue I am facing:
In an external storage directory in nextcloud, while viewing on Chrome on Windows 10, large files show the wrong file size and users can only do a partial download up to the wrong file size shown.

Same problem also happens on the Android client.

After some investigation, it appears that files above 2^32 bytes are displaying file sizes equivalent to overflowing their true file size on a 32-bit unsigned integer. So, for example, a 30,806,174,832 file is showing as 707.1 MB, which looks like overflow because (30,806,174,832 modulus 2^32) / 1024^2 = 707.1 MB.

I did prove to myself that PHP is running as 64-bit:

root@nextcloud:~# php -a
Interactive mode enabled
php > echo PHP_INT_SIZE;

I did some searching and saw issues and discussion regarding 32-bit architectures and older versions of nextcloud, but I am on 64-bit architecture and latest nextcloud, version 12.0.3.

Any ideas what could be wrong?

I am also having a problem where right clicking files and “save target as” on multiple files at a time to download them concurrently on the same client will eventually cause all of that client’s downloads to fail, but I figure I should first get the file size issue fixed before tackling that one.

Shall I file a bug?

Could be an issue rather with your system than with Nextcloud. Didn’t saw this kind of issue so far and while Nextcloud is only the PHP “application” which works for most of the users regarding file size, I really believe it’s rather a misconfiguration somewhere.

But well, maybe someone can help you, when you file a bug report.

Any suggestions where to look for a misconfiguration? I followed the install instructions as precisely as possible.

Difficult. Could you try to run file on all the binaries used. For example:

$ file /bin/php
/bin/php: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, ...
$ file /bin/mysql
/bin/mysql: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0,...

Maybe we should also focus on the database. Could you check again if your DB settings match the suggestions?
If I remember correctly especially the following settings where important:

character-set-server = utf8mb4

I’m not sure however if these settings would influence the process in regards to 32 vs 64 bit. But maybe the settings limit something here … or the DB tables are not wide enough.
Could you provide the output of:
mysql> describe oc_filecache;

Here’s the output of the file command you suggested on the binaries I’m aware of.

root@nextcloud:~# file /usr/sbin/mysqld
/usr/sbin/mysqld: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=39d7222ac4e613386655e07c692e9ee949e786e6, stripped
root@nextcloud:~# file /usr/bin/mysql
/usr/bin/mysql: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=722eea8570a9528ab81d24b23dcb7e4c4c102219, stripped
root@nextcloud:~# file /usr/bin/php7.0
/usr/bin/php7.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=83a5621a43de87b4eb5b63859fefc70b964350cf, stripped
root@nextcloud:~# file /usr/sbin/apache2
/usr/sbin/apache2: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=a540a66c15a3ed4d2fdf0d6988b6889a3f390b9d, stripped

Regarding the /etc/my.cnf options, I have binlog_format=mixed, but not character-set-server=utf8mb4. I looked at the NC 12 installation manual and there’s no mention of the configuration you say is important.

Here’s my /etc/my.cnf:


I also see nothing in the Linux Database Configuration that looks definitely amiss, although instead of the mysql.ini file they mention there, I had these two files which don’t seem to contain similar content:

root@nextcloud:~# cat /etc/php/7.0/apache2/conf.d/20-mysqli.ini
; configuration for php mysql module
; priority=20
root@nextcloud:~# cat /etc/php/7.0/apache2/conf.d/10-mysqlnd.ini
; configuration for php mysql module
; priority=10

Here’s the output of DESCRIBE nextcloud.oc_filecache;:

MariaDB [(none)]> describe nextcloud.oc_filecache;
| Field            | Type          | Null | Key | Default | Extra          |
| fileid           | int(11)       | NO   | PRI | NULL    | auto_increment |
| storage          | int(11)       | NO   | MUL | 0       |                |
| path             | varchar(4000) | YES  |     | NULL    |                |
| path_hash        | varchar(32)   | NO   |     |         |                |
| parent           | int(11)       | NO   | MUL | 0       |                |
| name             | varchar(250)  | YES  |     | NULL    |                |
| mimetype         | int(11)       | NO   |     | 0       |                |
| mimepart         | int(11)       | NO   |     | 0       |                |
| size             | bigint(20)    | NO   |     | 0       |                |
| mtime            | int(11)       | NO   |     | 0       |                |
| storage_mtime    | int(11)       | NO   |     | 0       |                |
| encrypted        | int(11)       | NO   |     | 0       |                |
| unencrypted_size | bigint(20)    | NO   |     | 0       |                |
| etag             | varchar(40)   | YES  |     | NULL    |                |
| permissions      | int(11)       | YES  |     | 0       |                |
| checksum         | varchar(255)  | YES  |     | NULL    |                |
16 rows in set (0.00 sec)

…and keying off the idea of seeing what’s actually in the index, I looked up one of the files that was having the issue and lo and behold:

MariaDB [(none)]> select * from nextcloud.oc_filecache where name like 'myfilename';
| fileid | storage | path                | path_hash                        | parent | name         | mimetype | mimepart | size      | mtime      | storage_mtime | encrypted | unencrypted_size | etag          | permissions | checksum |
|    612 |       3 | mypath/myfilename   | 6fcba252ebbb69b716e9243be290e329 |    141 | myfilename   |       19 |        7 | 741403760 | 1397221022 |    1397221022 |         0 |                0 | 59e57c60b3036 |          27 |          |
1 row in set (0.00 sec)

…the size column for this 30GB file is 741403760, which is the same wrong value I’m seeing from the client. The data type of this column seems fine, but just to test I created a test table with similar definition and proved it:

MariaDB [(none)]> create database if not exists test_db_delete_me;
Query OK, 1 row affected (0.00 sec)

MariaDB [(none)]> use test_db_delete_me;
Database changed
MariaDB [test_db_delete_me]> create table `test` (`size` bigint(20) NOT NULL DEFAULT '0');
Query OK, 0 rows affected (0.01 sec)

MariaDB [test_db_delete_me]> insert into test values (30806174832);
Query OK, 1 row affected (0.00 sec)

MariaDB [test_db_delete_me]> select * from test;
| size        |
| 30806174832 |
1 row in set (0.00 sec)

So, I can only conclude that something before the database is causing this issue. What? I have no idea. Can anyone help?

Issue posted here: https://github.com/nextcloud/server/issues/6996

You could try one of the demo instances:

Is this a new setup or something upgraded (your operating system)?

Reading your bug report, do you use a reverse proxy in front of it? If yes, does it work without it?

Is this only an issue when you upload to external storage or also on native Nextcloud storage?

It’s a new setup.

Yes, I have a reverse proxy in front of it. I went around the reverse proxy and the same problem still happened.

Going back through the proxy again, I transferred two of the problem files to the native storage (which is actually an nfs mount to the same storage backend host) and the problem did not happen with those copies of the files. The file size shown via the web app was correct and I was able to download the files entirely.

Seeing as this seems to be an external storage problem, I went ahead and looked at the files via smbclient using the www-data user. The file sizes are correct when viewed this way.

So it seems that something between smbclient and the database is causing the issue.

I discovered today that other large files in the same external storage mount (but different sub-folders) appear correctly!

To further test, I copied one of the original problem files to a new folder in the same external storage mount. It’s file size was correct when viewed in the new folder.

There’s two folders that have this file size issue. One thing I note about the folders are that they both have a non-trivial number of files in them. One has 814 files and the other has 750 files. Is it possible that Nextcloud is sensitive to the number of files in the folder?

External storage is better handled in the bug tracker at https://github.com/nextcloud/server/issues

It needs a developer with more insight in the code to tell you where something can go wrong. Normally, I would expect such a number of files to be no problem. However, it would be nice to try if it works for folders with a smaller number of files.

Agree. :slight_smile:

I ultimately solved my problem by installing php-smbclient, reloading apache, and rescanning the files. Apparently the issue was using smbclient instead of php-smbclient. Note that this still doesn’t fix the issue when the server is running smbclient.