Funktioniert aber nur bis zum nächsten Neustart...

Dann ein Script nutzen, welches diesen Befehl immer bei der Anmeldung startet.

bitte zB

Bei mir war der Benutzerordner auch weg.

Dann warte ich noch mit dem Update. Den Local-Sync finde ich eh nicht so dolle.

script ist ja auch keine lösung. bei mir ist der benutzerordner nach delta update auch weg. stört erstmal nicht wirklich. schön ist aber anders.

Oder ausprobieren und gucken, was nach dem nächsten Neustart passiert.

sudo setfile -a v /Users/<name>

sollte einen Neustart überstehen

Es gab auch einen Ordner "Für alle Benutzer". Auch der ist nicht mehr zu sehen und läßt sich auch nicht mit dem o.g. Terminalbefehl wiederherstellen.
Gibt es dafür noch einen anderen Befehl?

Es gibt einen kleinen Trick der jeden Neustart übersteht.

Den von von MTN genannten Befehl ausführen. Dann einfach den Ordner Benutzer in die Seitenleiste des Finderfensters ziehen. Dort bleibt er auch nach einen Neustart erhalten. So braucht man nicht rumpfuschen bis das Problem von Apple behoben wird.
Ist es dann Behoben kann jeder den Ordner wieder aus der Seitenleiste schmeissen.

Was bedeuten würde, daß bei jedem Neustart ein Skript mit root-Rechten laufen würde, das dieses "hidden"-Flag entsprechend wieder setzt. Das kann ich mir irgendwie nicht so recht vorstellen, abgesehen davon daß das bei den Geräten, die ich hier gerade um mich habe, gar nicht auftritt, weder einmalig noch wiederholt.

bei mir ist er versteckt
was mir eigentlich egal ist, aber im final cut kann ich keine dateien, die ich am schreibtisch liegen habe, importieren, weil final cut im import-fenster den schreibtisch nicht mehr findet

so etwas darf nicht passieren

Für den "Für alle Benutzer" heißt der Befehl

sudo chflags nohidden /Users/Shared

Mein Bruder hatte heute das gleiche Problem, hatte zur Folge, dass er in Lightroom seinen Bilder Ordner nicht mehr gefunden hatte und nirgendwo hin importieren konnte, hat zwar temporär geholfen, aber nach Neustart war der Ordner auch wieder futsch.

Exakt. Drum als Eingrenzung die Idee, "SetFile" auszuschalten (weil das Applesche Zeugs in der Regel nicht chflags sondern SetFile nutzt, unter anderem weil man damit nicht nur BSD-Flags ändern sondern auch Erstellungs- und Modifikationsdatum anpassen kann).

Es ist gängige Praxis, dass bei System- und Security-Updates manche Sachen nicht beim Einspielen des Updates sondern erst im Rahmen des anschließenden Neustarts geradegezogen werden (meist durch irgendwas unterhalb /var/db getriggert). Und ab und an geht dabei offensichtlich so wie jetzt bei einem gewissen Prozentsatz der Systeme auch mal was schief.

Ich habe das Problem auf einem Rechner (MBP), und dort sind die Ordner nicht nur versteckt, sondern haben veränderte (erweiterte) Schreibrechte. Das finde ich gar nicht gut! Und stellt z.B. den VPN-Client Tunnelblick vor Probleme, weil ihm das dann zu unsicher ist.

Ich habe es noch nicht eingespielt, aber…
1. …mit 10.9.2 war der „offizielle“ Weg: Heimverzeichnis öffnen, Apfel-J, dann hat man eine Einstellungsoption für die Sichtbarkeit.
2. Bevor ich diesen Trick kannte, habe ich mir immer so beholfen:
a) Heimverzeichnis öffnen.
b) Shift-Apfel-G
c) Library
d) Ordner ist offen, jetzt einen Alias erstellen und ihn „Library_“ nennen oder so.

JREwing: Vielen Dank. Der Ordner "Für alle Benutzer" war wieder da. Bis zum nächsten Neustart...

Für mich völlig unverständlich, wie so etwas passieren kann. Das Update hatte doch eine enorm lange Vorlaufzeit und ist immer und immer wieder von unzähligen Usern weltweit getestet worden. Erst jetzt nach der Freigabe taucht auf einmal dieses Problem mit den Benutzerordnern auf? Das soll vorher niemandem aufgefallen sein? Verstehe ich nicht.

Ahhh, endlich die Bestätigung, dass beide Probleme wohl zusammenhängen. Zu Deiner Info: Das tritt nur auf einem gewissen Prozentsatz der Systeme auf und das Muster ist bislang nicht bekannt. Diskussion des Ganzen parallel hier nebenan:

Spannend wäre, mal
abzusetzen (behebt seitens Tunnelblick angemaulte Berechtigungen und Unsichtbarkeit), Tunnelblick zu starten (maul oder nicht?), dann einen Neustart durchzuführen und dann bitte erneut berichten, ob das durch den Neustart wieder revidiert wird oder nicht.

Wer hier ist nicht auch meiner Meinung, dass Apple längst weit unter unter unter Microsoft Niveau gefallen ist ?

Mei, so ist das ab und an mit Software-Geteste. Interne als auch externe Entwickler ticken anders als Normaluser (Letztere haben evtl. irgendwelche Softwares auf ihren Macs laufen, die kein Entwickler je installieren würde). Und manche Randbedingungen sind anders: Z.B. werden ca. 101% aller OS X Betatester Xcode auf dem Rechner haben, was an zig Stellen Dateien installiert hat. Sollten alle User, die jetzt in das "unsichtbar und falsche Permissions"-Problem laufen, kein Xcode installiert haben, dann ist da vielleicht ein kausaler Zusammenhang. Usw. usf. -- 100% fehlerfreie Software gibt es nicht und wegen solcher Unwägbarkeiten schlagen leider immer wieder echte Kracher trotz 'zig Betaversionen auch als finale Version auf den Rechnern von Endanwendern auf.

Th. Kaiser
Das hatte ich so gemacht und Tunnelblick ließ sich dann auch ohne maulen starten. Bis zum nächsten Neustart...

In den Apple Discussions habe ich gerade folgendes Vorgehen gefunden, das für mich das Problem scheinbar dauerhaft beseitigt hat:

Danke, d.h. das Permissions-Problem sowie Sichtbarkeit entstehen auf einem gewissen Prozentsatz von 10.9.3-Systemen jeweils erst beim Neustart.

Anscheinend oder scheinbar? Bitte nochmal Bestätigung, ob das jetzt Neustart-persistent ist

Denn was dort gepostet wurde, sind exakt die "ungetesteten" (hahaha, @Landgraeber -- der Witz war gut) Befehle, die ich auch gepostet habe, plus der -- oftmals nur als "Holzhammermethode" genannte -- Ratschlag, das NVRAM zurückzusetzen.

Danke und keine Sorge, diese Befehle sind a) harmlos (in Bezug auf das Testen) und b) kann ich damit umgehen (die waren ja an mich gerichtet).

Allerdings sollte statt "sudo chmod 755 /Users/Shared" der Befehl eigentlich "sudo chmod 777 /Users/Shared" heißen, sonst kann ja keiner etwas reinschreiben. Das ist beim Shared Folder sicher nicht gewünscht.

Das Festplattendienstprogramm repariert den Shared Folder übrigens ebenfalls auf 777.

Das ist Neustart persistent!

Jetzt schon dreimal und auch für Tunnelblick gibt es keine Schwierigkeiten mehr.

Vermutlich ist es PRAM zurücksetzen, denn genau wie du sagst, sind die restlichen Befehle ja identisch.

Puh, kraß. Dann nutzt Apple NVRAM-Variablen offensichtlich inzwischen wieder mehr und mehr.

Yep, ich Dummerle hab das quick&dirty und vor allem falsch von /Users geschlußfolgert (genaugenommen müsste es sogar "chmod 1777" heißen oder?)

Ok. Gerade mal getestet. Scheint wirklich der PRAM RESET zu sein. Da mein Laufwerk verschlüsselt ist, kann ich die Änderungen nicht im Recovery Mode machen. Der sieht nämlich mein Laufwerk nicht....
Also die chmod und setfiles ganz normal im Terminal nach PRAM Reset. Und siehe da: Alles läuft wie gewünscht. Auch nach jetzt mehreren Restarts.

Danke an lalle.

X-Ray

Soviel habe ich noch gar nicht getrunken