Ich habe das Problem, dass mein Backup-Programm (EaseUs), und ebenso das Windows Aufgabenplanungstool (Windows 7) mein virtuelles Cryptomator Laufwerk (Z:) nicht ansprechen können.
Bei EaseUs bekomme ich die Meldung: Laufwerk nicht gefunden.
In der Aufgabenplanung erhalte ich keine Fehlermeldungen, im Gegenteil, doch wird das Sichern, also das Schreiben der Sicherungs-Datei, nicht wirklich ausgeführt.
Im Dateimanager ist das virtuelle Laufwerk Z: jedoch vorhanden und ich kann manuell auch Dateien dahin kopieren, verschieben und löschen. Auch z.B. mit OpenOffice lassen sich Dateien auf Z: speichern. Alles ganz normal und wie üblich.
Der benutzte Befehl in der Aufgabenplanung:
robocopy Q:\KFFDaten\KFFDaten\ Z:\KFFDaten\ . /Purge
Die letzte Ereignismeldung lautet:
Die Aufgabenplanung hat die Aufgabe “\K_FF_Dat_Bakup\K_FF_Sichern”, Instanz “{f76fe42a-a0f8-49a4-8630-7a7851298242}”, Aktion “C:\Windows\system32\robocopy.EXE” mit Rückgabecode 16 erfolgreich abgeschlossen.
Die Dateien wurden jedoch NICHT geschrieben.
Ersetze ich Z: durch ein anderes, nicht virtuelles Laufwerk, dann ist alles ok, die Dateien werden kopiert.
Über Hilfe würde ich mich sehr freuen.
Euch noch einen schönen sonnigen Frühlingstag.
Die Aufgabe selbst (also das Ausführen des robocopy befehls) wurde erfolgreich beendet. Aber robocopy meldet dir den Fehler 16 zurück.
Hier ein Netz-Fundstück wenn man man “Rückabecode 16” sucht, in dem alle Codes aufgelistet sind:
Return Code
The return code from Robocopy is a bit map, defined as follows:
Hex Bit Value Decimal Value Meaning If Set
0x10 16 Serious error. Robocopy did not copy any files. This is either a usage error or an error due to insufficient access privileges on the source or destination directories.
0x08 8 Some files or directories could not be copied (copy errors occurred and the retry limit was exceeded). Check these errors further.
0x04 4 Some Mismatched files or directories were detected. Examine the output log. Housekeeping is probably necessary.
0x02 2 Some Extra files or directories were detected. Examine the output log. Some housekeeping may be needed.
0x01 1 One or more files were copied successfully (that is, new files have arrived).
0x00 0 No errors occurred, and no copying was done. The source and destination directory trees are completely synchronized.
You can use this information in a batch file to report the most serious anomalies, as follows:
if errorlevel 16 echo *FATAL ERROR* & goto end
if errorlevel 8 echo FAILED COPIES & goto end
if errorlevel 4 echo *MISMATCHES* & goto end
if errorlevel 2 echo EXTRA FILES & goto end
if errorlevel 1 echo Copy successful & goto end
if errorlevel 0 echo --no change-- & goto end
:end
Alternatively, full details of the return code could be reported as follows:
if errorlevel 16 echo *FATAL ERROR* & goto end
if errorlevel 15 echo FAIL MISM XTRA COPY & goto end
if errorlevel 14 echo FAIL MISM XTRA & goto end
if errorlevel 13 echo FAIL MISM COPY & goto end
if errorlevel 12 echo FAIL MISM & goto end
if errorlevel 11 echo FAIL XTRA COPY & goto end
if errorlevel 10 echo FAIL XTRA & goto end
if errorlevel 9 echo FAIL COPY & goto end
if errorlevel 8 echo FAIL & goto end
if errorlevel 7 echo MISM XTRA COPY & goto end
if errorlevel 6 echo MISM XTRA & goto end
if errorlevel 5 echo MISM COPY & goto end
if errorlevel 4 echo MISM & goto end
if errorlevel 3 echo XTRA COPY & goto end
if errorlevel 2 echo XTRA & goto end
if errorlevel 1 echo COPY & goto end
if errorlevel 0 echo --no change-- & goto end
:end
Ich habe den Befehl in der Aufgabenplanung noch einmal manuell ausgeführt und und mit /Log mitschreiben lassen auf Laufwerk Q: . Z: geht ja nicht.
Ergebnis:
ROBOCOPY :: Robustes Dateikopieren fr Windows
Gestartet: Sun Mar 03 13:04:40 2019
2019/03/03 13:04:40 FEHLER 3 (0x00000003) Dateisystemtyp des Zieles wird ermittelt Z:\KFFDaten
Das System kann den angegebenen Pfad nicht finden.
Quelle : Q:\KFFDaten\KFFDaten
Ziel - Z:\KFFDaten\
Dateien : *.*
Optionen: . /COPY:DAT /PURGE /R:1000000 /W:30
2019/03/03 13:04:40 FEHLER 3 (0x00000003) Zielverzeichnis wird erstellt
Das System kann den angegebenen Pfad nicht finden.
Der Pfad: Z:\KFFDaten existiert aber schon vorher. Und wenn ich das jetzt richtig verstehe, dann wird der Pfad noch einmal erstellt, dann aber doch nicht gefunden.
Ich muss gestehen, das überfordert etwas meine Vorstellungskraft. Mir war unbekannt und somit auch nicht klar, dass Rückgabecode = Fehlercode ist. Somit unterstellte ich für 16 = alles ok, weil, so wurde es ja auch im Text mitgeteilt.
Davon abgesehen:
Der Hinweis:
…
error due to insufficient access privileges on the source
or destination directories
…
verträgt sich für mich dann irgendwie auch nicht mit der Tatsache, dass OpenO. und der Dateimanager ja problemlos Zugriff haben.
Ich sehe das nicht so.
Fehlercode 16 = fatal error.
Das liefert robocopy zurück. Die Aufgabe selbst, also das Aufrühren eines Befehls war für die Aufgabe erfolgreich. Daher die etwas verwirrende aussage: Die Aufgabe war erfolgreich, die Rückmeldung war 16.
Aber zurück zum Thema, denn es ist ja offensichtlich dass bei kopieren mit robocopy was nicht klappt.
Ich vermute dass robocopy auf z: keinen Zugriff hat und daher den Zielordner nicht findet. Daher versucht es den Ordner zu erstellen, was aber ebenfalls nicht klappt (weil kein Zugriff)
Und das hier ist der Grund für meine Vermutung.
Frage: wenn du die Kommandozeile als Admin ausführst und per Hand den robocopy Befehl eingibst. Funktioniert es dann?
robocopy und WebDAV scheinen nicht die besten freunde zu sein lese ich. Aber grundsätzlich sollte es funktionieren. Ich habs mit dem UNC Pfad zum Tresor versucht und auch mit Dokany, ich komm auf das gleiche Ergebnis wie Du.
Ich denke es liegt an der Schnittstelle, nicht an cryptomator selbst. Allerdings bin ich kein Netzwerk / robocopy Profi, evtl hat noch jemand anderes hier eine Idee.
Der User, der Cryptomator startet, der hat auch Zugriff auf das virtuelle Laufwerk. Nur er und sonst niemand. Also auch kein Admin oder wer immer sich Adminrechte einräumt. Als Sicherheitsaspekt ja nicht so verkehrt.
Leider schließt das aber (Backup-)Funktionen aus, die von Programmen oder dem System auf Adminebene ausgeführt werden.
Also bliebe mir die Frage: Was ist zu tun, dass es dennoch geht?
Bei mir hat robocopy als “nicht-Admin” genauso wenig funktioniert.
Und meine Backups laufen auch ganz “normal”. Die User die rclone z.B. nutzen, melden auch keine grundsätzlichen Probleme.
Bin schon sehr gespannt was die Ursache sein könnte.
Bzgl Dokany ist meine Vermutung ebenfalls, dass ein Benutzter mit höheren Rechten eben nicht der gleiche Benutzter ist und somit wegen der Verwendung von CURRENT_SESSION in Dokany eben ausgesperrt wird. Diese Problematik kann eventuell gelöst werden, jedoch muss die im dazugehörigen Gituhub-Issue geforderte Funktionalität implementiert werden.
Hi infeo,
ich muss gestehen, ich bin über die Grenze der Überforderung hinaus.
Ich weiß nicht was ich alles versucht habe, inclus. deaktivieren der Win 7 UAC. Es ändert nichts, alles bleibt so wie schon vor Tagen.
Ich weiß nicht einmal was für mich besser wäre. Dokany oder Webdav.
Ich habe einen MagentaCloud Ordner der sich automatisch synchronisiert mit der Cloud. Mein Tresor ist in diesem Ordner auf Laufwerk D:
Dazu kommt das virtuelle Laufwerk Z: in dem ich arbeite. OpenOffice, PDF, Bilder, etc. alles kein Problem. Nur das Backup-Programm, sowie auf CMD-Niveau im Admin-Modus robocopy, die finden das Laufwerk Z: nicht.
Ich habe so ziemlich alles darüber gelesen was ich hier so darüber finden und verstehen kann. Das Problem scheint sehr oft aufzutreten und grundsätzlich zu sein. Eine echte Lösung habe ich dafür jedoch auch in den anderen Texten nicht finden können oder ich habe sie aufgrund von Englisch nicht verstanden.
Ich sehe nur die Möglichkeit damit zu Leben oder mir ein anderes Crypto-Programm zu installieren. Was halt schade wäre, denn ich habe für den Cryptomator fürs Händi pflichtbezahlt und für den PC freiwillig. Auch gefällt mir die Einfachheit in der Bedienung.
Falls nochmal irgendwann für die PC-Version für die Command-Ebene eine Parameterübergabe dazu käme, für Passwort etc. und das Nichtaufpoppen der beiden Fenster, dann wäre es für mich sozusagen perfekt.
Den, das-Laufwerk-findet-sich-nicht-Fehler, wird man, so hoffe ich, alsbald mal in den Griff bekommen. Solange muss ich eben meine Backups per Hand und Explorer einfügen.
Es ist zwar schon ein wenig länger her, ich antworte trotzdem (;
Also, du, @Hartmut, kannst daran nichts ändern. Aus Sicherheitsgründen ist es so, dass wenn du Dokany zur Bereitstellung deines Tresor benutzt, ausschließlich der aktuelle Nutzer darauf zugreifen kann. Da der Admin ein anderer Nutzer ist, geht das nicht. Dementsprechend können auch Programme, die mit Admin-Rechten gestartet wurden nicht darauf zugreifen.
Für Cryptomator 1.5.0 ist geplant, dass man zusätzliche Argumente beim Entsperren eines Tresors übergibt. Und über die wird es möglich sein, den Tresor auch für andere Nutzer zugänglich zu machen.
Hast du die Bereitstellung über WebDAV als Netzwerklaufwerk für dein BackUp mal ausprobiert? WebDAV ist zwar langsamer (und hat unter Windows diese 4GB Beschränkung…) aber vielleicht reicht das trotzdem aus.
Ich habe leider das Problem, dass ich bei zwei verschiedenen Backup-Programmen das Cryptomator-Laufwerk nicht als Auswahl bekomme. Wenn ich das gleich mit Boxcryptor versuche wird dieses als Laufwerk erkannt.
Es soll folgendes gemacht werden: Die Daten liegen unverschlüsselt auf der internen Festplatte und sollen dann verschlüsselt als Backup in der Cloud gespeichert werden.
Ist diese Problem bekannt bzw. gibt es hierfür eine Lösung?
Es ist egal, ich habe es mit beiden Varianten probiert. Ich hatte einen ähnlichen Beitrag gefunden, da war wahrscheinlich vom gleichen Problem die Rede. Da gab es allerdings auch keine Lösung.
Inzwischen habe ich meinen Frieden mit obiger Problematik gefunden. Mein Weg dahin sieht nun folgendermaßen aus:
Mit meinem Backup-Programm schreibe ich die ausgewählten zu sichernden Dateien auf ein Hilfs-Laufwerk (Q:) und von dort zeitverzögert per Aufgabenplanungstool und dem Befehl:
robocopy Q:\KFFDaten\KFFDaten\ Z:\KFFDaten\ . /Purge
in den Cryptomator Tresor, der sich im Magenta-Cloud Ordner befinden.
Bei Bedarf ließe sich nun noch der Inhalt von (Q:) wieder löschen, doch den Bedarf habe ich nicht.
Im übrigen, hat es sich als nützlich herausgestellt, Cryptomator auch über das Aufgabenplanungstool zeitverzögert zu starten. Vorher gab es ab und an Probleme, wenn Magenta-Clouds Start noch nicht völlig abgeschlossen war.
In meiner Benutzerkontensteuerung ist jetzt auch wieder die höchste Sicherheitsstufe eingestellt.
