Keine Backups via WebDAV möglich
vor 14 Jahren
Seit etwa einem halben Jahr nutze ich Duplicati, um Sicherungen per WebDAV in das Mediencenter hochzuladen. Seit geraumer Zeit funktioniert das aber nicht mehr wirklich, weil das Mediencenter immer wieder gerade eben erzeugte Dateien (getestet mit 10 MB, 20 MB bzw. 50 MB-Dateien) als Dateien mit der Größe 0 ausweist.
Vermutlich hängt das Problem mit den auch an anderer Stelle erwähnten Problemen mit der WebDAV-Umsetzung zusammen.
Einer der Duplicati-Entwickler hat mir hierzu folgende Analyse zugesendet, die ich hier in der Hoffnung poste, dass sie so den Weg über den Moderator an die zuständigen Techniker findet (via "Kontakt" wird die Nachricht abgeschnitten) - möglicherweise hilft sie bei der Fehlersuche.
Für eine Rückmeldung wäre ich dankbar!
Gruß
Joachim Deckers
Hire die Antwort von René, einem der Duplicati-Entwickler:
In short:
I could reproduce the issue but I don't know what triggers it.
I found a few postings on the internet that described exactly the same issue. No solution though.
The issue itself is very simple: Duplicati creates a new file that should be 25MB big. After the WebDAV server has received it, it says "File successfully created. File size is 0 bytes.".
It seems impossible to get in touch with t-online if you are not a customer. I managed to get into the forums with my mediencenter account but I am not allowed to post anything within the first 14 days.
What to do:
I suggest you to get in touch with the Mediencenter support. Tell them that we think we found a server bug and want to talk to someone who maintains the WebDAV servers. To prove that we are not some stupid posers, here some excerpts from the log file:
Duplicati wants to store a file and sends a first request:
User-Agent: Duplicati WEBDAV Client v1.3.3.1457
Content-Type: application/octet-stream
Authorization: Basic ******
Host: webdav.mediencenter.t-online.de
Content-Length: 26213520
Expect: 100-continue
Connection: Close
The request seems to be ok for the WebDAV server and it replies as expected:
Version = 1.1,
StatusCode = 100,
StatusDescription = Continue.
Then Duplicati sends 26213520 bytes of data to the WebDAV server. The WebDAV server acknowledges the reception of data.
The Mediencenter WebDAV server sends a success message and says it has created the file successfully:
Version = 1.0,
StatusCode = 201,
StatusDescription = Created.
StatusDescription = Created.
Unfortunately, it also reports the created file to be 0 bytes:
Date: Sat, 06 Oct 2012 13:03:26 GMT
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
Content-Length: 0
Content-Type: application/zip
This only happens once in a while. 500 files were ok, 1 was not.
It's ok to give them my email address: (hier im Forum unterdrückt). They can get in touch with me in English or German.
As we (Duplicati) now know this faulty behavior of the Mediencenter WebDAV server, we are able to create a work around. Unfortunately, Kenneth is very busy with other things at the moment and Kenneth is the main developer. I can do analysis but my programming skills are too limited. That's why we would perfer you to get in touch with the Mediencenter customer support first and not wait for a quick fix.
René
Vermutlich hängt das Problem mit den auch an anderer Stelle erwähnten Problemen mit der WebDAV-Umsetzung zusammen.
Einer der Duplicati-Entwickler hat mir hierzu folgende Analyse zugesendet, die ich hier in der Hoffnung poste, dass sie so den Weg über den Moderator an die zuständigen Techniker findet (via "Kontakt" wird die Nachricht abgeschnitten) - möglicherweise hilft sie bei der Fehlersuche.
Für eine Rückmeldung wäre ich dankbar!
Gruß
Joachim Deckers
Hire die Antwort von René, einem der Duplicati-Entwickler:
In short:
I could reproduce the issue but I don't know what triggers it.
I found a few postings on the internet that described exactly the same issue. No solution though.
The issue itself is very simple: Duplicati creates a new file that should be 25MB big. After the WebDAV server has received it, it says "File successfully created. File size is 0 bytes.".
It seems impossible to get in touch with t-online if you are not a customer. I managed to get into the forums with my mediencenter account but I am not allowed to post anything within the first 14 days.
What to do:
I suggest you to get in touch with the Mediencenter support. Tell them that we think we found a server bug and want to talk to someone who maintains the WebDAV servers. To prove that we are not some stupid posers, here some excerpts from the log file:
Duplicati wants to store a file and sends a first request:
User-Agent: Duplicati WEBDAV Client v1.3.3.1457
Content-Type: application/octet-stream
Authorization: Basic ******
Host: webdav.mediencenter.t-online.de
Content-Length: 26213520
Expect: 100-continue
Connection: Close
The request seems to be ok for the WebDAV server and it replies as expected:
Version = 1.1,
StatusCode = 100,
StatusDescription = Continue.
Then Duplicati sends 26213520 bytes of data to the WebDAV server. The WebDAV server acknowledges the reception of data.
The Mediencenter WebDAV server sends a success message and says it has created the file successfully:
Version = 1.0,
StatusCode = 201,
StatusDescription = Created.
StatusDescription = Created.
Unfortunately, it also reports the created file to be 0 bytes:
Date: Sat, 06 Oct 2012 13:03:26 GMT
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
Content-Length: 0
Content-Type: application/zip
This only happens once in a while. 500 files were ok, 1 was not.
It's ok to give them my email address: (hier im Forum unterdrückt). They can get in touch with me in English or German.
As we (Duplicati) now know this faulty behavior of the Mediencenter WebDAV server, we are able to create a work around. Unfortunately, Kenneth is very busy with other things at the moment and Kenneth is the main developer. I can do analysis but my programming skills are too limited. That's why we would perfer you to get in touch with the Mediencenter customer support first and not wait for a quick fix.
René
Hinweis:
Dieser Beitrag wurde geschlossen.
Hinweis:
Dieser Beitrag ist nicht mehr für Antworten oder Kommentare geöffnet und ist nicht mehr für die Mitglieder der Community sichtbar.
6301
0
0
Das könnte Ihnen auch weiterhelfen
vor 4 Jahren
in
269
0
2
vor 6 Jahren
in
2481
0
1
vor 4 Jahren
in
860
2
1
Beliebte Tags letzte 7 Tage
Das könnte Sie auch interessieren
Kaufberatung anfragen
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Angebote anzeigen
Informieren Sie sich über unsere aktuellen MagentaCLOUD-Angebote.
vor 14 Jahren
@vfluegel: es gibt folgende Optimierungmöglichkeiten in der davfs.conf zum Ausprobieren, damit es mit dem MC klappt:
use_locks 0
cache_size 1 # MiByte
table_size 4096
delay_upload 1
gui_optimize 1
@SwingVoter: Welchen WebDAV-Client nutzen Sie? Falls Sie ebenfalls davfs verwenden, probieren Sie doch bitte auch die Optimierung der davfs.conf.
0
0
vor 14 Jahren
der Konfigurationsvorschlag für Davfs funktioniert.
Gestern ca. 200 Dateien übertragen, 0-Byte-Problem ist nicht mehr aufgetaucht.
Danke!
0
0
vor 14 Jahren
Upload bei mir via Fritzbox 7390 (kopieren der Dateien auf USB-Stick der Fritzbox, dann Upload von der Fritzbox auch bei ausgeschalteten Computer). Habe in den letzten 24 Stunden 7 Dateien zwischen 350 MB und 2,0 GB versucht. Ergebnis: Alle werden mit 0 angezeigt und sind auch leer. Der Upload hat zudem etwa doppelt so lange gedauert wie mit meiner Uploadgeschwindigkeit zu erwarten.
0
0
vor 14 Jahren
Dateiübertragung in den Online-Speicher fehlgeschlagen. Fehler: 412 Precondition Failed. Datei: *****.zip
0
0
vor 14 Jahren
Dateiübertragung in den Online-Speicher fehlgeschlagen. Fehler: 412 Precondition Failed. Datei: *****.zip
Danke für diese Info. Diese Meldung muss nicht ein Fehler sein. Der WebDAV-Client kann in seinem Request an den Server eine Bedingung mitgeben. Wenn diese Bedingung nicht erfüllt ist, dann muss der Server nach RFC mit dem Code 412 antworten (Precondition failed = "Vorbedingung nicht erfüllt").
Ein Beispiel wäre, wenn der Client bei der Kopieranfrage ein "Overwrite: F" mitsendet. In einem solchen Fall würde der Kopiervorgang mit derselben Meldung abbrechen, wenn es am Zielort schon eine entsprechende Ressorce gibt (F steht für false, also Overwrite: F = nicht überschreiben).
Um eingrenzen zu können, ob die Ursache beim Client oder bei unserem Server liegt, müssten wir den Request kennen, den die Fritzbox gesendet hat. Zeigt denn die Fritzbox zufällig noch mehr an? Vielleicht könnten Sie uns auch eine Mail an foren.foren@telekom.de schicken, damit die Kollegen die Logs überprüfen können. Benötigt werden folgende Infos in der Mail:
* vollständiger Name
* Kundennummer
* Zugangsnummer/E-Mail-Adresse des Mediencenters
* Handynummer
* Zeitpunkt des Uploads in das Mediencenter + Dateiname einer betroffenen Datei
* Nickname SwingVoter
Als Betreff verwenden Sie bitte unbedingt "Angeforderte E-Mail, ID 11055416“.
0
0
vor 13 Jahren
Der 'precondition_failed'-Dialog tauchte hier auch auf, wurde aber inzwischen ersetzt mit DBuserror:
org.freedesktop.DBus.Error.Service.Unknown: The name:1.465 was not provided by any .service files.
Wie gesagt, mit anderen Clouds gibt es keine Probleme und über den Webbrowser 300+MB hochladen ist keine Option.
0
0
vor 13 Jahren
http://dbus.freedesktop.org/doc/dbus-specification.html#auth-command-error
Ich kann natürlich auch falsch liegen, aber zumindest eine Veränderung des clients (Dateimanager) ausschliessen und das die Verbindung mit anderen clouds klappt wiegt m.E. schwerer.
0
0
vor 13 Jahren
@SwingVoter und lin_tux: Gestern früh wurde ein Bugfix live genommen, der den Upload von größeren Dateien stabiler macht, deren Upload zwangsläufig länger dauert. Würden uns über ein Feedback freuen, ob das Problem der 0-Byte-Dateien bzw. des Fehlers 412 damit gelöst ist.
@lin_tux und Apollon123: Wir haben die anderen Beiträge in einen neuen Thread verschoben:
http://foren.t-online.de/foren/read/-/-/-,442,11059210,11080735.html
Sie handelten zwar auch um Backups, aber in diesem Thread geht es um die 0-Byte-Problematik. Sie erwähnen vom Original abweichende Dateigrößen. Lassen Sie uns das Thema in dem anderen Thread behandeln, um die Übersicht zu wahren. Danke.
0
0
vor 13 Jahren
Im Gegensatz zu meinem früheren Test vor 1-2 Monaten gab es dabei keinerlei Fehler - also weder Abbrüche/Fehlermeldungen, noch das Problem der 0-Byte-Dateien. (auch ohne "--list-verify-uploads")
0
0
von
vor 10 Jahren
Die Dateien ließen sich alle hochladen aber eben erst nach mehrmaligem Versuch. Im Übertragunsmonitor konnte ich auch Stundenlang Upload-Aktivität sehen.
Und komplett unbeantwortet: warum werden für eine 3 GB-Datei mehr als 6 GB Daten übertragen?
0
von
vor 10 Jahren
Die Dateien ließen sich alle hochladen aber eben erst nach mehrmaligem Versuch. Im Übertragunsmonitor konnte ich auch Stundenlang Upload-Aktivität sehen. Und komplett unbeantwortet: warum werden für eine 3 GB-Datei mehr als 6 GB Daten übertragen?
Und komplett unbeantwortet: warum werden für eine 3 GB-Datei mehr als 6 GB Daten übertragen?
Können Sie einen Screenshot des Übertragngsmonitors dieser Uploads hier einstellen?
Viele Grüße
Jürgen Wo.
0
von
vor 10 Jahren
Leider nicht - WebDAV hat keinen Übertragungsmonitor.
0