[10.8 Mountain Lion] Benutzerrechte im Eimer - Festplattendienstprogramm keine Hilfe

[HyteRaph]

Oh je..
Also kurze Vorgeschichte:
Wie in diesem Threat geschildert, sind bei meiner alten Server Installation die Benutzer und Gruppen (warum auch immer) verschwunden.. Mir fiel nach kurzer Zeit keine bessere Lösung als ein erneutes Aufsetzen des Server ein. Dafür habe ich die noch vorhandenen Benutzerordner gesichert und deren Inhalt nach der Neuinstallation in deren neue Benutzerordner geschoben. Ich habe dann die Rechter für jeden Benutzerordner so eingerichtet (über "Informationen"-"Freigaben & Zugriffsrechte"), dass nur der jeweilige Benutzer und der Serveradminaccount Lese-&Schreibrechte haben. "everyone" auf "Keine Rechte". Meiner Meinung nach müsste das ja tauglich für die Netzwerkbenutzer sein. Die Benutzer können auch über das Netzwerk auf ihre Ordner zugreifen, aber:

Mobile Netzwerkbenutzeraccounts haben "keine Rechte zum schreiben". .. warum auch immer?!

und:

Das Festplattendienstprogramm findet unter "Zugriffsrechte des Volumes überprüfen" unzählige Fehler. Nachdem ich sie "repariert" habe und anschließend wieder überprüfe, ändert sich exakt gar nichts. Alle Fehler sind weiterhin existent. Wenn hier jemand eine Idee hat, bitte melden. Das könnte ja evtl. mit dem oben geschilderten Problame zusammen hängen. Ich weiß auch nicht... Oh man..

 

[salome]

Diese Möglichkeit Zugriffsrechte repsrieren" bezieht sich nur auf die Systemrechte , nicht auf die Userrechte. Und sie werden auch nicht "repariert" sondern auf den Ausgangszustand Gestüt, der sich mitunter durch updaten verschoben hat. Dass manche Einstellungen nicht zurückgesetzt werden, hat keine Bedeutung, du kannst das unbeachtet lassen. Fehler liegen kaum je an falschen Systemrechten, außer der User hat gebastelt.

Die Userrechte setzt du mit dem Terminal der recovery Partition zurück.
Du öffnest dieses in den Dienstprogrammen der recovery Partition und
"reset password" ein und drückst die Return-Taste, danach geht ein Fenster auf, in dem du ganz nach unten scrollst. Da erscheint dann "Userrechte zurücksetzen", du wählst den richtigen User aus (kleiner Tab weiter oben) und gleich ist der Vorgang erledigt.

Dann startest du wieder von der internen Platte. Leider habe ich festgestellt, dass diese Prozess sehr oft gar nichts hilft.

 

[MacApple]

Mobile Netzwerkbenutzeraccounts haben "keine Rechte zum schreiben". .. warum auch immer?!

Kontrollier mal, ob die Dateien in den Benutzerordnern auch den jeweiligen Benutzer gehören und ob die Gruppe richtig gesetzt ist.

 

[HyteRaph]

Diese Möglichkeit Zugriffsrechte repsrieren" bezieht sich nur auf die Systemrechte , nicht auf die Userrechte. Und sie werden auch nicht "repariert" sondern auf den Ausgangszustand Gestüt, der sich mitunter durch updaten verschoben hat. Dass manche Einstellungen nicht zurückgesetzt werden, hat keine Bedeutung, du kannst das unbeachtet lassen. Fehler liegen kaum je an falschen Systemrechten, außer der User hat gebastelt.

Okey. Gut zu wissen. Danke für die Erklärung!

Die Userrechte setzt du mit dem Terminal der recovery Partition zurück.
Du öffnest dieses in den Dienstprogrammen der recovery Partition und
"reset password" ein und drückst die Return-Taste, danach geht ein Fenster auf, in dem du ganz nach unten scrollst. Da erscheint dann "Userrechte zurücksetzen", du wählst den richtigen User aus (kleiner Tab weiter oben) und gleich ist der Vorgang erledigt.

Dann startest du wieder von der internen Platte. Leider habe ich festgestellt, dass diese Prozess sehr oft gar nichts hilft.

Verstehe ich das richtig, dass ich im Recovery Mode starten soll und dann dort im Terminal die Nutzerrechte resetten muss?

Kann ich nicht über das normale Terminal im laufenden Betrieb (bei abgemeldetem Benutzer) die Rechte reppen? (sudo chown nutzername:group -R /Users/nutzername) - also mit etwas ähnlichem, weil das habe ich schon probiert..

Ansonsten muss ich wohl mit Feierabend warten...

//edit:

Habe noch etwas zu der "resetpassword" Sache recherchiert. Muss wohl neustarten .. Dann werde ich das später mal probieren. Hoffentlich hilft das auch. Ich kann nämlich von meinem Benutzeraccount keine Dateien mehr löschen, weil ich angeblich die Rechte nicht hätte..

Danke für die Hilfestellung!

 

[Riwwelmaddes]

Wenn ich Dich richtig verstehe, haben nur mobile User (wie über I Phone, I Pad) keine Schreibrechte. Hast du in der Dateifreigabe bei den Einstellungen Deines Volumen die Freigabe über WebDAV erteilt? Vielleicht hilft das weiter.

Gruß!
Stefan

 

[HyteRaph]

Wenn ich Dich richtig verstehe, haben nur mobile User (wie über I Phone, I Pad) keine Schreibrechte. Hast du in der Dateifreigabe bei den Einstellungen Deines Volumen die Freigabe über WebDAV erteilt? Vielleicht hilft das weiter.

Gruß!
Stefan

Hi Stefan,
ich schätze jeder Netzwerkbenutzer hat Probleme mit seinem persönlichen Netzwerkbenutzerordner (/Users/*netzwerkbenutzername). Obwohl ich direkt am Server die Nutzerordner den jeweiligen Nutzern alle Rechte einräume.

Soll heißen:
Nutzer "Tom" hat Lese- & Schreibrechte für den Ordner /Users/Tom (sudo chown Tom:workgroup /Users/Tom)
-Zumindest wird mir das angezeigt, wenn ich im /Users Ordner Rechtsklick-Informationen von "Tom" anschaue

Wenn sich Tom nun am Server anmeldet, um auf die Freigaben zuzugreifen, kann er zwar die normalen Standartfreigaben, welche im Büro für verschiedene Gruppen zur Verfügung stehen lesen und schreiben, ABER nicht seinen eigenen Ordner.
- Freigabe Ordner A und Ordner B sind stehen normal zu Verfügung -- /Users/Tom nicht

Für die allgemeine Büroaktivität ist das nun noch kein Weltuntergang, weil im Grunde nur die allgemeinen Freigaben(Ordner A & B..) für die Dateiverwaltung genutzt werden, aber ich möchte doch schon gerne eine intakte Rechtestruktur der Users-Ordner haben. Zumal das für mobile Netzwerkaccounts (Synchronisation) zwingend erforderlich ist.

Ich hoffe es ist verständlich, was ich sagen möchte

 

[HyteRaph]

So .. Gerade "resetpassword" versucht durchzuführen.

Leider werden mir die Netzwerkbenutzeraccounts nicht angezeigt. Einzig der Serveraccount und Adminaccount wurden angezeigt...
Wieso zum Teufel kann ich denn bitte nicht die Daten aus dem jeweiligen Usersordner änern, wenn ich mit dem jeweiligen Nutzer angemeldet bin und dieser auch der Ordnerbesitzer ist?! Ich verstehe das einfach nicht!! Hach das ist zum ausrasten....

 

[Marcel Bresink]

Mir fiel nach kurzer Zeit keine bessere Lösung als ein erneutes Aufsetzen des Server ein.

Das war keine gute Idee. Es wäre besser gewesen, die Open Directory-Datenbank aus einer Datensicherung wiederherzustellen.

Ich habe dann die Rechter für jeden Benutzerordner so eingerichtet (über "Informationen"-"Freigaben & Zugriffsrechte"), dass nur der jeweilige Benutzer und der Serveradminaccount Lese-&Schreibrechte haben.

Mit dem Finder kann man das nicht richtig machen. Du darfst keine Rechte hinzufügen, sondern musst die Eigentümer aller Dateien ändern. Dass ein Admin-Account Schreibrecht auf Benutzerdaten hat, ist eine Sicherheitslücke und sollte vermieden werden.

Mobile Netzwerkbenutzeraccounts haben "keine Rechte zum schreiben". .. warum auch immer?!

Weil Mobile Accounts sowohl auf dem Server als auch auf dem Mobilgerät einen Benutzerordner haben. Es müssen alle Eigentümer für alle Dateien auf allen Computern im Netz überprüft und angepasst werden. Man müsste ein maßgeschneidertes UNIX-Skript auf Basis von "find" entwickeln, um das hinzubekommen.

Leider werden mir die Netzwerkbenutzeraccounts nicht angezeigt.

Das kann auch nicht funktionieren, da das Recovery-Betriebssystem nicht als Open Directory-Client eingerichtet werden kann. Die netzweiten Accounts sind daher unbekannt.

 

[HyteRaph]

Das war keine gute Idee. Es wäre besser gewesen, die Open Directory-Datenbank aus einer Datensicherung wiederherzustellen.

Hmm Mist. Jetzt ist es leider zu spät. Für die Zukunft: Wie stelle ich denn einzig die Open Directory aus dem Timemachine Backup wieder her?

Mit dem Finder kann man das nicht richtig machen. Du darfst keine Rechte hinzufügen, sondern musst die Eigentümer aller Dateien ändern. Dass ein Admin-Account Schreibrecht auf Benutzerdaten hat, ist eine Sicherheitslücke und sollte vermieden werden.

Okey, das mit dem Adminaccount habe ich nun geändert bzw. dessen Rechte wieder raus genommen.
Einen Eigentümer setzt man doch mittels "sudo chown NAME:GRUPPE /Users/NAME" oder irre ich mich? Denn genau das habe ich gemacht. Dennoch kann ich mit meinem Benutzer keine Daten aus meinem persönlichen Benutzerordner (auf dem Server) löschen...

Weil Mobile Accounts sowohl auf dem Server als auch auf dem Mobilgerät einen Benutzerordner haben. Es müssen alle Eigentümer für alle Dateien auf allen Computern im Netz überprüft und angepasst werden. Man müsste ein maßgeschneidertes UNIX-Skript auf Basis von "find" entwickeln, um das hinzubekommen.

Mobile Account meint doch, dass man alle persönlichen Benutzerdaten vom Server auf den Client synchronisiert, oder? Es tritt bei mir auch bei "standard" Netzwerkaccounts auf. (s.o.) Ohne einen mobilen Account am Client eingerichtet zu haben, kann ich, wenn ich mich über meinen Netzwerkaccount anmelde, keine Daten von meinem Benutzerordner am Server bearbeiten, weil cih die Rechte nicht hätte. Laut Finder am Server hat mein Acc allerdings Lese-&Schreibrechte und chown wurde auch gesetzt.
Wie bekokmme ich das blos wieder in Ordnung?!

Das kann auch nicht funktionieren, da das Recovery-Betriebssystem nicht als Open Directory-Client eingerichtet werden kann. Die netzweiten Accounts sind daher unbekannt.

Das verstehe ich leider nicht ganz. Ich habe doch das BS komplett neu und auch eine neue Open Direcotry erstellt. Alle Account wurden auch per Hand neu gesetzt. Anschließend habe ich den zuvor gesicherten Inhalt der Benutzeraccounts wieder zurück in deren neue Benutzerordner geschoben und da scheint der Hase im Pfeffer begraben zu sein, oder?

Vielen Dank schonmal für die Antworten. Hast du unter Umständen eine Idee, wie ich die Benutzerrechte wieder in die Angeln heben kann? Ich kann nicht ganz nachvollziehen, wieder "chown" nicht funzt und wieso ich mit meinem Netzwerkaccount die Daten meines eigenen Benutzeraccounts nicht verändern kann.

Langsam verzweifle ich ..

 

[HyteRaph]

Also noch mal kurz gefasst:

Obwol mein Benutzerordner über den Netzwerklogin eingebunden wird und ich somit die Ordner "Dokumente", "Downloads" usw. sehe, wie sie auf dem Server für meinen Benutzeraccount liegen, bekomme bei Löschversuchen immer die Meldung, dass ich nicht die nötigen Berechtigungen habe. Umbenennen, Bearbeiten und so funzen logischerweise auch nicht.
Rechtsklick-Informationen sagt allerdings mein Account hat Lese-&Schreibzugriff.

 

[Marcel Bresink]

Wie stelle ich denn einzig die Open Directory aus dem Timemachine Backup wieder her?

Wenn nur Open Directory wiederhergestellt werden soll, geht das per Time Machine nicht. Wenn das getrennt vom restlichen System behandelt werden soll, muss man vorher die Funktion "Open Directory-Master archivieren" in der Server-App verwendet haben und dann die entsprechende Rückladefunktion nutzen.

Einen Eigentümer setzt man doch mittels "sudo chown NAME:GRUPPE /Users/NAME" oder irre ich mich?

Wenn das wörtlich so gemeint ist, wird damit nur der Eigentümer für ein einziges Objekt geändert, nämlich für den Privatordner des Benutzers (aber nicht für dessen Inhalt). Wie gesagt müssten im schlimmsten Fall alle Dateien auf allen Platten auf allen Computern überprüft werden. Die Details hängen davon ab, in welcher Umgebung mit welchem Programm von welchem Benutzer die Daten wieder zurückkopiert wurden.

Ich habe doch das BS komplett neu und auch eine neue Open Direcotry erstellt.

Es ging ja hier um die Frage, ob man vom Recovery-Betriebssystem aus mit Benutzer-Accounts des Servers arbeiten kann. Das geht nicht und hat mit dem "richtigen" Betriebssystem nichts zu tun.

Hast du unter Umständen eine Idee, wie ich die Benutzerrechte wieder in die Angeln heben kann?

Dazu müsste man sehen, welche Benutzerrechte tatsächlich eingestellt sind. Der Finder ist dazu nicht geeignet. Mit

dscl /Search -read /Users/`whoami`

kannst Du die Identität Deines eigenen Accounts vollständig anzeigen lassen.

Mit

ls -leO@ ~

kannst Du die Rechteeinstellungen zumindest für alle sichtbaren Objekte in der obersten Ebene Deines Privatordners anzeigen lassen.

 

[HyteRaph]

Ich habe bisher von den anderen Nutzern keine Probleme mitbekommen. Ich bin aber auch einer der wenigen, welche bereits einen mobilen Account besaßen und das Netzwerk-Login überhaupt nutzen für die Anmeldung. Ich gehe jetzt erstmal davon aus, dass wohl nur mein Account betroffen ist.. Bzw hoffe ich das einfach mal.

dscl /Search -read /Users/username
dsAttrTypeNative:objectClass: person inetOrgPerson organizationalPerson posixAccount shadowAccount top extensibleObject apple-user
AltSecurityIdentities: Kerberos:[email protected]
AppleMetaNodeLocation: /LDAPv3/127.0.0.1
AppleMetaRecordName: uid=username,cn=users,dc=server,dc=xxx,dc=private
AuthenticationAuthority:
;ApplePasswordServer;XXXX [email protected]:xxx.xxx.xxx.xxx
;Kerberosv5;;[email protected];XXX.XXX.XXX;
EMailAddress: [email protected]
FirstName: Xxx
GeneratedUID: 61X267XX-780X-49X7-X48X-XX55X66X76XX
HomeDirectory: <home_dir><url>afp://xxx.xxx.xxx/Users</url><path>username</path></home_dir>
HomeDirectoryQuota: 20000000000
LastName: Xxx
NFSHomeDirectory: /Network/Servers/xxx.xxx.xxx/Users/username
Password: ********
PrimaryGroupID: 20
RealName:
User Name
RecordName: username
RecordType: dsRecTypeStandard:Users
UniqueID: 1025
UserShell: /bin/bash

ls -leO@ ~
total 0
drwx---r-x+ 30 username  staff  -  1020 22 Apr 13:46 Desktop
0: group:everyone deny delete
1: user:XXX allow list,search,readattr,readextattr,readsecurity
drwx---r-x+ 39 username  staff  -  1326 22 Apr 11:31 Documents
0: group:everyone deny delete
1: user:XXX allow list,search,readattr,readextattr,readsecurity
drwx---r-x+ 18 username  staff  -  612 22 Apr 12:33 Downloads
0: group:everyone deny delete
1: user:XXX allow list,search,readattr,readextattr,readsecurity
drwx---r-x@ 41 username  staff  hidden 1394 22 Apr 12:29 Library
   com.apple.FinderInfo    32
0: group:everyone deny delete
1: user:XXX allow list,search,readattr,readextattr,readsecurity
drwx---r-x+  3 username  staff  -  102 26 Mär 15:05 Movies
0: group:everyone deny delete
1: user:XXX allow list,search,readattr,readextattr,readsecurity
drwx---r-x+  3 username  staff  -  102 26 Mär 15:05 Music
0: group:everyone deny delete
1: user:XXX allow list,search,readattr,readextattr,readsecurity
drwx---r-x+ 11 username  staff  -  374 16 Dez 17:11 Pictures
0: group:everyone deny delete
1: user:XXX allow list,search,readattr,readextattr,readsecurity
drwx---r-x+  4 username  staff  -  136 26 Mär 15:05 Public
0: group:everyone deny delete
1: user:XXX allow list,search,readattr,readextattr,readsecurity
drwxr-xr-x+  7 username  staff  -  238 22 Apr 12:52 ownCloud
0: user:_spotlight inherited allow list,search,file_inherit,directory_inherit

Kann man damit irgendwas erkennen?

Im Zweifel werde ich meinen Nutzer noch einmal komplett löschen und neu erstellen in der Hoffnung, dass die Rechte anschließend korrekt sitzen.

PS: Bei etwas herumprobieren ist mir etwas äußerst komisches aufgefallen:

Der Inhalt einer Word Datei, welche auf meinem Schreibtisch liegt, lässt sich bearbeiten und sogar über Word speichern. Die Datei lässt sich allerdings weder in den Papierkorb schieben noch lässt sich der Dateiname ändern.... WIe kann sowas denn schon wieder sein?!

 

[Marcel Bresink]

Die Daten zeigen, dass "username" Eigentümer der Ordner ist. Falls bei Eingabe von

ls -ln

die Anzeige von "username" durch "1025" ersetzt wird, wäre bestätigt, dass Du selbst der Eigentümer der Ordner bist. Zumindest das wäre dann schon mal korrekt.

Ansonsten fällt auf, dass der Eigentümergruppe "staff" das Leserecht entzogen wurde, während aber "jedem sonst" das Leserecht gegeben wird. Ebenso muss manuell einmal dem einzelnen Benutzer "XXX" ein zusätzliches Leserecht erteilt worden sein. Falls "XXX" in Wirklichkeit eine hexadezimale Zahlen-/Buchstabenfolge ist, ist dieser Benutzer-Account inzwischen gelöscht worden.

Der Inhalt einer Word Datei, welche auf meinem Schreibtisch liegt, lässt sich bearbeiten und sogar über Word speichern. Die Datei lässt sich allerdings weder in den Papierkorb schieben noch lässt sich der Dateiname ändern.... WIe kann sowas denn schon wieder sein?!

Das würde bedeuten, dass Du für den Ordner "Desktop" in Deinem Privatordner kein Schreib- und Löschrecht hast.

 

[HyteRaph]

Hallo Marcel,

vielen Dank schonmal für deine Mühen!
XXX war/ist ein existierender user. Die gelöschten Nutzerrechte habe ich nach dem neu aufsetzen per hand unter "Informationen" der jeweiligen Ordner in den neu erstellten Nutzer geändert. Da liegt vermutlich auch der Hase im Pfeffer begraben...

ls -ln ~:

drwx------+ 1 1025  20  264 22 Apr 15:26 Desktop
drwx------+ 1 1025  20  264 22 Apr 15:12 Documents
drwx------+ 1 1025  20  264 22 Apr 15:20 Downloads
drwx------@ 1 1025  20  1248 22 Apr 15:38 Library
drwx------+ 1 1025  20  264 22 Apr 15:05 Movies
drwx------+ 1 1025  20  264 22 Apr 15:05 Music
drwx------+ 1 1025  20  264 22 Apr 15:05 Pictures
drwxr-xr-x+ 1 1025  20  264 22 Apr 15:05 Public
drwxr-xr-x+ 1 1025  20  264 22 Apr 15:39 ownCloud

Das würde bedeuten, dass Du für den Ordner "Desktop" in Deinem Privatordner kein Schreib- und Löschrecht hast.

Dem list Befehl oben nach zu urteilen scheint sowas der Fall zu sein, oder? Ich kann zwar nichts mit dem drwx Zeug anfangen, aber auffällig ist, dass ownCloud und Public so unterschiedliche Rechte zu haben scheinen...


//edit & Lösung:
Obwohl ich ja inzwischen den Netzwerkaccount eh neu angelegt habe, scheinen die einzelnen Dateien von den Rechten immer noch verrückt zu spielen. Zumindest von der Anzeige her im Finder. Nun habe ich herausgefunden, dass, wenn ich den Elternfolder anschaue und dessen Rechte auf alle beherbergten Dateien übertrage, das kuriose "Ich-kann-nichts-löschen-Problem" behoben wurde. Das ganze habe ich direkt am Server getätigt. Anschließend konnte ich die gesicherten Dateien auch über meinen Clientrechner mit meinem Netzwerkaccount umbennenen/löschen usw.

Diese Lösung ist vermutlich nicht die sauberste und vermutlich auch nicht die schnellste, aber hat mir geholfen. Schade nur, dass ich dafür den Account einmal mehr komplett gelöscht habe, um ihn anschließend wieder neu zu erstellen. Das war vermutlich nicht nötig. Ich schätze, dass ich das "Rechte auf alle Unterobjekte anwenden..." am Elternordner auch vor dem Neuerstellen des Accounts hätte machen können.


Vielen Dank für die Mühen und Hilfestellungen Marcel und die Anderen!

 

[stk]

das entscheidende ist die »1025« das ist die UID des Benutzers dem der Ordner nun gehört, da gibt es die Divergenz zwischen den Systemen alt und neu.

Wahlweise kannst Du die UID des Benutzers wieder entsprechend anpassen oder mit

sudo chown -r USERKURZNAME:staff /Users/USERKURZNAME

die Zuordnung von Benutzerordner und korrektem User wieder herbei führen.

Nur nebenbei: die Rechte von Public sind korrekt, die von OwnCloud würde ich auf drwx------ ändern. Aber das ist normal wenn auf oberster Ebene des Homefolders ein neuer Ordner erzeugt wird oder dort Dokumente abgelegt werden, das diese von außen einsehbar sind. Das Apple das immer noch nicht gefixt hat …