[Bug]: Big file upload in shared folder (without account) is not working

[chino-lu]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• Nextcloud Server is running on 64bit capable CPU, PHP and OS.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

when trying to upload a file in a shared folder without the usage of a folder, it will end in a unknown server error with the following in the logfiles:

Sabre\DAV\Exception\BadRequest: Erwartete Dateigröße von 5000000000 Bytes, aber 0 Bytes gelesen (vom Nextcloud-Client) und geschrieben (in den Nextcloud-Speicher). Dies kann entweder ein Netzwerkproblem auf der sendenden Seite oder ein Problem beim Schreiben in den Speicher auf der Serverseite sein.

while on client side, it becomes visible that the upload ends with a 413 status code

Steps to reproduce

1. create a new folder and make a public share
2. password protect the folder and allow upload and editing
3. open new private window, take the share link and login with the password
4. try to upload a large file (I have tested with a 5GB.bin file)

Expected behavior

the file is fully uploaded and available to the users

Installation method

None

Operating system

None

PHP engine version

None

Web server

None

Database engine version

None

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
    "system": {
        "htaccess.RewriteBase": "\/",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "apps_paths": [
            {
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "192.168.0.11:8666",
            "cloud.removed.xx"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "tempdirectory": "\/var\/www\/html\/data\/tmp",
        "dbtype": "mysql",
        "version": "25.0.2.3",
        "overwrite.cli.url": "https:\/\/cloud.mikeklein.lu",
        "overwritehost": "cloud.removed.xx",
        "overwriteprotocol": "https",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "memories.exiftool_no_local": true,
        "session_lifetime": 86400,
        "session_keepalive": true
    }
}

List of activated Apps

Enabled:
  - cloud_federation_api: 1.8.0
  - dav: 1.24.0
  - federatedfilesharing: 1.15.0
  - files: 1.20.1
  - files_pdfviewer: 2.6.0
  - files_rightclick: 1.4.0
  - files_sharing: 1.17.0
  - files_trashbin: 1.15.0
  - files_versions: 1.18.0
  - logreader: 2.10.0
  - lookup_server_connector: 1.13.0
  - memories: 4.9.2
  - news: 19.0.0
  - nextcloud_announcements: 1.14.0
  - notes: 4.6.0
  - notifications: 2.13.1
  - oauth2: 1.13.0
  - password_policy: 1.15.0
  - photos: 2.0.1
  - provisioning_api: 1.15.0
  - recognize: 3.3.3
  - related_resources: 1.0.3
  - richdocuments: 7.0.2
  - serverinfo: 1.15.0
  - settings: 1.7.0
  - sharebymail: 1.15.0
  - systemtags: 1.15.0
  - text: 3.6.0
  - theming: 2.0.1
  - twofactor_backupcodes: 1.14.0
  - updatenotification: 1.15.0
  - viewer: 1.9.0
  - workflowengine: 2.7.0
Disabled:
  - activity: 2.17.0
  - admin_audit
  - bruteforcesettings
  - circles: 25.0.0
  - comments: 1.15.0
  - contactsinteraction: 1.6.0
  - dashboard: 7.5.0
  - encryption
  - federation: 1.15.0
  - files_external
  - firstrunwizard: 2.14.0
  - privacy: 1.9.0
  - recommendations: 1.4.0
  - support: 1.8.0
  - survey_client: 1.13.0
  - suspicious_login
  - twofactor_totp
  - user_ldap
  - user_status: 1.5.0
  - weather_status: 1.5.0

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

comment too long

Additional info

System is running on a Dell R720 with UnRaid using the official Docker container from Nextcloud.
It had been tested with Nginx Proxy Manager and Swag.

[szaimen]

Hi, as this is very likely a configuration issue and I cannot reproduce the issue, please ask in https://help.nextcloud.com to get help

[chino-lu]

ok, config is working for people with account, but not for those without. to me, very strange behavior and config issue seems not to be the root cause

[t-schuster]

Hi,

We faced the same issue and found the issue origin.

This is an issue with the docker container because Apache 2.4.54 changed the default upload limit in Apache from unlimited to 1 Gigabyte if no limit is specified.

The official docker container has upgraded the internal apache (when not using FPM) to 2.4.54 and now there is no effective way to change the upload limit. The PHP environment variable has no effect.

It works for logged in users because they can use the chunked file upload API, bypassing the body limit. Shared folders cannot use this API and then will run into this limit at 1 GiB.

The issue should be reopened, this is a bug in the official Nextcloud container. We can reliably reproduce the issue from a clean docker setup.

[t-schuster]

@szaimen Steps to reproduce:

1. Pull official Nextcloud Container nextcloud:25.0.3-apache
2. Go through normal setup, log in and create a folder
3. Create a sharelink with upload permission on the folder
4. Log out of Nextcloud, ensure cookies have been deleted
5. Use the sharelink to upload a file of ATLEAST 1 GiB SIZE, ideally 2 or 3 gigabytes.
6. The upload will fail once apache reaches the request size limit

Workaround:

Extract the Apache 000-default.conf file and add LimitRequestBody 10737418240. This should allow uploads of up to 10GiB. Alternatively add LimitRequestBody 0 for an unlimited request size. PHP Request Limits will also apply, so they must be configured too.
Then mount the resulting file over the official docker configuration.

Verified again on our own setup.

[szaimen]

Please open an issue about this here: https://github.com/nextcloud/docker/issues

[t-schuster]

The Server documentation is still out of date and doesn't mention the issue.

edit: There is several issues already open on the docker repository with no fix since early 2022. It seems that the docker repository isn't interested in a fix, so it should be fixed here.

The server should allow enabling chunked file uploads for shares via share links, which would bypass the issue entirely.

[szaimen]

You mean this documentation?
https://docs.nextcloud.com/server/stable/admin_manual/configuration_files/big_file_upload_configuration.html

[t-schuster]

That and the installation documentation.

The given link does not mention that Apache now has this limit, it only notes that mod_reqtimeout could stop large uploads.

The nginx section specifically notes that there is 1 GiB limit, the Apache section mentions no such limit. This should be adjusted.

The installation documentation also only mentions the upload limits in connection to the PHP.ini file and nginx, not to in connection to Apache.

There is also NO notes on the Docker setup, as there it will ship with the default configuration of 1 GiB limitations (which the downstream docker repository has not fixed in almost a year) in the -apache Container.

[szaimen]

Feel free to open an issue about this in the documentation repo: https://github.com/nextcloud/documentation/issues

[t-schuster]

Thanks, I have opened an issue over there.

I would like to reiterate though that Server should fix this as the official Docker repo has not issued the 1-liner fix (adding LimitRequestBody 0 to the Apache configuration to restore previous behaviour) in over a year, so there seems to be no interest in fixing it on their end. Hence this issue should be reopened.

[szaimen]

The docker container is maintained by the community so feel free to open an issue over in the correct repo.

[t-schuster]

There is already an issue open on the docker container repository for almost a year with no response from the developers.

But I see, if it's community maintained then that would move the issue over there. It would be helpful if this was indicated, as that image repository is advertised as the official Nextcloud image and maintained by Nextcloud GmbH on Dockerhub, and it's part of the Nextcloud github org. There is no good way to tell that the nextcloud/docker repository is not, in fact, an officially supported or endorsed product, but merely a community effort.

Thank you for your responses so far.