How to extend default upload limit NX AIO

I would like to upload big files to my self hosted Nextcloud AIO.

I’m looking for both general tips on how to do it as well as what to do with the default 10GB PHP max upload limit.


Nextcloud is already deployed and running on my VPS so I’d need to adjust the limitation ideally without reinstalling the Docker Image. I have limited experience with Docker, so step-by-step explanations would be appreciated! :pray:

what is this default limit relevant for? I have a 55GB (archived) file I’d like to back up and ideally, not divide it into smaller limited files.

Thanks everyone!

A quick Google search points to this forum.

thank you!

I’m just a little insecure about the next step because I’m not entirely sure how docker works.

the comment in the forum says:

As with any other docker container you need to stop it first, remove it and then adjust the docker run command by adding this environmental varilable to the docker run command. (but before the last line nextcloud/all-in-one:latest).

so as I have NX AIO already deployed and running, what does ‘remove’ mean in this case?
I have several containers running at the moment, which I can stop in the AIO interface. but this is still not the main container referred to in the comment right?

so would you first stop the containers and then which container would you remove and how (before running the docker run script again with the relevant env vars)?

and also, what are the consequences the aforementioned instructions? by rerunning the new docker script, is it like reinstalling NX altogether and then recreating my user or is it info being kept?

what is this default limit relevant for? I have a 55GB (archived) file I’d like to back up and ideally, not divide it into smaller limited files.

Are you having specific problems uploading this file? Under what scenarios?

The 10 GB limit only applies to anonymous uploads or non-Nextcloud WebDAV clients.

first I’ve tried uploading this file from the built-in Gnome-NX integration, through Gnome’s Files. it stopped imedietly, claiming that the file is too large (I think this is a standard WebDAV?).

then I tried again via in Firefox using NX web client. there the upload started and was running for some time (I’ve tried 3-4 times every time it’d run anywhere from 15 mins to an hour) but then it’d eventually stop, providing no reason. so I started reading the uploading large files NX article and found the max upload limit.

so what you are saying, since I’m the admin user, I should have no problem uploading files larger than 10GB?

the only option I haven’t tried yet is via the official NX desktop client. I suppose I could do that by placing the file directly in the synced directory on my drive?

Please check your browser console (Inspect) and network tabs. Also check the Nextcloud Server log. There should be some hint about what’s going wrong somewhere in there.

so what you are saying, since I’m the admin user, I should have no problem uploading files larger than 10GB?

Correct, at least from the NC Web Client UI or any any other official NC client app, it should work. Though there are other variables. For example, if you’re using S3 underneath/etc.

The GNOME Files built-in WebDAV client though doesn’t know anything about the chunking approach AFAIK. That one failing makes sense (I use GNOME regularly for most day-to-day stuff, but not for super large files).

I don’t know what you’re use case is. But if you can’t get the chunking capable clients to work, than non-chunking WebDAV clients are even less likely to work.

So I’d focus on figuring out why the Web UI client isn’t working for you first. :slight_smile:

1 Like

ok. let me try to upload it once more and this time I’ll keep an eye on the console. the browser network console is simple but how do I access to the NC console?

what did you mean by ‘chunking capable clients’?

Nextcloud Server log is in the Web UI under Administration settings->Logging or on-disk in your configured datadirectory in nextcloud.log (at least by default).

what did you mean by ‘chunking capable clients’?

All of the Nextcloud maintained client apps (Web, Desktop, Android, iOS, etc.) have essentially an extension to WebDAV implemented in them to make uploading large files more reliable and faster. The client breaks the file up into chunks of >= 10MB then the uploads the chunks in parallel. Nextcloud Server re-assemblies the chunks automatically into a single file.

1 Like

I see! so maybe this is where it failed. since the upload always started and seemed to be running nominally for a while. I’d leave my PC and come back to check on it occasionally and it’d be running just until the progress bar would no longer be present. so it seems that the breaking down process was taking place up until a certain point.
generally: is there a logistical difference between uploading one large compressed file and the original unarchived folder?

I’m having the consoles open right now and it’s seems to be running in order. I’ll check on it in a bit. I’m not quite sure what sort of signs I should look for in the console/inspect>network

hi again. it’s stopped now.

I’m not sure what information I should share with you. it was running until it wasn’t.

there are some errors 723 found in the log but all I saw was something to do with the Antivirus

I think it’s been unable to start. but I don’t suppose this is related

and there’s an error in the MASTER CONTAINER logs that keeps appearing in a loop over and over again every couple mins:

Message: Not found.
File: /var/www/docker-aio/php/vendor/slim/slim/Slim/Middleware/RoutingMiddleware.php
Line: 76
Trace: #0 /var/www/docker-aio/php/vendor/slim/slim/Slim/Routing/RouteRunner.php(56): Slim\Middleware\RoutingMiddleware->performRouting(Object(GuzzleHttp\Psr7\ServerRequest))
#1 /var/www/docker-aio/php/vendor/slim/csrf/src/Guard.php(482): Slim\Routing\RouteRunner->handle(Object(GuzzleHttp\Psr7\ServerRequest))
#2 /var/www/docker-aio/php/vendor/slim/slim/Slim/MiddlewareDispatcher.php(168): Slim\Csrf\Guard->process(Object(GuzzleHttp\Psr7\ServerRequest), Object(Slim\Routing\RouteRunner))
#3 /var/www/docker-aio/php/vendor/slim/twig-view/src/TwigMiddleware.php(115): Psr\Http\Server\RequestHandlerInterface@anonymous->handle(Object(GuzzleHttp\Psr7\ServerRequest))
#4 /var/www/docker-aio/php/vendor/slim/slim/Slim/MiddlewareDispatcher.php(121): Slim\Views\TwigMiddleware->process(Object(GuzzleHttp\Psr7\ServerRequest), Object(Psr\Http\Server\RequestHandlerInterface@anonymous))
#5 /var/www/docker-aio/php/src/Middleware/AuthMiddleware.php(38): Psr\Http\Server\RequestHandlerInterface@anonymous->handle(Object(GuzzleHttp\Psr7\ServerRequest))
#6 /var/www/docker-aio/php/vendor/slim/slim/Slim/MiddlewareDispatcher.php(269): AIO\Middleware\AuthMiddleware->__invoke(Object(GuzzleHttp\Psr7\ServerRequest), Object(Psr\Http\Server\RequestHandlerInterface@anonymous))
#7 /var/www/docker-aio/php/vendor/slim/slim/Slim/Middleware/ErrorMiddleware.php(76): Psr\Http\Server\RequestHandlerInterface@anonymous->handle(Object(GuzzleHttp\Psr7\ServerRequest))
#8 /var/www/docker-aio/php/vendor/slim/slim/Slim/MiddlewareDispatcher.php(121): Slim\Middleware\ErrorMiddleware->process(Object(GuzzleHttp\Psr7\ServerRequest), Object(Psr\Http\Server\RequestHandlerInterface@anonymous))
#9 /var/www/docker-aio/php/vendor/slim/slim/Slim/MiddlewareDispatcher.php(65): Psr\Http\Server\RequestHandlerInterface@anonymous->handle(Object(GuzzleHttp\Psr7\ServerRequest))
#10 /var/www/docker-aio/php/vendor/slim/slim/Slim/App.php(199): Slim\MiddlewareDispatcher->handle(Object(GuzzleHttp\Psr7\ServerRequest))
#11 /var/www/docker-aio/php/vendor/slim/slim/Slim/App.php(183): Slim\App->handle(Object(GuzzleHttp\Psr7\ServerRequest))
#12 /var/www/docker-aio/php/public/index.php(185): Slim\App->run()
#13 {main}
Tips: To display error details in HTTP response set "displayErrorDetails" to true in the ErrorHandler constructor.

@jtr so it keeps failing. I’ve tried it with the desktop client and the behaviour seems to be similar.
it takes a moment to star syncing and then the syncing progresses seemingly in order until it eventually fails and shows an error.


I’m suspecting it’s something to do with my VPS provider. if the PHP max_upload_limit isn’t the issue, there might be some kind of limitation applying by them. I just have no idea how to verify it.

recent NC logs:

Guessing: Did you try to rename the file to something without emoji before uploading?

Your ClamAV container looks offline.

Turn off anti-virus checks entirely for the time being: Antivirus scanner — Nextcloud latest Administration Manual latest documentation

Or figure out what’s going on with that container.

I’ve stopped the whole container. these logs that I shared yesterday are from when the container was stopped.

I’m afraid I was asking too much from my VPS actually. I think the bandwidth they provide won’t allow me to push such a heavy file and it’s nothing to do with NC itself…

If you disable the ClamAV container, you still need to disable antivirus in Nextcloud itself. That’s why I provided that doc link. It’ll, at a minimum, get rid of that error.

sorry about that! okay I’ve turned off under apps. I’m still receiving antivirus error logs though