File Drop Not Working for Large Files

Support intro

Sorry to hear you’re facing problems :slightly_frowning_face: is for home/non-enterprise users. If you’re running a business, paid support can be accessed via where we can ensure your business keeps running smoothly.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:


Or for longer, use three backticks above and below the code snippet:


Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can :heart:

Nextcloud version (eg, 20.0.5): 27.1.4
Operating system and version (eg, Ubuntu 20.04): Debian 11
Apache or nginx version (eg, Apache 2.4.25): Apache 2.4.56
PHP version (eg, 7.4): 8.1.26

The issue you are facing:
Uploads to public file drop shares fail when trying to upload large files. I don’t have a hard size cut-off but the largest I could upload was 5GB. When I try a 100GB .zip though it usually makes it about 30% or so and then fails saying “Couldn’t upload for an unknown reason”.

I CAN however upload just fine to the same exact folder when authenticated, and NOT using the public drop link. Checking the logs in “/var/log/apache2” it seems like the public drop uploads aren’t chunked? I only ever see one PUT request for the file I’m trying to upload.

Is this the first time you’ve seen this error? (Y/N):Y

Steps to replicate it:

  1. Create Folder
  2. Create a shareable “File drop” link.
  3. Start a file upload using this link in a private window with a file >100GB
  4. Upload fails after some time.

The output of your Nextcloud log in Admin > Logging:

Nothing relevant is generated here.

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

$CONFIG = array (
  'passwordsalt' => '[REDACTED]',
  'secret' => '[REDACTED]',
  'trusted_domains' => 
  array (
    0 => 'localhost',
    1 => '<>',
    2 => '<nextclouds local IP>',
  'trusted_proxies' =>
  array (
    0 => '<REVERSE PROXY IP>'
  'datadirectory' => '/var/www/nextcloud-data',
  'dbtype' => 'mysql',
  'version' => '',
  'overwrite.cli.url' => 'http://localhost',
  'dbname' => '[REDACTED]',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => '[REDACTED]',
  'dbpassword' => '[REDACTED]',
  'installed' => true,
  'instanceid' => '0725c6a7f7c17',
  'memcache.local' => '\\OC\\Memcache\\Redis',
  'redis' => 
  array (
    'host' => '/var/run/redis/redis.sock',
    'port' => 0,
    'timeout' => 0.0,
  'filelocking.enabled' => true,
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'maintenance' => false,
  'theme' => '',
  'loglevel' => 2,
  'updater.secret' => '[REDACTED]',
  'mail_smtpmode' => 'smtp',
  'mail_smtpsecure' => 'ssl',
  'mail_sendmailmode' => 'smtp',
  'mail_from_address' => '[REDACTED]',
  'mail_domain' => '[REDACTED]',
  'mail_smtpauth' => 1,
  'mail_smtpname' => '[REDACTED]',
  'mail_smtppassword' => '[REDACTED]',
  'mail_smtphost' => '[REDACTED]',
  'mail_smtpport' => '465',

The output of your Apache/nginx/system log in /var/log/____:
The only logs I could find that are relevant to this is the browser logs of the client. When the upload fails it generates this:

 PUT https://<MY.NEXTCLOUD.COM>/public.php/webdav/<FILENAME> 500 (Internal Server Error)
send @ jquery.js:10191
ajax @ jquery.js:9772
(anonymous) @ jquery-migrate.min.js:2
t.<computed> @ jquery-migrate.min.js:2
send @ jquery.fileupload.js?v=0014ef76-2:915
c @ jquery.js:3802
u @ jquery.js:3870
setTimeout (async)
(anonymous) @ jquery.js:3908
l @ jquery.js:3536
add @ jquery.js:3595
(anonymous) @ jquery.js:3928
(anonymous) @ jquery-migrate.min.js:2
t.<computed> @ jquery-migrate.min.js:2
then @ jquery.js:3913
_onSend @ jquery.fileupload.js?v=0014ef76-2:959
(anonymous) @ jquery-ui.js:143
data.submit @ jquery.fileupload.js?v=0014ef76-2:677
addFileToUpload @ files_drop.js?v=0014ef76-2:68
add @ files_drop.js?v=0014ef76-2:95
_trigger @ jquery-ui.js:717
(anonymous) @ jquery.fileupload.js?v=0014ef76-2:1051
each @ jquery.js:385
_onAdd @ jquery.fileupload.js?v=0014ef76-2:1044
(anonymous) @ jquery-ui.js:143
(anonymous) @ jquery.fileupload.js?v=0014ef76-2:1254
l @ jquery.js:3536
add @ jquery.js:3595
always @ jquery.js:3748
_onChange @ jquery.fileupload.js?v=0014ef76-2:1244
(anonymous) @ jquery-ui.js:143
s @ jquery-ui.js:626
dispatch @ jquery.js:5466
f.handle @ jquery.js:5270
Show 24 more frames
Show less
index.js:318 OC.requestToken changed k8xt...<REST OF TOKEN>

Output errors in nextcloud.log in /var/www/ or as admin user in top right menu, filtering for errors. Use a pastebin service if necessary.

I don’t have a nextcloud.log.

Makes sense. 100gb is absolutely massive for a random browser session upload with no frills. Try a different service like magic wormhole for such a serious upload. Or, use a designated guest account as you’ve done.

Also important is whether you are connected over 10gb hardwire nic as opposed to generic wifi with a 10mb/sec disk on the server.

That’s correct, currently.

You can upvote and/or subscribe to track progress on the feature suggestion here:

It just seems strange that the functionality to make this work is already there. It just needs to be allowed on unauthenticated sessions. Everything in this situation is hardwired, either way speed isn’t what I’m concerned about. It’s just the fact that this feature is blatantly handicapped for no actual reason other than, they just haven’t gotten around to fixing it.

However what’s more concerning to me is that there is no warning, no notice, no message, no log within the Web UI, nothing that tells the user that File Drops are meant for tiny files. The fact that I spent a entire day digging through logs to realize the difference in upload method is silly.

Thanks, after posting this I found that link through Google lol

I believe the last I looked a bit at it, the roadblock is that anonymous users don’t have a home directory so there’s no place to put the chunks. So it’s not as simple as just enabling for unauthenticated connections. Someone has to think through where the intermediate files go, how they’ll be managed, security implications, etc.

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