No upload >1GB in shared folders (if using the shared link) possible - traefik

Nextcloud version (eg, 25.0.5): 28.0.0
Operating system and version (eg, Ubuntu 20.04):Debian 12
Apache or nginx version (eg, Apache 2.4.25): Apache 2.4.57
PHP version (eg, 7.4): 8.2

The issue you are facing:

If i try to upload any file >1GB to a shared folder by using its shared link (so not by just open it via my logged in account) it immediatly stops and shows:“Could not upload:Some_File_Name”. If i just open the same folder without the shared link, i am able to upload every filesize unristricted and without any problems. I assume it has something to do with my reverse proxy traefik, but I don’t really understand the difference between these upload variants (Shared link or ”direct”) so I post it here to maybe get a hint on what I can do about it…

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

Steps to replicate it:

  1. Create a Folder.
  2. Share it.
  3. Open the link and try to upload >1GB files.

The output of your Nextcloud log in Admin > Logging:

{"reqId":"qigrA8JhnW4mmW50GGtY","level":3,"time":"2023-12-20T16:10:18+00:00","remoteAddr":"93.216.420.69","user":"--","app":"no app in context","method":"PUT","url":"/public.php/webdav/LANGER%20STREAM%20~%20TINDER%20~%20IWAS%20MIT%20STEGI%20VERMUTLICH%20~%20PAYDAY%20~%20REACTIONS%20~%20TIKTOKS.mp4","message":"Erwartete Dateigröße von 1612158656 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.","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36","version":"28.0.0.11","exception":{"Exception":"Sabre\\DAV\\Exception\\BadRequest","Message":"Erwartete Dateigröße von 1612158656 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.","Code":0,"Trace":[{"file":"/var/www/nextcloud/apps/dav/lib/Connector/Sabre/Directory.php","line":148,"function":"put","class":"OCA\\DAV\\Connector\\Sabre\\File","type":"->"},{"file":"/var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php","line":1098,"function":"createFile","class":"OCA\\DAV\\Connector\\Sabre\\Directory","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php","line":504,"function":"createFile","class":"Sabre\\DAV\\Server","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/var/www/nextcloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"httpPut","class":"Sabre\\DAV\\CorePlugin","type":"->"},{"file":"/var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php","line":472,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php","line":253,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php","line":321,"function":"start","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/var/www/nextcloud/apps/dav/appinfo/v1/publicwebdav.php","line":124,"function":"exec","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/var/www/nextcloud/public.php","line":81,"args":["/var/www/nextcloud/apps/dav/appinfo/v1/publicwebdav.php"],"function":"require_once"}],"File":"/var/www/nextcloud/apps/dav/lib/Connector/Sabre/File.php","Line":301,"message":"Erwartete Dateigröße von 1612158656 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.","exception":[],"CustomMessage":"Erwartete Dateigröße von 1612158656 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."},"id":"658314662115e"}```

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

<?php
$CONFIG = array (
  'instanceid' => '',
  'passwordsalt' => '',
  'secret' => '',
  'trusted_domains' => 
  array (
    0 => '192.168.2.31',
    1 => '192.168.2.165',

  ),
  'datadirectory' => '/mnt/data/',
  'dbtype' => 'mysql',
  'version' => '28.0.0.11',
  'overwrite.cli.url' => 'DOMAIN',
  'overwriteprotocol' => 'https',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => '',
  'dbpassword' => ',
  'installed' => true,
  'default_phone_region' => '',
  'default_language' => '',
  'trusted_proxies' => 
  array (
    0 => '192.168.2.165',
    1 => '192.168.2.250',
  ),
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'memcache.distributed' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' => 
  array (
    'host' => 'localhost',
    'port' => 6379,
  ),
  'maintenance' => false,
  'theme' => '',
  'loglevel' => 2,
  'log.condition' => 
  array (
    'apps' => 
    array (
      0 => 'admin_audit',
    ),
  ),
  'app_install_overwrite' => 
  array (
    0 => 'richdocumentscode',
    1 => 'drawio',
    2 => 'external',
    3 => 'dicomviewer',
    4 => 'epubreader',
    5 => 'electronicsignatures',
    6 => 'files_3dmodelviewer',
    7 => 'files_rightclick',
  ),
  'mail_smtpmode' => 'smtp',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_sendmailmode' => 'smtp',
  'mail_smtpauth' => 1,
  'mail_smtpsecure' => 'ssl',
  'mail_smtphost' => 'smtp.gmail.com',
  'mail_from_address' => '',
  'mail_domain' => 'gmail.com',
  'mail_smtpport' => '465',
  'mail_smtpname' => '',
  'mail_smtppassword' => '',
  'updater.release.channel' => 'stable',
  'ldapProviderFactory' => 'OCA\\User_LDAP\\LDAPProviderFactory',
);

Here is my traefik config:

http:
  routers:
    nextcloud-router:
      rule: "Host(`DOMAIN`)"
      entryPoints:
        - "websecure"
      middlewares:
        - "nc-dav"
        - "nc-headers"
      service: "nextcloud-service"
      tls:
        certResolver: "production"

  middlewares:
    nc-dav:
      replacePathRegex:
        regex: "^/.well-known/ca(l|rd)dav"
        replacement: "/remote.php/dav"    
    nc-headers:
      headers:
        customFrameOptionsValue: SAMEORIGIN
        framedeny: true
        stsIncludeSubdomains: true
        stsPreload: true
        stsSeconds: 15552000

  services:
    nextcloud-service:
      loadBalancer:
        servers:
          - url: "http://192.168.2.31:80/"

I just don’t get the difference between the shared folder and the direct folder access… But maybe you can help <3

I thought it works, but it doesnt…
It loads the loadingbar to 100% and then breaks with the error mentioned above.

Weelll… haha - got it. It is a known problem because of the following:

Hi @jospoortvliet
I just came across this issue and had the very same symptoms as described by @0xnor0. I’m running NC v16.0.5.
What I have discovered is that the upload works fine to the very same folder, when I’m logged in. However, when using a private browser session and the public shared link with upload option, then It does not work. Also, the two ways do upload the file distinct significantly!
When uploading logged-in, the file is sent in chunks of 10MB to the following URL:
/remote.php/dav/uploads/{user}/web-file-upload-079828e8c1d254f98d8b73d8304dbd80-1571255990916/188743680 (last component is changing between requests)
However, when uploading from the public upload-enabled link, then the entire file is sent in one single PUT request:
/public.php/webdav/filename.ext
Therefore, the maximum client-side post limit is reached (e.g. client_max_body_size for nginx) and the request never even hits PHP or NC but is refused by the web server. Increasing this limit, enables the upload. However, an upload size of 3.5GB is not necessarily the best option and not available from many hosting providers.
That this is a common use case has been documented here and here (and other places).
So an approach to the solution would be to use the same upload component (or at least approach) of the web interface for public shared links as it is used in the regular logged-in state.
If it is considered a bug or feature request, I don’t know. Probably more the latter. However, it would be cool if the web client could give a better error message. Which would be easy, given that the server returns a http status code of 413 Payload Too Large.
But given that it is indeed a common use case, it would be much better than the suggested approach of creating a common user for third parties.
Thanks,
Martin.

this is still the case. To get around it i added

LimitRequestBody 322122547200

into the .htaccess (/nextcloud/.htaccess) right below the </FilesMatch> part. It has to be in the <IfModule mod_headers.c>.
But i would prefer if the filehandling is getting changed to the 10mb split variant.

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