2
Php error with Nextcloud big file uploads
Hi,
I've had some issues with the official Nextcloud (apache) container. When uploading some bigger files (I assume they're bigger, don't know for each individual one, it says 156GB in 13 files) using the desktop sync client it keeps failing and repeating the upload indefinitely.
Does anyone know what I could try to debug this issue further?
I suspect some issue with either the apache2 configuration (or the haproxy) regarding chunking or caching.
apache2 log output:
I've had some issues with the official Nextcloud (apache) container. When uploading some bigger files (I assume they're bigger, don't know for each individual one, it says 156GB in 13 files) using the desktop sync client it keeps failing and repeating the upload indefinitely.
Does anyone know what I could try to debug this issue further?
I suspect some issue with either the apache2 configuration (or the haproxy) regarding chunking or caching.
apache2 log output:
app_6 | [Sun Oct 31 17:36:05.468312 2021] [php:error] [pid 51] [client 2001:DB8::2:44500] PHP Fatal error: Uncaught TypeError: hash_final(): Argument #1 ($context) must be a valid Hash Context resource in /var/www/html/lib/private/Files/Stream/HashWrapper.php:70\nStack trace:\n#0 /var/www/html/lib/private/Files/Stream/HashWrapper.php(70): hash_final(Object(HashContext))\n#1 [internal function]: OC\\Files\\Stream\\HashWrapper->stream_close()\n#2 /var/www/html/3rdparty/icewind/streams/src/Wrapper.php(96): fclose(Resource id #31)\n#3 /var/www/html/3rdparty/icewind/streams/src/CallbackWrapper.php(117): Icewind\\Streams\\Wrapper->stream_close()\n#4 [internal function]: Icewind\\Streams\\CallbackWrapper->stream_close()\n#5 /var/www/html/3rdparty/icewind/streams/src/Wrapper.php(96): fclose(Resource id #34)\n#6 /var/www/html/3rdparty/icewind/streams/src/CountWrapper.php(99): Icewind\\Streams\\Wrapper->stream_close()\n#7 [internal function]: Icewind\\Streams\\CountWrapper->stream_close()\n#8 /var/www/html/3rdparty/icewind/streams/src/Wrapper.php(96): fclose(Resource id #38)\n#9 /var/www/html/3rdparty/icewind/streams/src/CallbackWrapper.php(117): Icewind\\Streams\\Wrapper->stream_close()\n#10 [internal function]: Icewind\\Streams\\CallbackWrapper->stream_close()\n#11 /var/www/html/3rdparty/guzzlehttp/psr7/src/Stream.php(108): fclose(Resource id #41)\n#12 /var/www/html/3rdparty/guzzlehttp/psr7/src/Stream.php(74): GuzzleHttp\\Psr7\\Stream->close()\n#13 [internal function]: GuzzleHttp\\Psr7\\Stream->__destruct()\n#14 {main}\n thrown in /var/www/html/lib/private/Files/Stream/HashWrapper.php on line 70
app_6 | [Sun Oct 31 17:36:06.005881 2021] [php:error] [pid 51] [client 2001:DB8::2:44500] PHP Fatal error: Uncaught TypeError: hash_final(): Argument #1 ($context) must be a valid Hash Context resource in /var/www/html/lib/private/Files/Stream/HashWrapper.php:70\nStack trace:\n#0 /var/www/html/lib/private/Files/Stream/HashWrapper.php(70): hash_final(Object(HashContext))\n#1 [internal function]: OC\\Files\\Stream\\HashWrapper->stream_close()\n#2 {main}\n thrown in /var/www/html/lib/private/Files/Stream/HashWrapper.php on line 70
app_6 | 2001:DB8::2 - user [31/Oct/2021:17:26:12 +0000] "MOVE /remote.php/dav/uploads/user/3337383129/.file HTTP/1.1" 500 858 "-" "Mozilla/5.0 (Windows) mirall/3.3.5stable-Win64 (build 20210930) (Nextcloud, windows-10.0.22483 ClientArchitecture: x86_64 OsArchitecture: x86_64)" 
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1452177506
Url: https://administrator.de/en/php-error-with-nextcloud-big-file-uploads-1452177506.html
Ausgedruckt am: 22.12.2024 um 05:12 Uhr
2 Kommentare
Neuester Kommentar
Hi,
did you check the maximum-upload size in your php config?
Kind regards
did you check the maximum-upload size in your php config?
Kind regards
Thanks, I completely overlooked that one because the client sent the file completely. I just assumed that an upload limit in PHP would cancel the upload and not just receive it completely and drop it afterward...
upload_max_filesize was set to 512M via an environment variable.
Therefore I now just set these environment variables like:
(because it does not appear to prevent anything as the whole file was received anyway)...
Thanks for your help
Edit: Nope it wasn't that. Now it also works with the default limits of 512M (localhost deployment though) ?!? think I've to do some more testing
Edit2: Another few hours later I now found the problematic module. It's related to the S3 module.
As soon as I switch to the S3 bucket instead of local files it causes errors.
Edit3: Noticed why I initially thought the problem was solved. If you just don't do anything and let the client "do its thing", it'll incorrectly show that it synced everything successfully until hitting "Force sync now" or looking into the folder at the status icon of the failing file...
Edit4: Think we're done here. I've opened an Issue upstream. It looks like there is an error-handling API responses from the S3 bucket properly. Can be reproduced (even though slightly different) with another S3 bucket (localstack).
upload_max_filesize was set to 512M via an environment variable.
Therefore I now just set these environment variables like:
PHP_UPLOAD_LIMIT=1024G
PHP_MEMORY_LIMIT=4GThanks for your help
Edit: Nope it wasn't that. Now it also works with the default limits of 512M (localhost deployment though) ?!? think I've to do some more testing
Edit2: Another few hours later I now found the problematic module. It's related to the S3 module.
As soon as I switch to the S3 bucket instead of local files it causes errors.
Edit3: Noticed why I initially thought the problem was solved. If you just don't do anything and let the client "do its thing", it'll incorrectly show that it synced everything successfully until hitting "Force sync now" or looking into the folder at the status icon of the failing file...
Edit4: Think we're done here. I've opened an Issue upstream. It looks like there is an error-handling API responses from the S3 bucket properly. Can be reproduced (even though slightly different) with another S3 bucket (localstack).
1
