Catalina: Problem mit Zugriffsrechen im Benutzerordner

thulium

Aktives Mitglied
Thread Starter
Dabei seit
12.11.2011
Beiträge
3.568
Reaktionspunkte
370
Moin.

Auf der aktuellsten Version von Catalina hat eine Benutzerin den OneDrive-Client von MS installiert.
Dieser legt im Benutzerordner einen Ordner an "OneDrive ..."

Dorthin hat sie einen Ordner "foo" mit Office-Dokumenten kopiert.

Wegen diverser Probleme mit der Synchronisation hat sie OneDrive wieder deinstalliert und wollte "foo" löschen.

Es erschien eine Aufforderung zur Eingabe ihres Adminpasswortes.
Nach der Eingabe erscheint die Meldung "konnte nicht abgeschlossen werden ... da Ihnen für einige Objekte die Zugriffsrechte fehlen".

Eine Recherche liefert:
https://communities.apple.com/de/thread/250820538
Der Thread mit der Lösung soll sein: https://support.apple.com/de-de/HT203538

Der Links ist jedoch tot.

Wen ich es richtig verstehe, müssen "Zugriffsrechte repariert werden".

Laut Heise ist das ohne Neuinstallation nicht mehr möglich.
https://www.heise.de/mac-and-i/meld...fiehlt-Neuinstallation-von-macOS-4694225.html

Gibt es doch einen Weg, den Ordner zu löschen?

Danke.
 
Ich vermute, dass hier einige ACL im Wege stehe. Damit das nicht nur herum rätseln ist, wäre interessant, was in Terminal.app die Ausgabe von
Code:
ls -le foo

ergibt. Du kannst aber auch mal probieren, alle ACL zu löschen mit
Code:
sudo chmod -RN foo
 
@lisanet
Vielen Dank.
Sobald ich wieder an dem Rechner sein werde, berichte ich.

Nur um sicher zu gehen: der genannte Terminalbefehl erfasst auch alle Dateien und Unterordner innerhalb "foo"?

Aus Neugier:
Hat jemand schon eine Vermutung, wie so ein Effekt durch den OneDrive-Client ausgelöst werden konnte?
 
Moin.

Auf der aktuellsten Version von Catalina hat eine Benutzerin den OneDrive-Client von MS installiert.
Dieser legt im Benutzerordner einen Ordner an "OneDrive ..."

Laut der "neuen Anleitung" (für die es auch keinen Link mehr gibt der Funktioniert) muss man seinen Mac in den Recovery-Modus bringen.
Nach der Anmeldung öffnet man das Dienstprogramm "Terminal". Dazu gibt man „repairHomePermissions“ im Terminal ein und drückt Enter.
Da startet ein Tool namens Repair Home. Über dieses Tool wählt man nun seinen Benutzerordner aus und kann ihn reparieren – bzw. setzt die Benutzerrechte zurück.

Danach den Mac wieder normal neu starten.

Das ging zumindest bis 10.14.4 so. Ob es mit dem aktuellen Catalina noch geht kann ich nicht beantworten.
Die Support-Links sind sicher weg da sie da gerade selbst nicht wissen was sie da machen.

Der alternative Vorschlag von Apple ist "macOS neu installieren".



Hauptsache man kann den Nutzern auf die Nüsse gehen wo es nur geht.
 
Nur um sicher zu gehen: der genannte Terminalbefehl erfasst auch alle Dateien und Unterordner innerhalb "foo"?
Yep. Das ist das mit dem "R". Siehe im Terminal: man chmod
Hat jemand schon eine Vermutung, wie so ein Effekt durch den OneDrive-Client ausgelöst werden konnte?
ACL zu setzen kann schon unter Umständen für ein Sync-tool nützlich sein. OneDrive unterstützt ja auch sowas wie "Dateien bei Bedarf". Da sind dann zwar Dateien im Finder sichtbar, aber nur als Verweis und werden erst beim tatsächliche Verwedne herunter geladen. Dabei ließen sich meines Erachtens ACL ganz gut einsetzen um sicherzustellen, dass diese "Phantom-Datei" nicht einfach gelöscht wird.

Wenn man dann beim eigentlichen Sync-Vorgang Probleme kriegt - warum auch immer - und dann vor Frust abbricht, OneDrive einfach killt oder es nicht korrekt deinstalliert sondern nur löscht ohne den Sync vorher zu beenden, kann es schon passieren, dass diese Phantom-Dateien oder Dateien die gerade im Sync waren halt noch vorhanden sind.

Wie gesagt, ist jetzt meine Vermutung. Wenn ich mal Lust und Zeit habe werde ich OneDrive mal dahingehend ansehen.
 
Hauptsache man kann den Nutzern auf die Nüsse gehen wo es nur geht.
Hauptsache man kann einfach nur mal meckern, ohne das Problem anzugehen (was mit einfachsten Bordmitteln geht) weil offensichtlich etwas Verständnis fehlt.
 
@lisanet
Vielen Dank für die Schilderung.
In der Tat gab es Problem beim Synchronisieren und wir haben den OneDriveClient daher deinstalliert.

Am Rande:
Vom MS-Support wurde mir mitgeteilt, dass beim "In den Papierkorb verschieben" des Clients Einstellungen und Einträge im Schlüsselbund nicht gelöscht würden und es dafür auch keine automatisierten Prozesse gäbe.
Da staune ich etwas, dass Apple nicht von Softwareentwicklern verlangt, zwingend einen Prozess zum "restlosen Löschen" anzubieten.
 
Hauptsache man kann einfach nur mal meckern, ohne das Problem anzugehen (was mit einfachsten Bordmitteln geht) weil offensichtlich etwas Verständnis fehlt.

42 - Vermutungen anstellen und nicht lesen können. Perfekt!
 
Gerade lese ich auf
https://www.heise.de/ratgeber/Tipp-....red.mac-and-i.mac-and-i.atom.beitrag.beitrag
einen Beitrag, der sich ebenfalls mit der Reparatur von Benutzerrechten befasst.

Kannst Du oder jemand anderes das dort vorgeschlagene Verfahren bewerten/einordnen?
Oh, ich glaube, das wird eine längere Antwort aud diesen Artikel.

Der Artikel ist, wie leider oft, etwas sehr pauschal und versucht mit sehr radikalen Dingen vorzugehen und schießt dabei definitv übers Ziel hinaus. Ich kann nur davon abraten, diesem Artikel zu folgen. Lass es sein, wenn du dir nicht noch mehr Probleme einhandeln willst. Viel Know-How scheint der Autor meines Erachtens nicht zu haben.

Im Einzelnen:

Grundsätzlich verstellen sich User-Rechte nicht einfach mir-nichts-dir-nichts. Da muss man schon was tun, was man hätte sein lassen sollen. Aus vielen Rückmeldungen und Hilferufen in Foren, treten Probleme mit den User-Rechten dann auf, wenn man einen Clean-Install macht und dann die Daten vom Backup oder aus der Timemachine mittels Finder zurück kopieren will. Oder eine Kombination aus Migrationsassi mit neuem User und manuellem Kopieren aus dem Backup und ähnliche Dinge. Mein Tipp ist da halt: keinen Clean-Install machen (es sei denn man kennt sich mit dem Thema der Rechte aus).

Zuerst ist es wichtig, den Auslieferungszustand, oder besser gesagt, die voreingestellten Rechte im Userverzeichnis zu kennen. Ich gehe erst mal nicht auf ACL (access control list) ein.

Um es etws übersichtlich zu mahcen, schreibe ich die Terminalnotation: Du kannst du im Terminal mit 'ls -l' ansehen
r=lesen
w=schreiben
x=Betreten bei Verzeichnissen bzw. Ausführen-können bei Dateien
Die ersten 3 Stellen sind der User, dann die Gruppe des Users, dann alle restlichen User (ich mach ein Leerzeichen dazwischen zur Lesbarkeit. Im Terminal ist das nicht)

Unter macOS ist das User-Verzeichnis selbst, also z.B. /Users/lisanet: rwx r-x r-x

Die von macOS standardmäßig angelegten Unterverzeichnisse im User-Verzeichnis sind anders:
Desktop, Documents, Downloads, Library, Movies, Music, Pictures sind alle: rwx --- ---. Das heißt also, sie können nur vom User selbst und sonst niemanden geschrieben, gelesen oder betreten werden. Ist ja auch sinnvoll. Einen anderen User gehen diese Sachen ja nichts an. Will man anderen Usern das erlauben -> dafür wurden die Dateifreigaben erfunden.

Public ist, wie es der Name sagt, öffentlich, also rwx r-x r-x, alle andern User können also lesen aber nichts rein schreiben.

Der "Briefkasten" unter Public ist etwas anders. Der hat die Rechte rwx -wx -wx, das bedeutet, dass andere User was rein schreiben (=kopieren) können, aber nichts daran sehen können. So wie in einem echten Briefkasten ja auch.

Wenn man im Home-Verzeichnis direkt nun selbst ein neues Verzeichnis anlegt oder eine Datei darin erstellt, dann werden standardmäßig folgende Rechte dafür genommen: rwx r-w r-x. Das bedeutet, das _alle User_ des Systems dieses Verzeichnis und die Dateien lesen können. Nicht unbedingt das, was man wahrscheinlich will. Zudem konterkariert es den o.g. Standard.

Daher empfiehlt es sich daher, entweder neue Verzeichnisse oder Dateien in den Standardverzeichnissen anzulegen oder die Rechte eben auf den macOS-Standard im direkten Homeverzeichnis anzupassen.


Warum ist nun der Artikel Mist und sogar gefährlich?

a) Info-Dialog: Hier wird pauschal empfohlen, die für das Home-Verzeichnis gemachten Einstellungen auf alle Unterobjekte anzuwenden. Das klingt zwar gut und logisch, führt aber dazu, dass die Rechte nun definitv nicht mehr so sind, wie sie im Auslieferungszustand, den ich oben beschrieben hab, waren. Die Folge ist nun, dass _jeder User_ des Systems _alle Dateien_ ohne weiteres _lesen_ kann.

b) Dann sagt der Artikel man solle weiterhin mit "diskutil resetUserPermissions / $(id -u)" arbeiten. Das "/" bedeutet dabei die gesamte Festplatte. Warum man das in Verbindung mit dem User machen soll, ist schlichtweg unsinnig. Zudem existiert der Befehl in 10.15.6 nicht mehr. (Gott sei Dank!)

c) Wenn man dann noch den letzten Befehl ansieht, dann wird's abenteuerlich. Klar kann der in ganz bestimmten Situationen helfen. Aber wenn man den schon braucht, dann hat man sein System vorher so verbastelt, dass dieser Befehl mit Sicherheit nicht die Probleme löst. Der Befehl löscht das sogenannte "immutable" Flag des Home-Verzeichnisses. Das ist aber standardmäßig gar nicht gesetzt. Das konnte früher (so zu SnowLeo-Zeiten) vielleicht mal durch einen Clean-Install mit zurückkopieren aus TimeMachine passieren. Aber ich kenne keine einigermaßen sinnvolle Aktion, die dieses Flag überhaupt auf das Homeverzeichnis setzen würde.

Rechte "reparieren" kann man am besten im Terminal, mit den Befehlen "chmod" (Rechte ändern), chown (User ändern) oder chgrp (Gruppe ändern), indem man die obigen Standards wiederherstellt.
 
Unix ging halt schon immer nach der Philosophie, dass es keine Geheimnisse in einem Unix-System geben sollte. Das ist Old School, "groovy" und eigentlich cool, aber reflektiert halt nicht mehr das heutige Denken. In einem Original Unix-Homeverzeichnis gibt es ja auch keine "Dokumente", "Bilder" und haumichblau-Ordner. Die wurden erst spaeter im Zuge des grafischen Desktops dazugebastelt. Deswegen haben wir heute das Mischmasch aus klassischen Unix-Nutzerrechten (jeder kann alles einsehen, aber nicht unbedingt aendern) und heutigem restriktiven Denken (der Inhalt meines Ordners geht niemanden etwas an).

Das sollte man sich immer vergegenwaertigen, bevor man an anfaengt an den Nutzerrechten rumzufummeln.

Und nein, mit dem poesen Clean Install hat das nichts zu tun. Ich habe das schon zigmal gemacht, mit anschliessendem manuellen Rueckspielen von Nutzerordnern aus dem Backup und mir hat's da noch nie was verhauen. Ich tippe wieder mal eher auf gewisse "Helferlein"... :hum:
 
Unix ging halt schon immer nach der Philosophie, dass es keine Geheimnisse in einem Unix-System geben sollte. ...

Von welchem Unix sprichst Du? Auf SunOS konnte ich schon vor 35 Jahren längst nicht alles lesen...
Meine Mail-Datei in meinen HOME Verzeichnis hatte damals auch schon rw- --- --- als Standard Dateiattribute...
Und dazu gibt es viele Beispiele mehr...

Aber Recht hast Du, dass es Download usw. nicht standardmässig gab.
Wenn Du Glück hattest, hatte Dein neuer Account zumindest eine
.profile
.cshrc
.xinitrc

Wenn Du Pech hattest, musstest Du auch diese Beispiele vom Kollegen kopieren. Dann war Dein $HOME wirklich leer...

--peter
 
SunOS war ja auch kein "original" UNIX. In den alten UNIXen war das schon immer so mit rwxr-xr-x.

PS: Bei der mbox-Datei weiss ich es, ehrlich gesagt, gar nicht mehr so genau. Kann sein, dass die eine Ausnahme war.
PPS: Kleine Ergaenzung von der FreeBSD-Webseite:
https://www.freebsd.org/cgi/man.cgi...opos=0&manpath=FreeBSD+12.1-RELEASE+and+Ports

Kurzer Snip:
The default mask value is S_IWGRP|S_IWOTH (022, write access for the owner only).
Welches impliziert, dass alle Nutzer Leserechte besitzen.
 
Zuletzt bearbeitet:
@lisanet

Ganz herzlichen Dank für Deine ausführliche und erhellende Antwort. Gut, dass ich um Bewertung des Artikels gebeten habe. Schade, dass man sich bei Heise nicht auf Qualität verlassen kann.
 
Welches impliziert, dass alle Nutzer Leserechte besitzen.
Die umask ist in macOS immer noch 022. Darum ist's ja meines Erachtens auch sinnvoller, nicht direkt im Homeverzeichnis neue Dateien / Verzeichnisse anzulegen, sondern in eben Documents, Pictures etc.
 
Zurück
Oben Unten