Hallo

Das 10.6.4 Update hat mir ein TM Volume korrumpiert. Es erscheint als locked, ich finde aber keine Möglichkeit, es zu entsperren. Im Finder, mit Disk Utility oder mit DiskWarrior geht es nicht. Ich vermute, es gibt ein shell command, weiss es aber nicht.

Direkt nach dem 10.6.4-Update wurde fsck angestossen, mit ständig 90 % CPU-Last im Activity Monitor deutlich zu sehen. Nach Stunden musste ich das aber mal beenden. Danach war das TM Volume locked (das sparseimage selbst ist nicht locked). Also war fsck vermutlich gerade mit dem TM Volume beschäftigt, was ich aber mangels Output nicht erkennen konnte.

Beim 10.6.1 Update war genau das gleiche passiert, nur war damals das Volume nicht locked. Mit DiskWarrior habe ich das damals in Ordnung gebracht. Das geht jetzt aber nicht, weil das blöde Volume locked ist und ich keinen Ansatzpunkt finde, wie ich es entsperren kann.

Der Get info Dialog des Finders sagt zu diesem Volume bei meinen Rechten "read & write", lässt aber keinen Zugriff zu, ganz im Gegenteil zu einem anderen TM Volume eines anderen Rechners, wo alles normal ist.

Neustarts und Repairs des sparseimages im FDP habe ich mehrfach durchgeführt.

Danke für Tipps!
Andreas

Wenn keine wichtige Daten drauf sind:
Volume Löschen und Sicherung neu anlegen...

Wenn keine wichtige Daten drauf sind:
Volume Löschen und Sicherung neu anlegen...

Nein, das ist weder der Sinn von TM noch kann ich jetzt sagen, welche Daten der letzten 2 1/2 Jahre wichtig sein könnten.

Vielleicht hilft im Terminal

chflags nouchg <volumePathOfExtDrive> retourniert nichts, das Kommando lief also durch.

chflags nouchg <TMVolumePath> retourniert "chflags: /Volumes/Backup of MacBookAir1,1: Read-only file system", wobei es sich wahrscheinlich um eine falsche Fehlermeldung wegen des defekten TM Volumes des MacBookAir handelt, weil Rechte und Personen des MacBookAir Volumes völlig identisch sind mit denen des funktionierenden TM Volumes meines PowerBooks.

Weder "locked", noch "read only" hat irgendetwas mit Rechten oder einem Defekt der Platte zu tun. Und warum sprichst Du von einem "sparsebundle"? Handelt es sich gar nicht um eine Festplatte?

"Korrumpiert" wurde auch nichts. Es ist normal, dass der oberste Ordner einer Platte mit dem Attribut "geschützt" versehen wird, wenn man eine wichtige Operation abbricht.

Wenn es tatsächlich um eine Festplatte geht, dann hat der erste Befehl den Lock erfolgreich entfernt und die Platte ist wieder beschreibbar.

Ev. hilft

mount -uw "/Volumes/Backup of MacBookAir1,1"

und dann

chflags nouchg "/Volumes/Backup of MacBookAir1,1"



If you do not show full output i doubt we can help.

Da erhalte ich immer eine Fehlermeldung "unknown special file or file system /Volumes/teorema67tc/Backup of MacBookAir1,1." Ich hab's mit diverser Syntax probiert, auch den Namen der sparsbundles eingesetzt. Das andere - funktionierende - Backup wird mit mount ebenfalls nicht gemountet. Kann es sein, dass sparsebundles von mount nicht angesprochen werden?

Zeig mal ein

ls -l /Volumes

Das ist jetzt zwar nicht konstruktiv, aber wichtige Daten wuerde ich jetzt nie einem derart stuemperhaften Backupsystem wie Timemachine anvertrauen, zumindest nicht ohne gelegentlich anderweitig Backups anzufertigen...

Auf forums.macosxhints sieht man


drwxr-xr-x+ 3 root staff - 102 8 Nov 2009 Backups.backupdb -- defekt

drwxr-xr-x+ 3 spxxxx staff - 102 8 Nov 2009 Backups.backupdb -- i.O.


und mE ist da der Hund begraben.

Du solltest recht haben:

rwxr-xr-x+ 3 root staff - 102 8 Nov 2009 Backups.backupdb (das defekte Volume)

drwxr-xr-x+ 3 spxxxx staff - 102 8 Nov 2009 Backups.backupdb (das funktionierende)

Ich werde das mal ändern, chown ...

... geht leider auch nicht:

Andreas-AirBook:Backup of MacBookAir1,1 spxxxx$ sudo chown spxxxx Backups.backupdb
Password:
chown: Backups.backupdb: Read-only file system

someone: Ich habe keinen einen Datenverlust und habe eine weitere Sicherung. Ich möchte einfach nur das defekte sparseimage repariert bekommen

Wenn Du keine Ahnung hast lass es lieber. Wenn die Festplatte nicht HFS formatiert ist wird von Time Machine ein Sparseimage angelegt um die vorhandenen Rechte korrekt zu sichern. Das trifft beispielsweise auf ein TimeCapsule-Laufwerk zu. So wird ein mitwachsen des Images bei einer größeren Festplatte abgesichert.

Hmm, manchmal gehe ich an Sachen ganz einfach heran...

wenn ich die bisherigen Informationen richtig einordne..

handelt es sich um ein .sparsebundle, da Du auf ein Netzwerkvolumen sicherst.. (TC ist ein Netzwerkvolumen...)

Die o.g. Rechteangaben bwziehen sich aber auf den "im .sparsebundle" liegenden Ordner, "Backups.backupdb".

Eine Rechtekorrektur dieses Ordners funktioniert nicht, da es als "read-only-Dateisystem" ausgegeben wird.

Welche Rechte hast Du denn in der Obersten Ordnerebene, eben dem .sparsebundle..?

Vielleicht solltest Du hier die Rechte nochmal kontrollieren, denn da müsstest Du ja die Rechte setzen können.

Eventl. hast Du das alles schon gemacht, jedoch habe ich dies aus den bisherigen Einträgen nicht herausgelesen...

Rene

Ah, wieder mal besserwissen, ohne das Problem auch nur ansatzweise verstanden zu haben?

teorema67:
Warum müssen wir erst aus einem anderen Forum erfahren, dass es hier um einen Netzwerkzugriff auf eine Time Capsule geht? In dem Fall ist die Herangehensweise komplett anders.

Zeig mal die Ausgabe des Befehls
sowie von

während sowohl die Time Capsule als auch das gelockte sparsebundle gemountet sind.

Hier hats ls -alOe

Marcel Bresink: Wenn mir ein Tool (fsck) ein Volume unbrauchbar macht, dann nenne ich das Volume "beschädigt" oder "korrumpiert".

Ob das eine TC ist oder nicht, ist völlig egal. In meinem Fall ist es eine Platte an APExtreme, das macht keinen Unterschied zur TC. Im anderen Forum habe ich an einer Stelle zur Vereinfachtung TC gesagt.

Der Output zu mount steht oben: "unknown special file or file system /Volumes/teorema67tc/Backup of MacBookAir1,1."

Output von xattr: No such file: /Volumes/teorema67tc/Backup of MacBookAir1,1

Das Problem ist, dass Backup of MacBookAir1,1 als read-only file system figuriert, das andere (Backup of PowerBook5,8) dagegen ist read & write. Daran scheitert jede Intervention am Backup of MacBookAir1,1. Den Fehler vermute ich im sparsebundle,

... die betreibe ich manchmal als Netzwerkvolume und manchmal am USB, hat bisher auch keinen Unterschied gemacht.

rene204: Rechte auf der obersten Ebene sind

drwxrwxrwx@ 7 spywea staff - 264 17 Jun 22:02 MacBookAir1,1_001ec2b6fbd5.sparsebundle
drwxrwxrwx@ 6 spywea staff - 264 19 Jun 14:34 PowerBook5,8_001451223768.sparsebundle

Das zweite TM Volume arbeitet korrekt, das erste ist read-only.

Nur mal ganz ins Blaue gefragt an die Mitlesenden mit Ahnung: Könnte es sein, dass mal irgendein Netzwerkzugriff auf die nicht lesbare (virtuelle) Platte nicht ordentlich beendet wurde und aus Sicherheitsgründen der Schreibzugriff verboten ist, damit nicht zwei Geräte scheinbar gleichzeitig zu schreiben versuchen?
Wäre es nicht ein Einfaches, die Datei zu duplizieren und dann mal zu testen, ob das Duplikat nicht wieder problemlos läuft? Lesbar heißt ja auch kopierbar…

unsupported destination discussions.apple.com

eyespy39: daran habe ich mich noch nicht gemacht, weil ich befürchte, dass TM das sparsebundle dann nicht mehr erkennt - denn TM funktionier mit diesem Backup, ich kann nur keine neuen dazuschreiben.

Lies Dir mal den Artikel durch. Ein Punkr behandelt den Fall Read only von TimeMachine Volumes.



Drag the sparsebundle to the Disk Utility sidebar.
Select the sparsebundle, then click Repair.

_mäuschen: Erst mal danke für die Hilfe und die Tipps oben!

Die fragliche Platte stammt aus einer verstorbenen TC. Das dürfte der Grund sein, dass sie via Netzwerk als TM-Platte funktioniert. Ob der aktuelle Defekt damit zu tun hat, dass sie nicht mehr in einer TC werkelt, kann ich leider nicht überprüfen.

Da hast Du wohl nichts verstanden.

Danke für den Hinweis, aber, wie im Eingangspost geschrieben, ändert Repair im FDP nicht. Die Reparatur läuft durch und das sparsebundle ist danach immer noch read only.

eyespy39

Netzwerkzugriff; da ist was dran.

Weil


Sie können Time Machine mit einer Time Capsule und mit USB- und FireWire-Volumes verwenden
…
Für die Datensicherung mit Time Machine kann keine externe Festplatte verwendet werden, die mit einer AirPort Extreme-Basisstation verbunden ist
http://docs.info.apple.com/

Gefunden hier http://discussions.apple.com


und weiter gehts hier:

Using Time Machine with a USB drive connected to an Airport Extreme
http://discussions.apple.com

Ja, mir ist bekannt, dass Apple das immer propagiert hat. Es ging bisher aber problemlos - zumindest mit bestimmten Festplattentypen, darunter die, die in der TC verbaut sind.

Oder sollte mir da ein schlimmer Verdacht kommen, dass Apple dies mit 10.6.4 sabotiert hat?

Wobei ... da fällt mir ein ... hier steht eine unausgepackte TC 1GB, die ich für meine am Hitzetod verstorbene erhalten habe (aber erst 3 Monate später, deshalb habe ich die APExtreme gekauft) ... sollte ich da mal die sparsebundles rüberschaufeln und die neue TC bis zum nächsten Hitzetod verwenden?

Das Volume ist funktionsfähig, aber read-only gemountet. Der Read-Only-Zustand wurde nach Deinen Angaben nicht durch fsck_hfs, sondern durch ein Abbrechen einer laufenden Schreiboperation (während fsck_hfs lief) verursacht. Das ist ein so vorgesehener Schutzmechanismus und keine Beschädigung.

Nein, ist es nicht, denn hier finden zwei ineinander verschachtelte Mount-Vorgänge statt und der oberste Mount-Vorgang bezieht sich auf ein AFPFS-Dateisystem, das nicht den gleichen Funktionsumfang unterstützt, wie ein reiner HFS-Mount auf einer direkt angeschlossenen Festplatte.

Nein, das ist die Ausgabe von "mount -uw". Ich hatte nach der Ausgabe von
gefragt.

Wie ausdrücklich erwähnt, solltest Du diesen Befehl eingeben, während das gelockte sparsebundle gemountet ist.

Um die Sache abzukürzen: Unmounte das sparsebundle und versuche, über folgende Befehle den Plattencheck zum Abschluss zu bringen. Das kann sehr lange dauern:


ACHTUNG: Das sind vier Befehle, die als vier Zeilen eingeben werden müssen. Bitte den Browser so breit ziehen, dass das auch als vier Zeilen angezeigt wird.

VORAB in den Systemeinstellungen TM ausschalten!

Marcel Bresink: Auch dir est mal vielen Dank für die Hilfe!
Nun ja, bliebe zu diskutieren, ob der Schutzmechanismus, für den es anscheinend mit vernünftigem Aufwand kein Zurücksetzen gibt, nicht einer Beschädigung entspricht.
Das völlig egal bezog sich auf TC versus Platte an APExtreme, nicht versus USB.

Das Ergebnis von mount (die Platte hängt an der APExtreme):
Andreas-AirBook:~ spxxxx$ mount
/dev/disk0s2 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
afp_0V1wtE1xAKjh00nqqT0Pyetl-1.2d000005 on /Volumes/teorema67tc (afpfs, nodev, nosuid, mounted by spxxxx)
/dev/disk1 on /Volumes/Backup of PowerBook5,8 (hfs, local, nodev, nosuid, journaled, noowners, mounted by spxxxx)
/dev/disk2s2 on /Volumes/Backup of MacBookAir1,1 (hfs, local, nodev, nosuid, read-only, mounted by spxxxx)
Andreas-AirBook:~ spxxxx$
Genau so hatte ich es gemacht, das ist der Output mit gemountetem sparsebundle. Was mich wieder eher an "Beschädigung" denken lässt

Und das Ergebnis von hdiutil:
hdiutil: attach failed - No such file or directory

Ich denke, ich gebe auf und fange mit einer neuen Sicherung an. Die alten Backups sind ja zumindest noch lesbar, nur leider fliegen sie aus der neckischen TM-Animation raus, wenn ich eine neue Sicherung beginne.

Den Transfer auf die nagelneue TimeCapsule habe ich verworfen: Wenn ich die alte Festplatte an USB und die neue TC ans Ethernetkabel hänge, dauert das Kopieren der vorhandenen 375GB stolze 25 Stunden, so was ist unbrauchbar.

Da wurde entweder der Befehl falsch eingegeben (er reicht bis ">/tmp/Mount.txt") oder Du hast auch den äußeren Mount deaktiviert. Der Mount des AFP-Dateisystems muss online bleiben. Der innere Mount des sparsebundle darf nicht aktiv sein.

Marcel Bresink: Ich habe den Befehl komplett bis zur Zeilenschaltung eingegeben, mit deaktiviertem äusserem Mount sowie mit aktiviertem, dann noch mal beide Möglichkeiten mit dem funktionierenden Backup vom PowerBook, und als Output habe ich in allen 4 Fällen "attach failed..." erhalten. Mich macht auch der man-Hinweis stutzig "attach will fail if no filesystems mount", aber ich bin kein Experte in solchen Operationen.

Diese Befehle, wenn ich sie richtig interpretiere, machen via Terminal das, was im von Snowleopard_09 zitierten Apple Support Dokument http://support.apple.com/kb/ht3275#1 auch empfohlen wird, oder? Das war das allererste, was ich nach Feststellen des read only Problems versucht habe, und da hat es schon nicht funktioniert.

Die Macwelt (ich weiß leider die Ausgabe nicht mehr) hatte mal untersucht, warum TM nicht zuverlässig mit diversen NAS zusammenarbeitet. Sinngemäss:

Die Versionen des Netzwerkprotokolls sollen leicht unterschiedlich sein (Funktionsumfang). Am Anfang funktioniert das Backup scheinbar problemlos (wie bei Dir), dann treten Fehler auf, irgendwann ist das Backup dann unbrauchbar!

Ich will Dich nicht deprimieren, aber ich vermute, dass das hier der Fall ist. Wäre schön, wenn jemand das Gegenteil beweisen könnte!

X-Jo: Na ja, es funktionierte vorher, es funktioniert jetzt beim AirBook mit dem neu begonnen sparsebundle, beim Backup des PowerBooks hat es keinen Unterbruch gegeben, die aktuelle Fehlfunktion kam eindeutig vom fsck nach dem 10.6.4 Upgrade, die Platte ist eine TC-Platte, und als sie noch in der TC war, hat die mir im Juni 2008 schon mal einen Fehler mit Unmöglichkeit der Backupinkrementierung produziert.

Hab den Macweltartikel gefunden:
[quoteMacwelt]Problematisch an dieser Lösung ist, dass Time Machine spezielle Befehle im AFP-Protokoll voraussetzt, die nötig sind, um sicherzustellen, dass die Dateien wirklich auf der Festplatte des NAS gespeichert sind. Diese Befehle sind neu (nicht Teil von "AFP 3.2") und wenig dokumentiert. Mit dem oben erwähnten Terminal-Befehl kann man Time Machine zu einer Datensicherung überreden, auch wenn die NAS-Festplatte diese AFP-Befehle nicht versteht. Ohne diese AFP-Befehle erhält Time Machine aber keine verlässlichen Informationen, ob eine Datei nur im Zwischenspeicher (Cache) der NAS-Festplatte gespeichert ist. In der Regel sind solche Backups deshalb nach einigen Wochen oder Monaten unbrauchbar. Typische Anzeichen dafür sind Fehlermeldungen, dass Time Machine das Backup-Volume nicht mehr erkennt oder nicht mehr öffnen kann. Manchmal meldet Time Machine statt dessen, dass der verfügbare Platz auf dem Backup-Volume nicht mehr ausreicht, obwohl dort mehrere GB frei sind. Reparieren lässt sich das Backup-Volume in einer solchen Situation nur sehr selten, meistens sind dann alle gesicherten Daten verloren.[/quote]

Quelle und ganzer Artikel:

Dann nehme ich an, die TC heißt in Wirklichkeit nicht teorema67tc, sondern anders und der echte Name enthält ein Leer- oder Sonderzeichen. Falls das so ist, muss der ganze /Volumes-Pfad in Anführungszeichen gesetzt werden.

X-Jo: Ich habe die Platte ja nicht freiwillig aus der TC genommen, sondern weil die den programmierten Hitzetod erlitten hat und Apple bei TCs nur Reparatur durch Austausch vornimmt (sehr witzig bei einem Datensicherungsgerät).

Macwelt müsste jetzt noch nachermitteln, ob das auch auf eine Platte aus einer TC an einer APExtreme zutrifft. Die ganzen gelisteten Symptome treffen auf mein Problem nicht zu, das Backup wird erkannt, ist lesbar (aber nicht beschreibbar), der Fehler ist nicht spontan aufgetreten und war in der Vergangenheit ein Mal reparierbar, als nach einem OS-Update schon einmal fsck stundenlang zu röteln begann, und einmal im Juni 2008 nicht reparierbar, als die Platte noch in der TC sass.

Marcel Bresink: Doch, der Name ist korrekt, es kommen keine Leer- oder Sonderzeichen vor.

Also hier sind doch ganz eindeutig Leerschläge im Namen

Andreas-AirBook:~ spxxxx$ mount
/dev/disk0s2 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
afp_0V1wtE1xAKjh00nqqT0Pyetl-1.2d000005 on /Volumes/teorema67tc (afpfs, nodev, nosuid, mounted by spxxxx)

/dev/disk1 on /Volumes/Backup of PowerBook5,8 (hfs, local, nodev, nosuid, journaled, noowners, mounted by spxxxx)

/dev/disk2s2 on /Volumes/Backup of MacBookAir1,1 (hfs, local, nodev, nosuid, read-only, mounted by spxxxx)






Und hier, im anderen Forum hast die spaces gar escaped

Andreas-AirBook:teorema67tc spxxxx$ cd /Volumes/Backup\ of\ MacBookAir1,1

Oh, sorry. Der bundles Name war gefragt.


Ich geh wieder schlafen.

Hi, schau Dir mal diesen Artikel an. Alles jedoch ohne Gewähr.

Snowleopard_09: Zu meinem Problem gibt's doch ein paar Unterschiede, mein Backup Volume wurde als
(hfs, local, nodev, nosuid, read-only, mounted by spxxxx)
ausgewiesen, das des Verfassers des Artikels als
(hfs, local, nodev, nosuid, journaled, mounted by admin)

Allerdings habe ich chown nach meiner Erinnerung (siehe oben) nicht auf das Volume selbst probiert, sondern nur auf Backups.backupdb, wobei das Volume bei mir ja nicht mir root, sondern mit mit meinem Username erschien.

... beim Verfasser des Artikels waren die Attribute beim funktionierenden und beim read-only Volume identisch, bei mir eindeutig nicht.