AMS 150 Problem nach dem Backup der USB-Platte

[lestat1973]

Hallo,

habe mir nun auch das AMS 150 zugelegt und ich bin wirklich zufrieden...

Folgendes Problem habe ich jedoch und bitte um Hilfe:
Da die Kopiergeschwindigkeit von meiner externen USB Platte über meinen Router extrem laaaangsam vonstatten ging, entschied ich mich die Platte direkt an das AMS anzuschliessen. Meine Platte war ja korrekt erkannt und dank der neuen Firmware konnte ich die Daten ja auch ordentlich lesen. Ein Kopierversuch vom PC aus, brachte keine Verbesserung, da die Daten nun von der USB-Platte am AMS wieder über's Netz zum AMS gingen. Langsam. Also drückte ich einfach auf das BACKUP Knopf. Die gesamte Platte (80GB) wurde relativ schnell (1h) in einen Ordner unterhalb von Share reinkopiert.
Dieser neuer Ordner ist nun komplett schreibgeschützt. Heißt, ich kann meine Daten nicht mehr innerhalb von Share verschieben (wollte ja lediglich paar Movies von der USB-Platte auf Share moven).
Da meine Kenntnise in Linux lange zurück liegen und über FTP der CHMOD-Befehl mit der Änderung auf 0777 nicht zulässig war, hoffe ich auf einen Hinweis aus dem Forum.
Grundsätzlich würde ich ja auch gerne wissen wie man am besten die Daten zwischen USB-Platte und AMS austauschen kann ohne das Netz zu bemühen.

Vielen Dank!
D. Konrad

[lochness]

Guter Test!
Ja, das ist so, ich habe mit telnet mal draufgeschaut. Es werden wohl teilweise die Rechte übernommen, die die USB-Platte mit NTFS hat, wenn sie am AMS gemountet ist. Das ist natürlich nicht so gut, denn an die UNIX Rechte kommt der normale Benutzer ja gar nicht dran. Beispiel:

# ls -l
dr-xr-xr-x 3 32767 32767 4096 Oct 21 05:50 $RECYCLE.BIN
dr-xr-xr-x 3 32767 32767 4096 Oct 25 19:07 RECYCLER
dr-xr-xr-x 4 32767 32767 4096 Oct 25 19:11 Scripte
dr-xr-xr-x 4 32767 32767 4096 Oct 24 04:04 System Volume Information
drwxr-xr-x 4 0 0 4096 Nov 27 21:11 ams150

Es werden da wohl, je nach Ebene oder so, verschiedene Rechte mit verschiedenen Benutzern verwendet. Die Source-Platte hat auf den ersten Blick überall den Owner 32767, die Gruppe 32767 und die Rechte dr-xr-xr-x .

Ich würde das als kleineren Fehler einstufen, denn wenn ein Backup auf ein - logischerweise - schreibbares Laufwerk gemacht wird, dann sollten die Daten nachher auch bearbeitet werden können.

Mit FTP kann man die Rechte nicht korrigieren, das kann man entweder mit "telnet" oder man setzt von Windows aus das Readonly Attribut um (Eigenschaften auf den Ordner und dann rekursiv über den ganzen Baum).

[lestat1973]

Hallo lochnes, vielen Dank für Deine Antwort.

Es werden da wohl, je nach Ebene oder so, verschiedene Rechte mit verschiedenen Benutzern verwendet. Die Source-Platte hat auf den ersten Blick überall den Owner 32767, die Gruppe 32767 und die Rechte dr-xr-xr-x .

Das ist richtig.

das kann man entweder mit "telnet" oder man setzt von Windows aus das Readonly Attribut um (Eigenschaften auf den Ordner und dann rekursiv über den ganzen Baum).

Die zweite Möglichkeit habe ich natürlich als erster bereits ausprobiert, funktionierte leider nicht wegen "Zugriff verweigert" - Meldung. Hatte dann hier über die telnet Möglichkeit gelesen und das auch von shell aus in XP ausprobiert, leider kann ich mich dort nicht mit einem "open IP" connecten.

Wenn Du mir da eine Hilfestellung bieten könntest, wäre ich sehr dankbar. Meine AMS Platte ist halt jetzt mit 1/5 mit diesem Backup belegt, welches ich nicht benötige...

Ich bin zwar Programmierer (.NET C#), aber meine Welt ist halt Windows und von Linux verstehe nicht so viel, aber die Kenntnise sollten ausreichen.

Vielen Dank für Deine Hilfe!
D. Konrad

[lochness]

Die zweite Möglichkeit habe ich natürlich als erster bereits ausprobiert, funktionierte leider nicht wegen "Zugriff verweigert" - Meldung.

Ich habe es aber doch gestern von meinem PC aus genauso gemacht Mein Share-Ordner hat immer noch die Standard-Einstellungen, dass jeder alles darf. Und, ich habe einen Vista-PC. Ich könnte es mit XP noch mal machen, aber nicht mehr jetzt.

Hatte dann hier über die telnet Möglichkeit gelesen und das auch von shell aus in XP ausprobiert, leider kann ich mich dort nicht mit einem "open IP" connecten.

Nun, ich weiß nicht, ob Du die Firrmware-Extensions modifiziert hattest oder modifizierte irgendwoher bekommen hattest. Der telnet-Zugang ist standardmäßig nicht drin und der wird von FSC auch nicht supported, das ist was "selbstgebasteltes".

Wenn Du mir da eine Hilfestellung bieten könntest, wäre ich sehr dankbar. Meine AMS Platte ist halt jetzt mit 1/5 mit diesem Backup belegt, welches ich nicht benötige...

Klar, kann ich machen, schick mir schon mal eine PN mit Deiner E-Mail-Adresse, wenn Du mit dem Setzen der Atrribute nicht weiterkommst (schon mal aus der Eingabeaufforderung versucht?).

Ich bin zwar Programmierer (.NET C#), aber meine Welt ist halt Windows und von Linux verstehe nicht so viel, aber die Kenntnise sollten ausreichen.

Das sollte hinzubekommen sein.

[lestat1973]

Gute morgen,

über Windows geht es definitiv nicht. Share ist natürlich mit Standardrechten da. Allerdings ist der Ordner unterhalb Share (in meinem Fall 2007_11_24_1739) mit den Rechten versehen wie in deinem und meinem letzten Post beschrieben. Ein Versuch Schreibschutz zu entfernen (egal ob auf der Ebene des Root Backup Ordners, eines Unterordners oder gar einzelner Dateien) wurde mit einem "Zugriff verweigert" quittiert. Es geht auch aus der Eingabeaufforderung von XP nicht! Zugriff verweigert. Liegt es daran das meine Platte mit NTFS formattiert ist? Oder kannst Du das gleiche mit einer FAT 32 Platte beobachten?

lestat1973 hat Folgendes geschrieben:
Hatte dann hier über die telnet Möglichkeit gelesen und das auch von shell aus in XP ausprobiert, leider kann ich mich dort nicht mit einem "open IP" connecten.
Nun, ich weiß nicht, ob Du die Firrmware-Extensions modifiziert hattest oder modifizierte irgendwoher bekommen hattest. Der telnet-Zugang ist standardmäßig nicht drin und der wird von FSC auch nicht supported, das ist was "selbstgebasteltes".

Ich habe ganz normal die Beta eingespielt, ich wußte nicht das da kein telnet drauf ist...Ich kann ja versuchen im Thread von Mr. Suizid nachzuschauen wie das funktioniert, telnet draufzupacken...Ich sende Dir eine PN mit meiner Mailadresse zu.

Gibt es aber einen einfacheren Weg diesen Backup-Ordner loszuwerden?
Und grundsätzlich für die Zukunft wie man die Daten einfach von der USB-Platte auf das NAS schieben kann ohne das Netzwerk zu bemühen?

Vielen, vielen Dank schon mal

[matze]

Hi,

also dein Problem besteht darin, dass du von einem USB-(NTFS-)Laufwerk Daten per Backup auf den AMS kopiert hast und diese nun auf der AMS-Platte nicht mehr löschen kannst? Das ist in der Tat sehr komisch und könnte was mit NTFS zu tun haben. Das muss doch auch ohne telnet-Zugang zu löschen sein ...

Bist du unter Windows mit einer Kennung angemeldet, die über Administratorrechte verfügt? Hast du im AMS-GUI eine Kennung mit Schreibrechten für "Share" konfiguriert, die exakt so lautet wie der Windows-Benutzername, unter dem du in Windows eingeloggt bist? Falls nicht, könntest du das nochmal probieren!

[matze]

Grundsätzlich würde ich ja auch gerne wissen wie man am besten die Daten zwischen USB-Platte und AMS austauschen kann ohne das Netz zu bemühen.

Meines Wissens geht das nur über den von dir genutzten Weg des Backup-Buttons. Allerdings ist weder dessen Funktion konfigurierbar noch das, was gesichert wird. Es werden schlicht die Daten von USB I nach Share gesichert. Mag sein, dass diese Möglichkeit für einige sehr interessant und nützlich ist. Ich benötige eher den umgekehrten Weg: die Daten des AMS - zumindest ausgewählte - von der AMS-Platte auf ein externe Platte sichern. Was sich da bei mir künftig ansammeln wird, ist mir schlicht zu wichtig als dass ich ein Abrauchen der AMS-Platte ohne Herzschlag verkraften würde. Es gibt meiner Meinung nach zwei elegante Möglichkeiten, wobei die eine etwas unschöner ist, weil sie den Umweg über Router und Netz (in meinem Fall auch noch WLAN) geht. Die elegantere und vermutlich schnellste Variante bedeudet allerdings wirklich eine ziemliche Bastelei und man benötigt als Vorausetzung auf jeden Fall Unix-Kenntnisse und einen telnet-Zugang zum AMS.

Zunächst einmal sollte man sich überlegen, was für eine Art von Backup man machen möchte. Ich habe keine große Ahnung davon, hier könnte man ja mal nachlesen: http://en.wikipedia.org/wiki/Incremental_backup Egal... was ich machen möchte, und im Folgenden beschreibe, ist im eigentlichen Sinne kein richtiges Backup, sondern ein Mirror, genauer gesagt, ein Snapshot bestimmter Daten auf dem AMS.

Ein einfaches, regelmäßiges 1:1 Kopieren scheint mir bei den Datenmengen vollkommen ineffizient. Es müssen also schlaue Tools her. Das sind A) robocopy und B) rsync

A) Der einfache Weg: robocopy (Windows / Datenübertragung über das Netz)

robocopy.exe ist ein Kommandozeilenprogramm von Microsoft. Es ist in Vista bereits enthalten, für XP kann man es sich als Teil der "Windows Server 2003 Resource Kit Tools" installieren. Es gibt für das Programm sogar eine GUI. Man kann also die GUI verwenden oder sich ein CMD-Batch basteln, welcher dann auf "Knopfdruck" oder aber regelmäßig, z.B. bei Starten/Herunterfahren des Rechners oder zu einer bestimmten Uhrzeit eine entsprechende Sicherung ausführt. Eine sehr einfache Batch-Datei als Beispiel:

Code: Select all

@echo off
::
:: mirror.cmd
::
robocopy "AMS150Dir_To_Save" "E:BackupAMS150Dir_To_Save" /MIR
robocopy "AMS150Another_Dir_To_Save" "E:BackupAMS150Another_Dir_To_Save" /MIR


... wobei E: ein beliebiges Laufwerk sein kann, also die Festplatte im PC oder eine externe USB-Platte, die am PC hängt. Der Vorteil im Gegensatz zum einfachen Kopieren: es wird ein genaues Abbild des Verzeichnisbaumes erstellt, wobei nur die Dateien tatsächlich kopiert werden, die sich auch verändert haben (oder neu hinzugekommen sind). Nochmal: dies ist kein richtiges Backup! Im Quellverzeichnis nicht (mehr) vorhandene Dateien werden im Zielverzeichnis gelöscht! Wer das nicht möchte, muss die Option /MIR weglassen, bei der entsprechnd Vorsicht angebracht ist.

NOTE: Read "True Replication" in Robocopy.Doc prior to first use of /MIR !
**** /MIR can DELETE files as well as copy them !

Ist schon nett so ... kleiner Nachteil allerdings: abhängig von der Netzwerkverbindung und der Datenmenge wird dies nach wie vor langsam sein, irgendwann müssen die Daten ja kopiert werden. Dass es lange dauert, wäre ja nicht weiter schlimm, wenn es solange nicht gleichzeitig auch noch den PC beschäftigen würde (auf dem robocopy ja läuft).

B) Der direkte Weg: rsync (Datenübertragung von der internen AMS-Platte auf den an den AMS angeschlossen USB-Datenträger per Backup-Knöpfchen)

Uff, es reicht erstmal. Wie ich das gemacht habe, schreibe ich später ... falls es jemanden interessieren sollte.

Viele Grüße!

[lochness]

Also, das Problem ist eindeutig reproduzierbar. Und, es hat in der Tat mit NTFS zu tun, nämlich insofern, dass die Linux Rechte der NTFS USB-Disk, wie oben beschrieben, als Readonly gesetzt sind (wohl um an allen Stellen zu verhindern, dass dort geschrieben werden kann ) und beim Copy über das Backup-Button-Script werden diese Rechte teilweise mitgenommen.

Es ist nun so, dass man von einem Windows XP PC die Attribute wirklich nicht umsetzen kann! Das geht nur von einem Vista-PC aus, auf dem XP bekomme ich die gleiche Fehlermeldung wie ihr auch. Bei Vista schaffe ich es, die Attribute umzusetzen:
Vorher:
# ls -l
-r-xr-xr-x 1 32767 32767 5454336 Jul 6 2006 DSC02468-2.ppf
Nachher:
# ls -l
-rwxr-xr-x 1 32767 32767 5454336 Jul 6 2006 DSC02468-2.ppf

Warum Vista sich über den Schreibschutz hinwegsetzt, ist mir nicht ganz klar, aber es ist recht hilfreich ... Und, warum nicht alle Ordner ihre Rechte behalten, sondern nur einige, das ist wohl ein Problem des "cp -a", das von dem Shell Script benutzt wird.

Ich habe schon alles mögliche versucht, Knoppix, Arbeiten als User "nobody", andere Kommandos, ... es funktioniert einfach nicht durchgängig. Wenn alle Ordner dem User "nobody" mit der User ID 32767 gehören würden, dann würde man es mit einer Knoppix BootCD hinbekommen.

Ich rate jetzt mal zu telnet, was anderes fällt mir heute Abend nicht mehr ein ...

[lestat1973]

also dein Problem besteht darin, dass du von einem USB-(NTFS-)Laufwerk Daten per Backup auf den AMS kopiert hast und diese nun auf der AMS-Platte nicht mehr löschen kannst? Das ist in der Tat sehr komisch und könnte was mit NTFS zu tun haben. Das muss doch auch ohne telnet-Zugang zu löschen sein ...

Genau das war mein Problem! Telnet ist der richtige Hinweis...schau paar zeilen weiter unten...
Was die Synchronisatoin angeht, die mach ich seit langem mit dem SyncToy Tool von Microsoft: http://www.microsoft.com/windowsxp/using/digitalphotography/prophoto/synctoy.mspx
Tooles Tool und in einer graphischen Oberfläche konfigurierbar...Danke jedoch für die Links. robocopy schau ich mir auf alle Fälle an.

Also, das Problem ist eindeutig reproduzierbar. Und, es hat in der Tat mit NTFS zu tun, nämlich insofern, dass die Linux Rechte der NTFS USB-Disk, wie oben beschrieben, als Readonly gesetzt sind (wohl um an allen Stellen zu verhindern, dass dort geschrieben werden kann ) und beim Copy über das Backup-Button-Script werden diese Rechte teilweise mitgenommen.

Wenigestens wäre damit die Fehlerursache eindeutig identifiziert

Es ist nun so, dass man von einem Windows XP PC die Attribute wirklich nicht umsetzen kann! Das geht nur von einem Vista-PC aus, auf dem XP bekomme ich die gleiche Fehlermeldung wie ihr auch. Bei Vista schaffe ich es, die Attribute umzusetzen:
Vorher:
# ls -l
-r-xr-xr-x 1 32767 32767 5454336 Jul 6 2006 DSC02468-2.ppf
Nachher:
# ls -l
-rwxr-xr-x 1 32767 32767 5454336 Jul 6 2006 DSC02468-2.ppf

Warum Vista sich über den Schreibschutz hinwegsetzt, ist mir nicht ganz klar, aber es ist recht hilfreich ... Und, warum nicht alle Ordner ihre Rechte behalten, sondern nur einige, das ist wohl ein Problem des "cp -a", das von dem Shell Script benutzt wird.

Sehr interessant das mit Vista. Das wäre im Moment der einziger Grund für mich umzusteigen

Ich rate jetzt mal zu telnet, was anderes fällt mir heute Abend nicht mehr ein ...

So habe ich es nun auch gemacht. Mit Deiner Hilfe habe ich telnet auf dem AMS 150 aufgespielt. Dann war es mit einem Befehl getan:
chmod 777 -R ORDNERNAME
führte dazu das alle nutzer auch Schreibrechte haben und ich dann sehr einfach den Schreibschutz von XP aus entfernen konnte.
Dateien hin und her verschoben...Ordner umbenannt...Alles hat geklappt.

Vielen, vielen DANK!

[lochness]

robocopy ist schon gut, das benutze ich hier auch, in einem Script.

Das mit Vista sehe ich als "Ausgleich", weil ich keine kleinen Dateien kopieren kann, dann geht wenigstens das ...

Ich meine, eine Lösung wäre einfach im Backup-Button-Script zu implementieren, dass die Linux-Rechte noch ein "w" bekommen.

[lestat1973]

Ich meine, eine Lösung wäre einfach im Backup-Button-Script zu implementieren, dass die Linux-Rechte noch ein "w" bekommen.

Das hört sich klasse an. Und wie ?

[lochness]

Ich dachte, FSC macht das vielleicht für uns ...
Wenn nicht, dann schaue ich mal, was geht. Im Prinzip einfach das chmod, was Du gemacht hast (oder so was ähnliches, was dann +w macht) , mit in das Script integrieren und schauen, dass das veränderte Script einen Reboot übersteht.