Benutzerkonto auf externem Volume

Lefteous

Aktives Mitglied
Thread Starter
Dabei seit
30.04.2005
Beiträge
445
Reaktionspunkte
11
Über die Systemeinstellungen kann man ja über die erweiterten Einstellungen das Benutzerkonto legen. Das funktioniert für mich auch echt prima. Es gibt dabei einige kleine Probleme, für die ich den Apple-Support kontaktiert habe. Nach langem Hin und Her kam dabei heraus, dass man das nicht machen darf. Warum gibt es dann diesen Dialog. Warum wird etwas angeboten, was dann nicht 100%ig funktioniert und nicht unterstützt wird?
 

Anhänge

  • user-account-volume.jpg
    user-account-volume.jpg
    162 KB · Aufrufe: 99
Warum gibt es dann diesen Dialog. Warum wird etwas angeboten, was dann nicht 100%ig funktioniert und nicht unterstützt wird?

Weil es Situationen gibt, wo dieser Dialog sinnvoll und notwendig ist. Interessanterweise genau beim "Verschieben" - genauer gesagt beim "umbennen auf dem internen Volume" - des Homeordners.

Den Homeordner eines Systems auf ein externes Volume zu geben, dass erst _nach_ Hochfahren gemountet wird ist zwar grundsätzlich möglich, jedoch gilt da halt auch der Spruch "es kommt drauf an". Und daher sind die individuellen Eigenschaften eines System entscheidend. Und da macOS sehr viele Eigenheiten hat (APFS-Verschlüsselung, firmlinks, hardcodierte Pfade, sandboxing, App-Container und so weiter), kann es halt auch sein, dass bei dem ein oder anderen Szenario, bei der ein oder anderen App, die veränderte Lage der Ordner auf externen Volumes eben zu Problemen führen kann.
 
Weil es Situationen gibt, wo dieser Dialog sinnvoll und notwendig ist. Interessanterweise genau beim "Verschieben" - genauer gesagt beim "umbennen auf dem internen Volume" - des Homeordners.
Kann sein, dass das stimmt, dass der Dialog vor allem dafür gedacht ist. Allerdings ist dort eine beliebige Auswahl möglich. Eine Beschränkung auf interne Volume gibt es nicht.

Den Homeordner eines Systems auf ein externes Volume zu geben, dass erst _nach_ Hochfahren gemountet wird ist zwar grundsätzlich möglich, jedoch gilt da halt auch der Spruch "es kommt drauf an". Und daher sind die individuellen Eigenschaften eines System entscheidend. Und da macOS sehr viele Eigenheiten hat (APFS-Verschlüsselung, firmlinks, hardcodierte Pfade, sandboxing, App-Container und so weiter), kann es halt auch sein, dass bei dem ein oder anderen Szenario, bei der ein oder anderen App, die veränderte Lage der Ordner auf externen Volumes eben zu Problemen führen kann.
Ich hatte noch ganz vergessen zu erwähnen, dass der Punkt des Apple Support gar nicht das Legen des Accounts auf das externe Volume per se ist. Es geht vor allem darum, dass das Systemvolumen und das Volumen des Benutzerordners nach Vorstellung des Supports identisch sein müssen. Alles andere werde nicht unterstützt. Das heißt auch explizit, dass eine Installation komplett auf dem externen Laufwerk möglich ist und supported wird. Oder: wenn ich das System auf das externe Laufwerk packe und das Benutzerkonto auf das interne Laufwerk, hätte ich exakt die gleichen Probleme wie jetzt auch. Long story short: Intern oder extern spielt hier gar keine Rolle, es geht darum diese beiden Dinge auf unterschiedliche Volumes zu packen und warum das ein Problem ist.

Die kleinen Probleme, die ich bisher gefunden habe, sind eigentlich nur eins, nämlich das man scheinbar Dateien auf einem anderen Volumen (hier Systemvolume) nicht in den Papierkorb verschieben kann, wenn der Benutzer auf einem anderen Volume gespeichert wird.

Ich hatte vorher die Variante mit den Symlinks auf Pfade auf der externen Platte im Home-Ordner. Das kann ich niemanden empfehlen. Da hatte ich genau diese Pfad-Probleme und das System lief auch insgesamt ziemlich unrund. So gut wie jetzt lief mein System schon lange nicht mehr. Wenn ich nicht auf weitere Probleme stoße, bleibe ich wohl dabei den kompletten Nutzer auf der externen Platte zu speichern.

Daher meine Frage in die Runde: Welche bekannten Probleme gibt es bei diesem Lösungsansatz?
 
Zuletzt bearbeitet:
Intern oder extern spielt hier gar keine Rolle, es geht darum diese beiden Dinge auf unterschiedliche Volumes zu packen und warum das ein Problem ist.

Das habe ich doch geschrieben. Was verstehst du nicht?

Sollte es sein "da kann man auch was externes wählen", dann bedenke bitte, dass es nicht um Geräte-Devices im Dialog geht, sondern um Pfade. Und die werden vom Kernel/Treibern fürs Userland (Dialog) einheitlich dargestellt / gemappt. So funktionieren eben Unixoide Betriebssysteme. Windows macht das mit diesen (IMO absolut unnötigen) Laufwerksbuchstaben anders.

Du kannst ja auch den Homeordner auf was externes legen, musst dann halt aber andere Sachen entsprechend anpassen, was aber nicht immer gelingen wird, wenn es die jeweiligen Entwickler nicht bedacht haben.

Das Thema ist auch nichts macOS spezifisches, sondern auch auf bspw Linux-Distris vorhanden. In unterschiedlicher Ausprägung.

Für das von dir wahrscheinlich angestrebte Ziel der Speicherplatzersparnis auf internen Platten gibt es bessere und weitaus sinnvollere Lösungen. Aber auch da gilt: Du musst dann auch andere Dinge anpassen. Eine one-click-Lösung kenne ich nicht.
 
Das habe ich doch geschrieben. Was verstehst du nicht?
Nein, ganz im Gegenteil:
Den Homeordner eines Systems auf ein externes Volume zu geben...
Sollte es sein "da kann man auch was externes wählen", dann bedenke bitte, dass es nicht um Geräte-Devices im Dialog geht, sondern um Pfade. Und die werden vom Kernel/Treibern fürs Userland (Dialog) einheitlich dargestellt / gemappt. So funktionieren eben Unixoide Betriebssysteme. Windows macht das mit diesen (IMO absolut unnötigen) Laufwerksbuchstaben anders.
Ja, offensichtlich, aber was ist die Relevanz dieser Aussage in diesem Kontext?
Du kannst ja auch den Homeordner auf was externes legen, musst dann halt aber andere Sachen entsprechend anpassen, was aber nicht immer gelingen wird, wenn es die jeweiligen Entwickler nicht bedacht haben.
Gut, darum geht es ja hier. Ich erhoffe mir hier konkrete Erfahrungen dazu. So ist das halt doch recht schwammig. Welcher Entwickler baut denn, wenn er schon relativ zum Benutzerordner arbeiten will, den dann so auf?
Java:
String home = "/Users/" + USERNAME;
Das Thema ist auch nichts macOS spezifisches, sondern auch auf bspw Linux-Distris vorhanden. In unterschiedlicher Ausprägung.
Aus eigener Erfahrung könnte ich nur von Problemen mit Symlink-Lösungen berichten, die es dort auch gibt. Dort habe ich den Ansatz mit den Account direkt auf einem anderen Volumen noch nie getestet.

Du kannst ja auch den Homeordner auf was externes legen, musst dann halt aber andere Sachen entsprechend anpassen, was aber nicht immer gelingen wird, wenn es die jeweiligen Entwickler nicht bedacht haben.
Die Symlink-Lösung hatte ich ja bereits getestet und für untauglich befunden. Auch hatte ich mal den ganzen Account als Symlink. Das ging Jahre lang sehr gut bis zu einem macOS-Update. Ich bin offen für gute Ideen, die dann aber schon auch konkreter sein dürfen ;-)
 
Wahrscheinlich wäre es seichter, wenn man es die APFS Volume Gruppen macht.
Z.B. die komplette Daten Volume auf das andere Laufwerk zu setzen.
 
Ich bin offen für gute Ideen, die dann aber schon auch konkreter sein dürfen ;-)

a) Home nicht auf extern
b) Keine symlinks auf externe Volumes / NAS selbst anlegen
c) nur innerhalb der Standardordner eigene Daten speichern bzw Verzeichnise anlegen.
d) externe Platten / NAS verwenden für Datenspeicherung, erfordert Anpassung von Programmen. Nicht alle Programme ermöglichen das. Entweder damit abfinden oder ein anderes Programm verwenden, was das erlaubt. macOS kann da nichts dafür.
e) Finger weg von der Library.

Da du keinen konkreten Einsatzzweck / Datenart / Programm nennst und keine konkreten Probleme benennst, kannst du auch nur allgemeine Antworten kriegen.
 
Welcher Entwickler baut denn, wenn er schon relativ zum Benutzerordner arbeiten will, den dann so auf?

Es gibt genügend Entwickler, die Pfade hardcoden. Es gibt allerdings auch manch gute Gründe das zu tun. (Datenschutz, Sync des Systems, Manipulationsschutz)
 
Wie Du weiter oben schon geschrieben hast, geht es um den Speicherplatz. Und ich suche nach einer Lösung, bei der eben die Kompatibilitätsprobleme nicht auftauchen.
Da du keinen konkreten Einsatzzweck / Datenart / Programm nennst und keine konkreten Probleme benennst, kannst du auch nur allgemeine Antworten kriegen.
Bei mir ist diese Lösung halt noch sehr frisch. Wenn jetzt viele Leute ankommen und eine Reihe konkreter Kompatibilitätsprobleme mit dieser Lösung erlebt haben, würde ich mir andere Lösungen noch mal genauer anschauen.

Es gibt genügend Entwickler, die Pfade hardcoden. Es gibt allerdings auch manch gute Gründe das zu tun. (Datenschutz, Sync des Systems, Manipulationsschutz)
Gibt es eine Liste solcher Apps, die solche Ding tun?
 
Bei mir ist diese Lösung halt noch sehr frisch. Wenn jetzt viele Leute ankommen und eine Reihe konkreter Kompatibilitätsprobleme mit dieser Lösung erlebt haben, würde ich mir andere Lösungen noch mal genauer anschauen.
+1 Habe ich. Mehrere Systeme damit erfolgreich zerlegt.
Das ist einfach nicht dafür gedacht, es gibt andere (bessere!!) Möglichkeiten um Speicherplatz zu organisieren, statt an dem Home-Ordner zu basteln.

Gibt es eine Liste solcher Apps, die solche Ding tun?
Was sollen die tun?
Probleme haben?
 
Wahrscheinlich wäre es seichter, wenn man es die APFS Volume Gruppen macht.
Z.B. die komplette Daten Volume auf das andere Laufwerk zu setzen.
Da müsste ich mich erst mal reinfuchsen. Ich hatte schon mal eine Lösung auf Basis von Fusion Drive. Ist das vergleichbar?
 
+1 Habe ich. Mehrere Systeme damit erfolgreich zerlegt.
Das ist einfach nicht dafür gedacht, es gibt andere (bessere!!) Möglichkeiten um Speicherplatz zu organisieren, statt an dem Home-Ordner zu basteln.
Das ist ein guter Hinweis. Welche Lösung würdest du persönlich empfehlen?

Was sollen die tun?
Probleme haben?
Das Arbeiten mit dieser Lösung verhindern.
 
Da müsste ich mich erst mal reinfuchsen. Ich hatte schon mal eine Lösung auf Basis von Fusion Drive. Ist das vergleichbar?
Fusion verbindet Container und schiebt Sachen hin und her.
Ich meinte eher die Art von Volume Gruppe, die System und Daten Volume verlinkt.
Da quasi die Daten Volume komplett auf das externe Laufwerk, dann solltest keine Probleme haben.
 
Fusion verbindet Container und schiebt Sachen hin und her.
Ich meinte eher die Art von Volume Gruppe, die System und Daten Volume verlinkt.
Da quasi die Daten Volume komplett auf das externe Laufwerk, dann solltest keine Probleme haben.
Ich habe deinen letzten Satz leider nicht ganz verstanden. Ich könnte mir die Intention vielleicht irgendwie erschließen, möchte aber bei diesem sensiblen Thema Missverständnisse vermeiden.
 
MacOS legt doch seit Catalina eine System (schreibgeschützt) und eine Daten Volume.
Von der Datenvolume aus werden auch Ordner über firm links in die System Volume eingehängt, auf die man ja nicht schreiben kann.

Die Idee wäre jetzt diese Daten Volume komplett auf extern zu verlagern.

Plan B wäre es über firm links komplett /Users einzuhängen, wie man das früher auch auf Unix Systemen gemacht hat.
 
... bitte, bitte keine Links auf externe Datenträger die via USB/TB/Netzwerk angebunden sind. Egal wie verlockend das klingt.
 
Hat das mit den Volume Groups schon mal jemand produktiv ausprobiert mit den Volume Groups zu diesem Zweck?
 
Vor ~20 Jahren kannte ich jemanden der seinen Homefolder auf einem Server via NFS genutzt hatte, damals konnte man macOS auch noch auf UFS installieren.
 
das ist doch alles immer das identische Grundproblem, egal ob Links oder Volume Groups etc.

Kannst du sicherstellen, dass die externen Datenträger immer verfügbar sind und immer schon eingebunden sind wenn dein Useraccount vom OS erstmals benötigt wird oder Programme und Systemdienste auf die Daten zugreifen, dann klappt es.

Da du das aber nicht sicherstellen kannst, da du das OS so tief nicht kontrollieren kannst, spielst du halt Roulette. Kann gut gehen, lange Zeit und dann nicht mehr.

Bestes Beispiel:

überlege dir den Fall des Rückspielens eines Backups / Umzuges auf einen neuen Rechner. Viel Spaß veim Verzweifeln, was du zuerst nachen sollst.
 
Zurück
Oben Unten