-
-
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
[app.files] expected filesize 10485760 got 10477568 #15200
Comments
Ref #13855 https://github.com/nextcloud/documentation/edit/master/admin_manual/installation/nginx.rst we may add this to the nginx template and/or .htaccess for apache2 then. What value do you suggest? cc @nextcloud/documentation @tomasz-grobelny |
The value heavily depends on the use-case and the main location of the instance's users and the quality of the connection to the server. Taking into account that all connections must be successful, because otherwise uploading a large folder won't be reliable, I think it goes something like:
So, with
|
The question is then whether we should keep |
I don't think those should be constant, e.g. A better approach could be, e.g. link to my previous comment from the documentation (I know it can be a bit dense to put there directly) and note that it can be an issue in function of user's bandwidth (I don't think server bandwidth is the issue normally). If I had to suggest a default value for |
I'm using the nextcloud docker instance (Version: 16.0.3.0) on a synology NAS and I'm getting the same error. Friends are uploading a couple of files via their mobile web browser to my server and a couple of files wont get uploaded due to Sabre\DAV\Exception\BadRequest: expected filesize x got y. Gonna try it now with disabled HTTP2. Edit:
PUT /public.php/webdav/85EB31F9-58E1-4A86-A00A-9777B8AD1824.jpeg |
Changed the reqtimeout_module configuration and now i think it works like a charm.
|
Problem still exists, but I don't know when it started. I'm mostly using calendar, not files. Due to the thingie with mod_reqtimeout I updated Apache to 2.4.41 and additionally tested with deactivating the module - same error. Log is on max debug, but gives only this:
Nextcloud:
Really don't know, what to do now. |
This comment has been minimized.
This comment has been minimized.
Is this Issue still valid in NC21.0.2? If not, please close this issue. Thanks! :) |
@szaimen the solution is actually in the initial report. I think for now, adding the
to the default nginx configuration should be fine for most cases, just the default |
Thanks for the feedback! So can this issue be closed then? :) |
Yes, let me close it, I'll open a PR against the docs in a minute. |
Steps to reproduce
for i in $(seq 1 50); do dd if=/dev/zero of=$i.bin; done
Nginx log shows the request having a
408
Error in nextcloud log: is
expected filesize 10485760 got 10477568
Expected behaviour
Upload should finish for all files. Maybe even retry if a particular upload fails.
Actual behaviour
Randomly about 8% of the files uploaded fail with the same message
Server configuration
Operating system: Debian
Web server: Nginx
Database: MariaDB
PHP version:
v.7.3.3-1
Nextcloud version: 16.0RC2
Updated from an older Nextcloud/ownCloud or fresh install: Updated from 15 through 16.0beta1
Where did you install Nextcloud from: signed tarballs
Nextcloud configuration:
Config report
Are you using external storage, if yes which one: local
Are you using encryption: no
Are you using an external user-backend, if yes which one: LDAP
LDAP configuration (delete this part if not used)
Used, should not be relevant.
Client configuration
Browser: Firefox
Operating system: FreeBSD 12.0
Solution
While documenting this bug, I noticed that the client's request stays hanging and that the web server logs a
408
. This meant that it was cutting the connection.Setting
client_body_timeout 300s;
(a significantly higher value than the default) fixed this for me.Why this is still a bug, albeit not code wise, but documentation wise:
Since the web client now defaults to 10 parallel uploads, with IIRC 10MB chunks, this means that when uploading a large number of larger files, the client will in reality be uploading 100MB at any time, expecting all of those to always finish within the default
client_body_timeout
value of 60s means expecting a consistent upload speed for data of about 13Mbps , it is not reasonable for the general use-case!I still open this issue, so the documentation for the upgrade and installation notes points out that this change in the web server will be needed.
PS: NextCloud 16 will be great; the files app appears to (finally!) work just as expected.
The text was updated successfully, but these errors were encountered: