nextcloud - Fehler Dateiupload - Sabre\DAV\Exception\BadRequest: expected filesize 1804947 got 65641

mr44er

moderater Moderator
Teammitglied
apache24-2.4.41 Version 2.4.x of Apache web server
mariadb103-client-10.3.16_2 Multithreaded SQL database (client)
mariadb103-server-10.3.16_2 Multithreaded SQL database (server)
nextcloud-php72-16.0.4 Personal cloud which runs on your own server

Sabre\DAV\Exception\BadRequest: expected filesize 1804947 got 65641

Der Fehler (mit diversen filesizes) kommt im Log, wenn ich Dateien uploaden möchte. Es spielt keine Rolle, ob ich das per Maske oder per drag'n'drop versuche, ebenfalls nicht mit einem anderen Browser. Nextcloud quittiert das schlicht mit 'Unbekannter Fehler aufgetreten', nachdem der Ladebalken gefühlt ewig angezeigt wird.
Kleine Testfiles von 4kb lassen sich jedoch problemlos hochladen.

Bis auf den Upload funktioniert die nc-Instanz unauffällig, die mit apache läuft. Das Problem bemerkte ich vor ca. vier Wochen und konnte mich wegen Zeitmangel nicht mehr darum kümmern. Wann der Spuk davor begann, kann ich nicht sagen. Es muß wohl mit einem davorliegenden Update passiert sein, es funktionierte jedenfalls zu Beginn.
Vor besagten 4 Wochen schaute ich zumindest auf github bei nextcloud/server vorbei und das Problem taucht oft auf (jetzt immer noch). Die einen sagen, es läge an einem Bug in apache 2.4.39 und mod_reqtimeout oder http2 deaktivieren hilft. Hat es aber nicht. Wieder andere berichten, dass das Problem selbst bei frischen Installationen besteht.

https://github.com/nextcloud/server/issues/15200#issuecomment-526822475

Hat hier jemand das Problem auch und lösen können oder kann mir wer eine Richtung vorschlagen?
 
Ich hatt den gleichen Fehler. Soweit ich mich erinnere war es aber eine frühere Version von 16 und nicht 16.0.4. Und bei mir war es ein Bug in nextcloud. Kurze Zeit später kam ein Update raus, welches das Problem behoben hat. Derzeit läuft hier Version 17, vielleicht ist das eine Alternative für dich?
 
Und bei mir war es ein Bug in nextcloud.
Tendiere ich auch dazu, aber wie hast du das exakt darauf festnageln können? Ich wurde aus den logs von apache und nc nicht schlau, obwohl ich das loglevel hochdrehte.

v17 nehme ich natürlich mit Handkuss. Hatte die Instanz bisher nur zögerlich angefasst, weil produktiv und ich nicht sinnloser rumstochern wollte, als bisher. ;)
 
Update auf 17 vollzogen, Fehler besteht immer noch.

nc:
Code:
[webdav] Fatal: Sabre\DAV\Exception\BadRequest: Expected filesize of 1288806 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 54017 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side. at <<closure>>

0. /usr/local/www/nextcloud/apps-pkg/dav/lib/Connector/Sabre/Directory.php line 156
   OCA\DAV\Connector\Sabre\File->put(null)
1. /usr/local/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php line 1096
   OCA\DAV\Connector\Sabre\Directory->createFile("iSCSI - xigmanas - vmware - howto.pdf", null)
2. /usr/local/www/nextcloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php line 525
   Sabre\DAV\Server->createFile("dump/iSCSI - xi ... f", null, null)
3. <<closure>>
   Sabre\DAV\CorePlugin->httpPut(Sabre\HTTP\Reque ... "}, Sabre\HTTP\Response {})
4. /usr/local/www/nextcloud/3rdparty/sabre/event/lib/EventEmitterTrait.php line 105
   undefinedundefinedcall_user_func_array([Sabre\DAV\CorePlugin {},"httpPut"], [Sabre\HTTP\Requ ... }])
5. /usr/local/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php line 479
   Sabre\Event\EventEmitter->emit("method:PUT", [Sabre\HTTP\Requ ... }])
6. /usr/local/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php line 254
   Sabre\DAV\Server->invokeMethod(Sabre\HTTP\Reque ... "}, Sabre\HTTP\Response {})
7. /usr/local/www/nextcloud/apps-pkg/dav/appinfo/v1/webdav.php line 80
   Sabre\DAV\Server->exec()
8. /usr/local/www/nextcloud/remote.php line 163
   undefinedundefinedrequire_once("/usr/local/www/ ... p")

PUT /remote.php/webdav/dump/iSCSI%20-%20xigmanas%20-%20vmware%20-%20howto.pdf
from 192.168.xxx.xxx by mr44er at 2019-10-06T17:49:12+00:00

apache:
Code:
[Sun Oct 06 19:46:54.117299 2019] [authz_core:error] [pid 24758] [client 192.168.xxx.xxx:40823] AH01630: client denied by server configuration: /usr/local/www/nextcloud/data/.ocdata
[Sun Oct 06 19:46:54.117327 2019] [headers:debug] [pid 24758] mod_headers.c(899): AH01503: headers: ap_headers_error_filter()
 
Hi,

ich hatte das Problem auch und das weltweite Internet befragt. Beim Einsatz von Apache habe ich folgende Lösung gefunden, die ich aber noch nicht nachvollzogen habe (ich habe es nur in die Config geschrieben und Apache neugestartet, laut meinen Kollegen tritt das Problem dann nicht mehr auf) - also Vorsicht, ich weiss nicht, welche Nebenwirkungen das haben kann:

Code:
<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
</IfModule>

Viele Grüße

Morfio
 
Hi,

ich hatte das Problem auch und das weltweite Internet befragt. Beim Einsatz von Apache habe ich folgende Lösung gefunden, die ich aber noch nicht nachvollzogen habe (ich habe es nur in die Config geschrieben und Apache neugestartet, laut meinen Kollegen tritt das Problem dann nicht mehr auf) - also Vorsicht, ich weiss nicht, welche Nebenwirkungen das haben kann:

Code:
<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
</IfModule>

Viele Grüße

Morfio
Ich kann nicht ausschließen, dass ich mir damals auch dieses Ergebnis ergoogelt habe. Bei mir steht allerdings ein höherer Wert in der Config:

Code:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
 
Strict-Transport-Security ist ein HTTP-Header, der den Browser zwingt immer HTTPS zu nutzen. Also der Webserver sendet den Header, der Browser sieht ihn und macht sich einen Eintrag in seiner Datenbank. Anschließend weiß er, dass die Seite nur per HTTPS angesprochen werden darf und wird alle anderen Verbindungen - also unverschlüsseltes HTTP - verweigern. Verweigern im Sinne von "geht nicht mehr".

Die Zeit gibt einfach an, wie viele Sekunden nach dem letztmaligem Sehen des Headers die Restriktion aktiv bleibt. Bei 31536000 Sekunden muss man also nach dem letzten Senden des Headers ein Jahr warten, bis unverschlüsseltes HTTP wieder erlaubt wird.
 
folgende Lösung gefunden, die ich aber noch nicht nachvollzogen habe
Mhm, kann ich hierzu auch nicht nachvollziehen, da ich weiß, was HSTS bewirkt. -> Yamagi hat es perfekt erklärt.

Macht da was einen Connection:close nach dem ersten Chunk und beim zweiten kommt keine AUTH mehr mit?
Habe nichts Stichfestes, aber so 'fühlt' sich der Ladebalken an, wenn er auf ca. 25% anläuft, ewig hängt, dann auf ca. 60% springt und dann abbricht.

Kurioserweise konnte mein Arbeitskollege heute zum Test diverse Files jeglicher Größe in verschiedenen Ordnern uploaden. Also bei ihm alles perfekt.
Dh. ich habe neue Anlaufstellen: entweder mein Account, DNS von intern irgendwie vermurkst, Berechtigungen checken.
Wobei mir gerade noch einfällt, dass ich vor besagten vier Wochen noch händisch das Zertifikat per certbot aktualisierte. Müsste ich noch gucken, ob dadurch was zwischengrätscht.
 
Möchte abschließend lösen:
Besagte nc-Instanz befindet sich in einer jail in einem anderen Netz. Explizites Setzen von DNAT in der Firewall (OPNsense 19.7.5_5-amd64) löste den Spuk auf.
 
Zurück
Oben