-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Downloads fail at 4GB with error "server returned wrong content-range" with 32bit server #39923
Comments
Hi @cbartondock - Any idea what NC release you were most recently running where this behavior did not occur? Also, for completeness, are you running the 64-bit kernel with 32-bit user land which became the new default behavior on 64-bit Pi boards a few months back? (i.e. raspberrypi/firmware#1795 (comment)) |
Stack trace provided by third party in the linked thread for
|
Unfortunately no, I only recently (on Nextcloud 24) attempted to download a large file (and it failed in exactly the same way). It may have worked in earlier versions or not. Running
So I think that indeed the kernel is 64bit (I update the firmware regularly). The OS is definitely 32 bit, however, as at the time I originally installed it (Raspbian Jessi) there were no 64bit raspbian images. Running |
It may also be relevant that the data directory is on a raid array I haven't tested it yet with the data directory on the sd card. |
Possible patch:
|
I will try the patch and do an occ files:scan and re-attempt to download files |
Is it actually correct that it should be getting a value passed in as a float? That doesn't seem right for a file size which I assume is in bytes. |
So that patch fixed the issue with file / folder sizes showing up as incorrect in the web app, but when I go to download (for example) a 4.3GB file the browser's downloader shows it as 4GB (so clearly the wrong size is being reported) and it fails at 4GB (probably because the two sides disagree on whether or not it should be finished) |
Is there a different file where a similar change should be made to the DAV implementation? |
I ended up upgrading to 64 bit which solved the issue, but if anyone is interested in debugging this I still have the old OS image and would be happy to help. |
Cc @come-nc |
On 32 bits all sizes above 4GB have to be a Do you have a PHP error in the logs with a trace when the download fails at 4GB? |
This one will be fixed by #40501 If anyone encountered another trace, please post it. Either here or in a new ticket if this one is closed. |
Bug description
All downloads from the server fail at around 4GB, and on the sync client it gives the error "server returned wrong content-range." I have verified that the problem is not with apache/php configuration or my external storage (downloading large files from the same raid array via apache directly works just fine) and that it isn't my router configuration (it also fails in exactly the same way when
http://localhost/nextcloud/remote.php/webdav
addresses are used). I have also tried several client devices so it is definitely a server side issue.Based on the fact that it always fails around 4GB I have to conclude that it is my Pi 4's 32bit OS causing the issue - I know that support for 32bit servers was only recently re-introduced to Nextcloud. Interestingly uploads work fine.
It is possible this is a regression that has re-introduced the bug in issue 5031, it certainly seems to be caused by the file sizes being incorrect (most probably those returned by the
stat
function inlib/private/Files/Storage/Dav.php
).Doing an
occ files:scan
does actually correct some but not all of the file sizes displayed in the web app, but it doesn't fix the issue with downloads. I should also note that in order to even getocc files:scan
to run without error on Nextcloud 27 I had to patch in the typecasts suggested here.Neither nextcloud logs nor APACHE/PHP-FPM logs have any errors.
Steps to reproduce
Expected behavior
Downloads of all file sizes up to PHP/APACHE limits suceed.
Installation method
Community Manual installation with Archive
Nextcloud Server version
27
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.1
Web server
Apache (supported)
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Upgraded to a MAJOR version (ex. 22 to 23)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
PHP 8.1.21
Nextcloud 27.1.0 beta 1
Raspbian/Debian Bullseye
The text was updated successfully, but these errors were encountered: