# WebDAV “HTTP Error: Request Entity Too Large”

**URL:** <https://help.nextcloud.com/t/webdav-http-error-request-entity-too-large/228103>\
**Category:** ℹ️ Support\
**Tags:** app\_api, postgresql, linuxserverio, ldap, webdav, nc31, setup\_warning\
**Created:** [July 5, 2025, 9:05pm UTC](https://help.nextcloud.com/t/webdav-http-error-request-entity-too-large/228103 "2025-07-05T21:05:38Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![hiasiboy](https://help.nextcloud.com/letter_avatar/hiasiboy/32/6_22734026db12803ebb3e059622ac3534.png) [@hiasiboy](https://help.nextcloud.com/u/hiasiboy)\
**Post date:** [July 5, 2025, 9:05pm UTC](https://help.nextcloud.com/t/webdav-http-error-request-entity-too-large/228103/1 "2025-07-05T21:05:39Z")

</div>

Hi,  
I am facing an Issue I’ve read about in 2-3 Threads already, but the solution does not work for me.

I am using NC 31.0.6.2 from the [linuxserver.io](http://linuxserver.io) Dockerimage on an x86-64 qnap nas  
[nextcloud - LinuxServer.io](https://docs.linuxserver.io/images/docker-nextcloud/)  
(supportinfo below)

On the client side I am using GNOME 48 (on ubuntu and arch btw), which lets you neatly add nextcloud in the filemanager via webdav.  
When uploading a file \>1gig, I get the message “HTTP Error: Request Entity Too Large” in my file browser.

From what I’ve read, it’s because this approach does not use chunking, but setting APACHE\_BODY\_LIMIT to “0” should remedy this.

I set the variable in portainer to 0, but that yielded no result after restarting the container.

So I used:  
`# docker exec -it nextcloud occ config:system:set --type="string" --value='0' APACHE_BODY_LIMIT`

(sidenote: this is the recommended way to use occ when using the [nextcloud - LinuxServer.io](https://docs.linuxserver.io/images/docker-nextcloud/) docker image)

(second sidenote I also tried --type=“integer”, same result)

and restarted the docker container.

I confirmed, that the setting should be there with  
`# docker exec -it nextcloud occ config:system:get --output="json_pretty" APACHE_BODY_LIMIT`  
`"0"`

and I’d say that looks ok. Sadly I still can’t copy the files.

I also set the following values:  
PHP\_UPLOAD\_LIMIT =\> ‘16G’  
POST\_MAX\_SIZE =\> ‘16G’  
PHP\_MEMORY\_LIMIT =\> ‘4G’

and restarted the container, but to no avail.  
I have basic linux skills, but this whole docker-, cloud-, and web-world is pretty foreign to me.

Thanks already,  
Hias

Server setup info:

## Server configuration detail

**Operating system:** Linux 5.10.60-qnap #1 SMP Wed Jan 8 04:05:31 CST 2025 x86\_64

**Webserver:** nginx/1.26.3 (fpm-fcgi)

**Database:** mysql 11.4.5

**PHP version:** 8.3.19

Modules loaded: Core, date, libxml, pcre, zlib, filter, hash, json, random, readline, Reflection, SPL, session, cgi-fcgi, bcmath, bz2, ctype, curl, dom, fileinfo, ftp, gd, gmp, iconv, standard, intl, ldap, mbstring, openssl, pcntl, PDO, pgsql, posix, imap, SimpleXML, sockets, sodium, sqlite3, sysvsem, xml, xmlwriter, zip, exif, mysqlnd, pdo\_pgsql, pdo\_sqlite, Phar, xmlreader, pdo\_mysql, apcu, msgpack, igbinary, redis, memcached, imagick, mcrypt, smbclient, libsmbclient, Zend OPcache

**Nextcloud version:** 31.0.6 - 31.0.6.2

**Updated from an older Nextcloud/ownCloud or fresh install:**

**Where did you install Nextcloud from:** unknown

> **Signing status**
>

> **List of activated apps**
>
> ```auto
> Enabled:
> - activity: 4.0.0
> - app_api: 5.0.2
> - bruteforcesettings: 4.0.0
> - circles: 31.0.0
> - comments: 1.21.0
> - contactsinteraction: 1.12.0
> - federation: 1.21.0
> - files_downloadlimit: 4.0.0
> - files_pdfviewer: 4.0.0
> - files_reminders: 1.4.0
> - files_sharing: 1.23.1
> - files_trashbin: 1.21.0
> - files_versions: 1.24.0
> - firstrunwizard: 4.0.0
> - forms: 5.1.1
> - logreader: 4.0.0
> - nextcloud_announcements: 3.0.0
> - notifications: 4.0.0
> - password_policy: 3.0.0
> - photos: 4.0.0-dev.1
> - privacy: 3.0.0
> - recommendations: 4.0.0
> - related_resources: 2.0.0
> - serverinfo: 3.0.0
> - sharebymail: 1.21.0
> - support: 3.0.0
> - survey_client: 3.0.0
> - text: 5.0.0
> - updatenotification: 1.21.0
> - user_status: 1.11.0
> - weather_status: 1.11.0
> - webhook_listeners: 1.2.0
> Disabled:
> - admin_audit
> - audioplayer: 3.4.1
> - checksum: 1.2.6
> - dashboard: 7.11.0
> - encryption
> - epubviewer: 1.8.0
> - files_external
> - music: 2.2.0
> - suspicious_login
> - systemtags: 1.21.1
> - twofactor_nextcloud_notification
> - twofactor_totp
> - user_ldap
> 
> ```

> **Configuration (config/config.php)**
>
> ```auto
> {
> "datadirectory": " ***REMOVED SENSITIVE VALUE***",
> "instanceid": " ***REMOVED SENSITIVE VALUE***",
> "passwordsalt": " ***REMOVED SENSITIVE VALUE***",
> "secret": " ***REMOVED SENSITIVE VALUE***",
> "trusted_domains": [
> "PRIVATE"
> ],
> "trusted_proxies": " ***REMOVED SENSITIVE VALUE***",
> "dbtype": "mysql",
> "version": "31.0.6.2",
> "overwrite.cli.url": "PRIVATE",
> "dbname": " ***REMOVED SENSITIVE VALUE***",
> "dbhost": " ***REMOVED SENSITIVE VALUE***",
> "dbport": "",
> "dbtableprefix": "oc_",
> "mysql.utf8mb4": true,
> "dbuser": " ***REMOVED SENSITIVE VALUE***",
> "dbpassword": " ***REMOVED SENSITIVE VALUE***",
> "installed": true,
> "memcache.local": "\\OC\\Memcache\\APCu",
> "filelocking.enabled": true,
> "memcache.locking": "\\OC\\Memcache\\APCu",
> "upgrade.disable-web": true,
> "filesystem_check_changes": 1,
> "APACHE_BODY_LIMIT": "0",
> "PHP_UPLOAD_LIMIT": "16G",
> "POST_MAX_SIZE": "16G",
> "PHP_MEMORY_LIMIT": "4G"
> }
> 
> ```

**Cron Configuration:**

Mode: cron  
Last: 2025-07-05T17:20:02+00:00 (46 seconds ago)

**External storages:** files\_external is disabled

**Encryption:** no

**User-backends:**

- OC\User\Database

**Subscription:**

- No valid subscription key set

**Browser:** Mozilla/5.0 (X11; Linux x86\_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36

## Setup checks

> **system**
>
> - Errors in the log: 14 errors in the logs since 28. Juni 2025, 19:20:48
> - Maintenance window start: Server has no maintenance window start time configured. This means resource intensive daily background jobs will also be executed during your main usage time. We recommend to set it to a time of low usage, so users are less impacted by the load caused from these heavy tasks.
> - Mimetype migrations available: One or more mimetype migrations are available. Occasionally new mimetypes are added to better handle certain file types. Migrating the mimetypes take a long time on larger instances so this is not done automatically during upgrades. Use the command `occ maintenance:repair --include-expensive` to perform the migrations.

> **config**
>
> - Default phone region: Your installation has no default phone region set. This is required to validate phone numbers in the profile settings without a country code. To allow numbers without a country code, please add “default\_phone\_region” with the respective ISO 3166-1 code of the region to your config file.
> - Email test: You have not set or verified your email server configuration, yet. Please head over to the “Basic settings” in order to set them. Afterwards, use the “Send email” button below the form to verify your settings.

---

<div class="post-metadata">

**Author:** ![hackito](https://help.nextcloud.com/user_avatar/help.nextcloud.com/hackito/32/72842_2.png) [@hackito](https://help.nextcloud.com/u/hackito)\
**Post date:** [July 6, 2025, 6:52am UTC](https://help.nextcloud.com/t/webdav-http-error-request-entity-too-large/228103/2 "2025-07-06T06:52:50Z")

</div>

The issue likely stems from the nginx proxy, not Apache. Since you’re using the [LinuxServer.io](http://LinuxServer.io) image with nginx (fpm-fcgi), you need to set `client_max_body_size 0;` in the nginx config to allow large uploads. The `APACHE_BODY_LIMIT` setting won’t apply here. Update the nginx config inside the container (if editable) or via reverse proxy (if used), then restart nginx. This should resolve the “Request Entity Too Large” error.

---

<div class="post-metadata">

**Author:** ![hiasiboy](https://help.nextcloud.com/letter_avatar/hiasiboy/32/6_22734026db12803ebb3e059622ac3534.png) [@hiasiboy](https://help.nextcloud.com/u/hiasiboy)\
**Post date:** [July 6, 2025, 8:58am UTC](https://help.nextcloud.com/t/webdav-http-error-request-entity-too-large/228103/3 "2025-07-06T08:58:30Z")

</div>

> [@hackito](#):
>
> client\_max\_body\_size

Hi,  
That was actually a super good pointer, thank you!

I looked, and the nginx config in the nginx config inside the nextcloud container config and it had already set `client_max_body_size 0;`

BUT I also have a separate nginx reverse proxy running in a separate Docker container ( nginx proxy manager, failed to mention that above 🤦 ), and I looked in the config files for that and in the file, for my nextcloud entry in the folder `/nginx-manager/data/nginx/proxy_host` I added the lines

```auto

  # https://docs.nextcloud.com/server/latest/admin_manual/installation/nginx.html#nextcloud-in-the-webroot-of-nginx

  # set max upload size and increase upload timeout:
  client_max_body_size 0;
  client_body_timeout 300s;
  fastcgi_buffers 64 4K;

  # The settings allows you to optimize the HTTP2 bandwidth.
  # See https://blog.cloudflare.com/delivering-http-2-upload-speed-improvements/
  # for tuning hints
  client_body_buffer_size 512k;

```

inside the

```auto
server {
...
}

```

restarted the nginx proxy manager container and boom now it works, thank you!

so in conclusion, for anyone stumbling onto this, the problem was a separate reverse proxy i already used via a separate docker container, calles “nginx proxy manager”, which needed the above changes!

Knowing more of the setup now, I should probably get rid of the reverse proxy inside the nextcloud container, but that seems like a different adventure for a different day.

Cheers!

---

<div class="post-metadata">

**Author:** ![system](https://help.nextcloud.com/user_avatar/help.nextcloud.com/system/32/29333_2.png) [@system](https://help.nextcloud.com/u/system)\
**Post date:** [July 14, 2025, 8:59am UTC](https://help.nextcloud.com/t/webdav-http-error-request-entity-too-large/228103/4 "2025-07-14T08:59:04Z")

</div>

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.