Privatkunden
Geschäftskunden
Sammelthread: Magenta Cloud 1GB Up-/Download Problem via Browser/WebDAV
2 AKZEPTIERTE LÖSUNGEN
Guten Abend @Dr._Seltsam,
danke, dass du dich hier noch einmal zu Wort gemeldet hast.
@Dr._Seltsam schrieb:
In diesem Thread geht es um upload-Probleme mit Dateien ab 1 GB, von denen die Telekom wahlweise behauptet
- es sei "gelöst" (Status in Titelüberschrift)
- es sei "behoben" (Aussage @Ina B. Telekom-Team am 01.10.)
- es sei "immer noch aktuell" oder "scheine aktuell nur noch selten Probleme zu bereiten" (erster Beitrag).
Ich gebe zu, das ist alles sehr verwirrend. 🥴 Ich versuche jetzt einmal, das Thema aus unserer Sicht zu beleuchten.
In diesem Thread ging es ursprünglich um folgendes Thema:
@prophaganda schrieb:
Ich möchte betonen:
Es geht hier ausschliesslich um den Fehler Nr. 012 aus der Liste: Bekannte Fehler und Verbesserungsvorschläge
Dieses damalige Problem wurde behoben, also gelöst. Das ist unter'm Strich die gleiche Aussage (hier in der Community). 😉
Im Laufe der Zeit haben wir aber festgestellt, dass es teilweise immer noch zu Problemen beim Upload größerer Dateien kommt. Und nun Asche auf mein Haupt, das habe ich hier im Thread nicht verfolgt. Daher habe ich das in meiner Antwort gestern leider nicht beachtet, sorry dafür. 😊
@Dr._Seltsam schrieb:
Dass es darüber hinaus eine 2 GByte "Größenbeschränkung" geben soll, höre ich zum ersten mal. Der Begriff "Größenbeschränkung" hört sich für mich erstmal auch nicht nach einem Eingeständnis eines (weiteren?) Fehlers an, sondern soll offenbar eine bewusste Leistungseinschränkung beschreiben. Woraus leitet sich die ab? Ich habe in den AGB dazu nichts gefunden.
Diese Beschränkung gibt es NUR bei der Nutzung der MagentaCLOUD über einen Browser. Hintergrund ist hier m.W. das HTTP-Protokoll. siehe
@Dr._Seltsam schrieb:
Bei mir besteht das 1 GB Problem genau wie von @Stoertie und anderen oft genug beschrieben auch weiterhin, und dazu läuft (angeblich) auch seit Monaten ein offenes Ticket. Anfangs erhielt ich hier auch noch regelmäßig ein update, dass es noch in Bearbeitung sei und man auf eine Rückmeldung der Fachabteilung warte. Seit dem 21.06. habe ich dazu nichts mehr gehört!
Ich habe mal nachgeschaut, das Ticket läuft immer noch. Die letzte Rückmeldung war hier in der Tat am 21. Juni. 😕 Zuletzt hieß es, dass die Entwickler noch nicht analysieren konnten, wodurch das Verhalten ausgelöst wird. Es wurde vermutet, dass eine Kombination von verschiedenen Faktoren zu dem Fehlerbild führen. Wir haken noch einmal nach, ob es neue Erkenntnisse gibt.
BTW: Damit alle Mitlesenden wissen, dass es hier noch Einschränkungen gibt, markiere ich meinen Beitrag absichtlich als Lösung. Das ist aber nur ein Zwischenbescheid. ✋
Herzliche Grüße
Ina B.
Hallo zusammen, ich habe die Rückmeldung erhalten, dass der Fehler
als gelöst gilt, daher erfolgt hier eine Lösungmarkierung.
Es wurden viele Tests durchgeführt und die meisten von euch können wieder Dateien >1GB up- und downloaden. Ich bedaure, dass die Lösungsfindung so lange gedauert hat und bedanke mich für eure Geduld.
Nun gilt
"Tritt ein Fehler, der in der Liste als behoben gekennzeichnet ist, erneut oder weiterhin auf, muss dieser neu bewertet werden. In dem Fall die Teamies bitten den Fehler weiterzuleiten (gerne mit expliziten Beispielen wie: Datei x am xx.xx.2021 heruntergeladen und abgebrochen)."
... und dazu gibt es ja noch vereinzelt Anwender hier im Thread, bei denen der Down- und/oder Upload noch immer klemmt. Diese Fälle werden also individuell betrachtet und weitergeleitet.
P. S.:
Erscheint die Meldung "Existing lock on file, exclusive", bitte einmal aus der MagentaCLOUD ausloggen und anschließend wieder einloggen. Jetzt sollte die Datei an der gewünschten Stelle vorhanden und nutzbar sein. -> Dieser Fehler wurde neu in die Liste aufgenommen.
Viele Grüße
Jonas J.
@duder schrieb:
jedoch glaube ich nicht, dass ein Fehler bei meinem System zu suchen ist.
Um Himmelswillen - das sollte nicht meine Aussage sein...
Fehlermeldungen um das Problem weiter einzugrenzen ist eine wichtige Vorraussetzung...
Und auch wo es genau hapert (im Detail)
@duder schrieb:
Nun könnte ich natürlich das Testfile mal via FF hochladen, um die Browseruploads auch zu prüfen
Das wäre jetzt mal eine Bitte...
Wen die FremdSoftware soweit funktiomniert, dann sollte es mit dem Protokoll passen.
Es geht vielmehr um die Nachvollziehbarkeit.
Was der Anwender z.B. nicht weiß:
Beim Upload werden in der Cloud in einem für den Anwender nicht sichtbaren (temporären) Ordner kleine "zerstückelte" Dateiabschnitte abgelegt.
Das hat den Zweck, dass bei einem Abruch beim letztem Abschnitt angeknüpft werden kann (ohne den Upload von vorne zu beginnen).
Erst wenn Alles oben ist, wird das Ganze in der Cloud zusammengesetzt und erscheint dann im richtigem Ordner.
Die "Datei-Schnipsel" sind immer einer Session zugeordnet.
Wenn also mit dem Browser hochgeladen wird, wird dafür automatisch eine eigene Session erzeugt.
Klappt jetzt z.B. der Upload über den Browser, wäre im nächsten Schritt für Cyberduck eine neue Session zu erstellen (also mit neuem Passwort) und dann sollte es (erst mal theoretisch) auch damit funktionieren.
Ich würde nicht ausschließen wollen, dass bei den >1GB Uplodas im Vorfeld "zerschossene" "Datei-Schnipsel" in der Cloud liegen, die sich dann am Ende nicht mehr zusammensetzen lassen.
Ich hoffe, das war jetzt nicht zu Viel auf einmal... 
Hallo prophaganda,
das werde ich schon noch gebacken bekommen … Jedoch, die 2,6 GB werden am Ende im Browser FF 96.0.2 nicht fertig hochgeladen und enden mit einer für den geneigten Nutzer erhellenden Fehlermeldung:
An exception occurred while uploading parts to a multipart upload. The following parts had errors:
- Part 2: Error executing "UploadPart" on "https://obs.eu-de.otc.t-systems.com/nmcloud-prod1-docs/urn%3Aoid%XXXXX?partNumber=2&uploadId=XXXXXXX..."; AWS HTTP error: Client error: `PUT https://obs.eu-de.otc.t-systems.com/nmcloud-prod1-docs/urn%3Aoid%XXXXXX?partNumber=2&uploadId=0XXXXX...` resulted in a `408 Request Timeout` response:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><Error><Code>RequestTimeout</Code><Message>The server did not rec (truncated...)
RequestTimeout (client): The server did not receive a complete request message within the time that it was prepared to wait. - <?xml version="1.0" encoding="UTF-8" standalone="yes"?><Error><Code>RequestTimeout</Code><Message>The server did not receive a complete request message within the time that it was prepared to wait.</Message><RequestId>0XXXXXXX</RequestId><HostId>zXXXXX</HostId></Error>
- Part 3: Error executing "UploadPart" on "https://obs.eu-de.otc.t-systems.com/nmcloud-prod1-docs/urn%3Aoid%XXXXXX?partNumber=3&uploadId=XXXXXX..."; AWS HTTP error: Client error: `PUT https://obs.eu-de.otc.t-systems.com/nmcloud-prod1-docs/urn%3Aoid%XXXXXX?partNumber=3&uploadId=XXXXXX...` resulted in a `408 Request Timeout` response:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><Error><Code>RequestTimeout</Code><Message>The server did not rec (truncated...)
RequestTimeout (client): The server did not receive a complete request message within the time that it was prepared to wait. - <?xml version="1.0" encoding="UTF-8" standalone="yes"?><Error><Code>RequestTimeout</Code><Message>The server did not receive a complete request message within the time that it was prepared to wait.</Message><RequestId>XXXXX</RequestId><HostId>XXXXXX</HostId></Error>
- Part 4: Error executing "UploadPart" on "https://obs.eu-de.otc.t-systems.com/nmcloud-prod1-docs/urn%3Aoid%3XXXXX?partNumber=4&uploadId=XXXXX"; AWS HTTP error: Client error: `PUT https://obs.eu-de.otc.t-systems.com/nmcloud-prod1-docs/urn%3Aoid%XXXX?partNumber=4&uploadId=XXXXXX` resulted in a `408 Request Timeout` response:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><Error><Code>RequestTimeout</Code><Message>The server did not rec (truncated...)
RequestTimeout (client): The server did not receive a complete request message within the time that it was prepared to wait. - <?xml version="1.0" encoding="UTF-8" standalone="yes"?><Error><Code>RequestTimeout</Code><Message>The server did not receive a complete request message within the time that it was prepared to wait.</Message><RequestId>XXXXX</RequestId><HostId>XXXXXX</HostId></Error>
Das ging also ebenso schief.
So long
duder
Hallo zusammen, ich habe die Rückmeldung erhalten, dass der Fehler
als gelöst gilt, daher erfolgt hier eine Lösungmarkierung.
Es wurden viele Tests durchgeführt und die meisten von euch können wieder Dateien >1GB up- und downloaden. Ich bedaure, dass die Lösungsfindung so lange gedauert hat und bedanke mich für eure Geduld.
Nun gilt
"Tritt ein Fehler, der in der Liste als behoben gekennzeichnet ist, erneut oder weiterhin auf, muss dieser neu bewertet werden. In dem Fall die Teamies bitten den Fehler weiterzuleiten (gerne mit expliziten Beispielen wie: Datei x am xx.xx.2021 heruntergeladen und abgebrochen)."
... und dazu gibt es ja noch vereinzelt Anwender hier im Thread, bei denen der Down- und/oder Upload noch immer klemmt. Diese Fälle werden also individuell betrachtet und weitergeleitet.
P. S.:
Erscheint die Meldung "Existing lock on file, exclusive", bitte einmal aus der MagentaCLOUD ausloggen und anschließend wieder einloggen. Jetzt sollte die Datei an der gewünschten Stelle vorhanden und nutzbar sein. -> Dieser Fehler wurde neu in die Liste aufgenommen.
Viele Grüße
Jonas J.
Kaufberatung anfragen
Zum Kontaktformular
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Angebote anzeigen
Zu den Telekom-Angeboten
Aktuelle Telekom Angebote für Mobilfunk (5G/LTE), Festnetz und Internet, TV & mehr.
