Hallo, ich habe ein neues MBP. Diesmal habe ich es allerdings neu aufgesetzt als die mittlerweile 10 Jahre alte Installation zu übertragen. Nun hat der Computer auch einen neuen Namen.

Mein altes Time Machine Backup war wohl verschlüsselt, jedenfalls fragt der Computer mich nun ob ich die (alte) TM Festplatte auch für neue Backups verwenden möchte. Legt aber ein neues Verzeichnis an. Auf die Daten z.b. FOTO im alten Backup kann ich aber nun nicht mehr zugreifen. Der Ordner hat ein Verbotsschild. Ich kann zwar über Informationen anzeigen die Berechtigungen ändern aber er übernimmt sie nicht.

Gibt es einen Weg noch an die alten Backup Daten zu kommen?

Danke

MEines Wissens nicht - die Daten habenja die Rechte des alten Nutzers und das ist das Problem unter OSX - der neue TM Nutzer - selbst mit Adminrechten - kann nicht auf das alte Backup zugreifen.

Deshalb hab ich TM inzwischen ganz rausgeschmissen und mache meine Backups mit CCC als reine Datei Lösung - so hab ich auch im Ernstfall immer noch Zugriff auf diese Daten.

Sorry, aber das ist völliger Unsinn.

Wenn man es richtig macht, hat jeder Nutzer auf dem neuen Mac dieselbe User-ID wie auf dem alten, dann gibt es überhaupt gar kein Problem. User-IDs sind Ziffern, die den Nutzernamen zugeordnet sind, bei macOS beginnend mit 501 und dann in aufsteigender Reihenfolge bei jedem neu angelegten Nutzer.

Wie immer bei Computern sind die Zahlen das letztlich Ausschlagebende. Wenn man auf dem neuen Mac die Nutzer in einer anderen Reihenfolge anlegt als beim alten, dann entsprechen den Nutzernamen plötzlich andere User-IDs und so bekommt man das Problem, das dynax74 offenbar plagt. Man kann die User-IDs zwar manuell ändern und somit an die der alten Installation angleichen, aber das ist eher was für Profis, denn wenn man da was falsch macht, geht am Ende gar nix mehr.

Aber natürlich kann man die Daten der Time-Machine-Festplatte für alle Nutzer lesbar machen, dann kann man auch darauf zugreifen.

Dazu einfach als Admin-Nutzer Terminal öffnen und
eingeben sowie auf Nachfrage das Admin-Passwort. Dann ist man root-Nutzer, und der kann alles.

Dann
eingeben und schon gehört der Ordner dem Nutzer nutzername und dieser kann alles in dem Ordner lesen und kopieren.

Den Pfad /Ordner/mit/Verbotsschild bekommt man übrigens am einfachsten ins Terminal, indem man den Ordner aus dem Finder dorthin zieht.

Alternativ kannst Du im Finder im Info-Fenster auch einfach einstellen, dass auf dieser Festplatte die Zugriffsberechtigungen ignoriert werden sollen. Das geht aber nur, wenn es sich dabei um eine externe Festplatte handelt und die (noch) nicht als Time-Machine-Festplatte für den neuen Mac eingestellt ist.
Mit neuem Namen und Verschlüsselung hat das nichts zu tun. Ein Time-Machine-Backup ist immer der individuellen und einzigartigen Seriennummer eines Macs zugeordnet und passt nur für diesen. Aus Sicht des neuen Mac ist auf dieser Festplatte also noch kein Time-Machine-Backup.

Davor alles richtig aber das stimmt nicht.
Gerade ebenfalls neues MBP aufgesetzt, TM-Platte dran, Backup gemacht und die Fortsetzung des alten Backups wurde erstellt. Ich kann nicht sagen woran es liegt. Daran, dass ich das alte Backup mit Passwort freigegeben habe oder daran, dass beide Rechner gleich heißen, die gleiche Seriennummer haben sie definitiv nicht.

Nö, was Weia vorher schreibt, stimmt auch nicht.

Problem 1: Seit Mac OS X 10.4 werden Benutzer nicht nur durch die UID, sondern auch durch eine User-UUID identifiziert. Diese sind weltweit einmalig und werden z.B. bei der Berechtigungsvergabe per Finder genutzt. Im allgemeinen Fall hilft es deshalb nicht, Benutzer einfach mit gleichem Namen in der gleichen Reihenfolge anzulegen.

Problem 2: Seit macOS 10.14 hat auch root kein Zugriffsrecht auf Time Machine-Daten mehr. Dem Programm, was den Zugriff haben soll (z.B. dem Terminal) muss erst eine zusätzliche Datenschutz-Genehmigung für vollen Festplattenzugriff erteilt werden.

Problem 3: Auch dann reichen die Standardzugriffsrechte von root noch nicht aus, um erfolgreich einen chown-Befehl auszuführen, denn die Datensicherung ist durch eine Zugriffssteuerungsliste, unter anderem mit dem Recht "group:everyone deny chown", zusätzlich geschützt. Man müsste erst die ACLs entfernen oder umschreiben.

Zur ursprünglichen Frage: Zwei unterschiedliche Computer sichern grundsätzlich in zwei unterschiedliche Sicherungen. Es wäre ja ziemlich gefährlich, wenn der eine Computer die Datensicherung des anderen beschädigen würde.

Einer der möglichen "normalen" Wege, Daten aus der Datensicherung des anderen Computers zu übernehmen ist der Aufruf des Migrationsassistenten mit der Option "Daten aus Time Machine-Backup übertragen".

Aha, interessant! Welche Versionen waren denn Quell- und Zielbetriebssystem? Ich habe nur Erfahrungen bis einschließlich 10.9 → 10.11, weil ich mir Migrationen auf 10.10 und 10.12/10.13 und (bislang) 10.14 geschenkt habe.

Und bis 10.9 → 10.11 war es bei mir definitiv so, in vielen verschieben Einzelfällen.

Bei mir (weitgehend) schon …

Aber wie im vorangegangenen Beitrag schon beschrieben: Erfahrungen basieren auf 10.0 bis einschließlich 10.11, da ich nicht jeden Versionssprung auf meinen Hauptrechnern (deren Inhalt ich migriere) mitmache.
Ja, das stimmt, aber …
… das kann ich nicht bestätigen. Solange die UID identisch war, war dem Finder die User-UUID bei mir stets vollkommen schnuppe. Das ist eine Erfahrung mit zahlreichen neu nach diesem Verfahren aufgesetzten Rechnern; es gab niemals Probleme.

Woher sollte der Finder die User-UUID, mit der eine Datei angelegt wurde, überhaupt kennen? Die wird, so weit ich sehen kann, im Gegensatz zur User-ID nirgendwo in den Metadaten jeder einzelnen Datei gespeichert.
Gerade eben auf einem 10.14-Testsystem getestet, kann ich auch nicht bestätigen. root kann auf der Time-Machine-Festplatte machen, was er will. (Allerdings ohne System Integrity Protection, die schalte ich so routinemäßig als allererstes bei einem neuen Rechner aus, dass ich vergessen habe, das zu erwähnen.)
Und welcher Prozess sollte die erteilen? Was root nicht kann, kann gar kein Prozess …
Da hast Du Recht. Da ich das Problem mit den unterschiedlichen User-IDs selbst nie hatte, habe ich das übersehen.
Wieso sollte er die beschädigen? Die Daten auf der Festplatte des neuen, geklonten Computers sind aus Sicht von Time Machine doch lediglich eine Menge auf einmal veränderter Dateien, und diese Änderungen werden ja alle gespeichert.

So, wie es jetzt ist, gehen bei einem Wechsel auf neue Hardware sämtliche Versionen einzelner Dateien und Ordner vor dem Wechsel verloren; das finde ich weit problematischer.
Mit dem Migrationsassistenten hatte ich leider zeitlebens immer nur Ärger, der hat nie wirklich alles migriert. Und ein Klon, der kein perfekter Klon ist, ist ein ziemliches Problem …

Was spricht aus Deiner Sicht dagegen, die Zugriffsrechte der externen Time-Machine-Festplatte einfach ignorieren zu lassen, solange es nur darum geht, an einzelne Dateien zu gelangen?

Vom Anlegen einer Datei war überhaupt nicht die Rede, sondern vom allgemeinen Fall mit einer nachträglichen Rechtevergabe zugunsten eines Benutzers durch den Finder. Alle modernen Versionen des Finders verwenden dazu Zugriffssteuerungslisten, in denen nur User-UUIDs gespeichert werden.

Der Prozess sandboxd erteilt die programmbezogenen (nicht prozessbezogenen) Rechte.

Das ist ja gerade der Sinn der Sache. Der Migrationsassistent klont eben nicht, sondern passt die Daten an ein anderes Betriebssystem an.

Das System klonen kann man mit dem Festplattendienstprogramm. Und die "wichtigen" Daten des Systems, inklusive der Benutzer-Accounts und aller Rechte, kann man mit einer Time Machine-Vollwiederherstellung zurückladen.

Mit normalen Mitteln lässt das System das bei einer Time-Machine-Platte nicht zu.

Nö, nicht durch den Finder. Mit chown im Terminal, das war mein Vorschlag. Und wenn ich
eingebe, dann kann neuerNutzer die Datei auch im Finder lesen und schreiben, User-UUID hin oder her.

Im übrigen war Deine These allgemeiner; Du meintest, wenn die User-IDs auf einem neu angelegten System identisch sind mit denen des alten Systems, hieße das noch lange nicht, dass der Finder die geklonten Dateien auf dem neuen System würde problemlos lesen können. Und das stimmt eben nicht, das kann der Finder dann sehr wohl. Denn selbst wenn er sich sperren wollen würde, müsste er dafür eben wissen, dass die Dateien ursprünglich mit einer anderen User-UUID angelegt wurden. Und das kann er nicht, da nur die User-ID in den Metadaten der Datei gespeichert wird und daher einzig ausschlaggebend ist.
Ist die Shell in 10.14 sandboxed? (Hab noch nicht und kann gerade nicht gucken.) Das wäre ja völlig absurd.
Hmhm. Und beschließt dabei eigenmächtig, welche meiner Anpassungen des Betriebssystems es würdig sind, übernommen zu werden, und welche nicht, und macht dabei auch noch etliche Fehler, so dass nach einer Migration vieles nicht mehr funktioniert, was vorher funktionierte. Nein danke.
Aber niemand zwingt Dich, dem System zu sagen, dass das überhaupt eine Time-Machine-Festplatte sein soll? Das System fragt ja eben beim ersten Anstöpseln, ob es diese Platte als Time-Machine-Platte verwenden soll. Du musst nur Nein sagen.

Um deinen Vorschlag geht es überhaupt nicht. Lies nochmal den obigen Beitrag und versuche ihn zu verstehen.

Nein, das habe ich nicht gesagt. Ich habe gesagt, dass im allgemeinen Fall nicht gewährleistet ist, dass irgendein Prozess, den dieser Benutzer gestartet hat, die gleichen Dateien lesen kann, wie im alten Betriebssystem. Dieser Benutzer hat andere Rechte (möglicherweise gar keine) für Dateien, der er nicht selbst angelegt hat, aber für die ihm per Finder nachträglich Rechte erteilt wurden.

Das ist falsch, da der Finder bei einer nachträglichen Rechte-Änderung nur User-UUIDs verwendet und keine UIDs.

Alles in macOS 10.14 ist sandboxed. Das ändert sich nur, wenn man den Systemintegritätsschutz abschaltet.

Nein, macOS erkennt Time Machine-Platten immer, egal ob man sie an diesem System als Time Machine-Zielmedium nutzen will, oder nicht.

Hä?

Unser Dialog begann damit, dass ich einen (User-IDs einbeziehenden) Vorschlag gemacht habe, wie das Problem von dynax74 zu lösen sei, und Du darauf schriebst, das sei alles falsch. Das war der Ausgangspunkt. Also geht es natürlich um meinen Vorschlag.
Ich lese immer alle Beiträge gründlich und versuche, sie zu verstehen. Was genau willst Du mir mit dieser altväterlichen Aufforderung sagen?

Du hattest gefragt, in welchen Fällen macOS die User-UUID und nicht die UID beim Zugriff auf Dateien auswertet. Das hatte ich beantwortet. Einer dieser Fälle ist der Zugriff auf Dateien, bei denen eine nachträgliche Rechtevergabe über den Finder für Benutzer stattgefunden hat, die nicht Eigentümer der Dateien sind.

Diese Antwort hatte nichts damit zu tun, welchen Vorschlag Du machst, um in einer Time-Machine-Sicherung die Datei-Eigentümer zu ändern.

Ich wüsste nicht, wo ich das gefragt haben sollte.

Meine Punkte waren vielmehr:

• Wenn Dateien einer alten Installation durch 1:1-Kopie („Klonen“) übernommen werden und die User-IDs der alten Installation mit der der neuen Installation identisch sind (gleiche Reihenfolge beim Anlegen der Nutzer), dann können der Finder und andere Programme Dateien von dem jeweiligen Nutzer immer lesen, völlig unabhängig von den User-UUIDs, mit denen diese Dateien ursprünglich erstellt wurden. (Du hattest das bestritten.)
• Und das – so die Thesen – kann auch gar nicht anders sein, da die ursprünglichen User-UUIDs nicht in den Metadaten der geklonten Dateien gespeichert sind und die neue Installation also gar keine Kenntnis davon hat, mit welchen User-UUIDs diese Dateien angelegt wurden und sich folglich auf die User-IDs verlassen muss.
• Selbst wenn diese These nicht stimmen sollte, so funktioniert empirisch jedenfalls das Klonen und der anschließende Zugriff auf die Dateien immer, solange die User-IDs identisch sind. Viele viele Male ohne Probleme so gemacht, allerdings – wie gesagt – bislang nur bis einschließlich 10.11.
• Und ein nachträgliches chown neuerNutzer Datei führt empirisch ebenfalls immer zum gewünschten Resultat, User-UUID hin oder her. Von einer „nachträglichen Änderung der Zugriffsrechte im Finder“ habe ich nie gesprochen.

Indirekt im Beitrag 24.10.18 13:20, indem Du fragst, woher der Finder an User-UUIDs zu einer Datei kommt.

Ja, das bestreite ich immer noch, weil es im allgemeinen Fall nicht stimmt.

Doch, es werden beliebig viele UUIDs in den Metadaten gespeichert, und zwar für alle Benutzer und Gruppen, die nicht der Eigentümer der Datei sind, für die per Finder aber ein Zugriffsrecht definiert wurde.

Aber ich, weil das die häufigste Ursache ist, wie eine Datei zu UUIDs in ihren Metadaten kommt.

Das ist erstens eine sehr andere Frage und zweitens war das eine rhetorische Frage, sprich, ein Reformulierung meiner These, dass der Finder eben nicht an diese Daten kommt.
Dieser „allgemeine Fall“ ist mir in zahllosen Installationen über zwei Jahrzehnte nur noch nie begegnet …
Ja, sobald ACLs ins Spiel kommen, stimmt das natürlich, nur ist das doch der absolute Ausnahmefall. Ich weiß nicht, warum Du immer wieder mit Dateien ankommst, deren Nutzerrechte im Finder mal verändert wurden. Wann kommt das jemals vor? Ich habe im Zusammenhang mit der jetzigen Diskussion jedenfalls nirgendwo davon gesprochen, dass man Zugriffsrechte im Finder verändern sollte.
Aha! OK, dann ist das also der Kern des Problems – das hättest Du vielleicht klarer formulieren sollen, dass Du davon nicht sprichst, weil Du mir unterstellst, ich hätte irgendwo in meinem Vorschlag davon geredet, sondern diesen Gesichtspunkt selbst zusätzlich einführst, weil Du da ein potentielles Problem siehst. Ich kenne wirklich niemanden, der den Finder zu einer Änderung der Nutzerrechte verwendet, schon allein aufgrund der grausamen GUI dafür, und dann eben auch aufgrund der oft völlig verkorksten Ergebnisse, wo statt einer genauso gut funktionierenden Änderung der Unix-Zugriffsrechte völlig unnötigerweise wilde ACL-Konstruktionen bemüht werden.

In Kurzform: Laien verändern die Zugriffsrechte in Finder nicht, weil sie gar nicht genau wissen, was das ist, und Profis verändern sie im Finder nicht, weil sie wissen, was für einen Mist der Finder da oft baut. Meiner Erfahrung nach ist bezüglich selbst angelegter Dateien die Quote von Dateien mit ACLs zu selbstangelegten Dateien insgesamt kleiner als 1:10.000.

Altes MBP mit 10.13, letzte Version, geschrotet durch das letzte Firmwareupdate, neues MBP ebenfalls 10.13 beim hochfahren, aber gleich Update auf 10.14 vorgenommen.

Bei mir war es aber definitiv ein neu aufgesetztes MBP, was die erste Datensicherung in den Ordner des alten MBP gemacht hat. Migrationsassistent war nicht im Spiel. Es kann also nur derselbe Name oder die Freigabe der verschlüsselten TM-Platte oder dieselbe Apple-ID oder irgendeine Kombination daraus verantwortlich sein.

Mal wieder zurück zum ursprünglichen Thema..

Hast du mal probiert mit der ALT-Taste beim Starten von TimeMachine auf das alte Backup zuzugreifen und die Dateien die benötigt werden auf den aktuellen Rechner zu kopieren ?
Mit der ALT- Taste sollte fogendes kommen:

Hallo Zusammen und vielen Dank! Ich habe tatsächlich über den Migrationsassistenten die Photo Bibliothek importieren können, allerdings unter dem alten Benutzer. Dann habe ich die Fotos auf eine Festplatte exportiert. Dann den Account gewechselt und den User und den Userordner wieder gelöscht. Hat alles auch fast geklappt. Jetzt habe ich noch diesen Rest im Papierkorb der sich nicht löschen lässt. (Siehe Bild) Wie bekomme ich das noch weg?

Danke

Auch die Festplatte sieht aktuell komisch aus.