Hallo @newt0n, in der Hoffnung, dass ich Deine Frage richtig verstehe, folgendes erstes Feedback: Die Architektur von Embedded Cloud sieht zunächst einmal vor, dass die Übertragung über das WebDAV-Interface von Nextcloud läuft (siehe URL .../dav/...).
Wäre es möglich, dass wir debuggen, was die Ursache für den Unterbruch bzw. Fehler ist? Ggf. würde uns hier die Netzwerkkonsole im Entwicklerbereich des Browsers (Ctrl+Shift+I) helfen und eine genauere Fehlermeldung/Fehlercode anzeigen.
”I believe the TrueNAS “app” uses the Nextcloud micro-services image underneath. If so, the variables are all documented here. The one you’re likely looking for is APACHE_BODY_LIMIT.
Note that official Nextcloud clients (including the Web UI) do not have this problem since they use chunking.
Ideally someone gets around to implementing chunking for GVFS at some point (there is an open issue here you may want to express your interest in).”
Hallo @newt0n, wir schicken eigentlich bereits 10-MB-Pakete (also nicht in einem grossen Block). Ist es möglich, dass ein Reverse-Proxy vor dem System bereits diese Paketgrössen unterbindet?
ich habe nochmal getestet und kann bestätigen: Von der selben Maschine (und Netzwerk und User) aus funktioniert der Upload einer ca. 2 GB großen ZIP-Datei über das Webinterface ohne Probleme - der Upload aus EC schlägt mit der oben genannten Fehlermeldung fehl. Im Reverse Proxy ist das Limit auf 10GB gesetzt, das kann also nicht das Problem sein.
Hallo @uw, habe ich das richtig in Erinnerung, dass Du mit meinem Supergrossen File den Fehler nachstellen konntest, oder war das nur der (andere besprochene) Bug im enaio?
ich konnte den Effekt zumindest teilweise nachstellen. Leider muss ich zur Behebung mehrere Punkte korrigieren. Auf der einen Seite muss ich vermutlich vom DMS Service weg und das Streaming der enaio Seite direkte implementieren, auf der WebDav Seite (Nextcloud) muss ich den Chunk Upload nochmals prüfen. Ich würde den Bugfix dafür mit dem nächsten Release bereitstellen.