Wie kann die Netzwerkfreigabe für einen bestimmten Benutzer mithilfe von Automount zuverlässig verbunden bleiben?

Ich habe ein Synology NAS und einen Mac mini mit Plex und XBMC, der Inhalte vom NAS streamt. Das MM verliert aus verschiedenen Gründen häufig die Verbindung zum NAS (z. B. nach einem Update/Neustart des NAS, Netzwerkproblemen, OS X-Problemen).

Nachdem ich mehrere Lösungen für dieses Problem ausprobiert hatte, stieß ich schließlich auf das integrierte Automount-Tool, das Netzwerklaufwerke wieder verbinden soll, wenn die Verbindung unterbrochen wird. Ich habe es eingerichtet, und es schien zu funktionieren. Aber es gibt ein nerviges Problem:

Ich bin mir nicht sicher, wie ich das formulieren soll, aber automatisch gemountete Freigaben scheinen von Zeit zu Zeit in einen nicht wirklich verbundenen Zustand überzugehen. Wenn die Freigabe durchlaufen wird, wird sofort eine Verbindung hergestellt. Das ist in Ordnung, aber die Freigabe wird nur für den Benutzer gemountet, der darauf zugegriffen hat .

Ich habe zwei Benutzerkonten: TV, das Plex und XBMC ausführt und auf die Freigabe zugreifen muss, und Admin, das ich für Verwaltungsaufgaben verwende. Gelegentlich verwende ich auch das Admin-Konto, um eine Verbindung zum NAS herzustellen, aber dafür verwende ich den Finder. Eine dauerhafte Verbindung ist nicht erforderlich.

Aus irgendeinem Grund, den ich nicht verstehe, wird die automatisch bereitgestellte Freigabe manchmal für das Admin-Konto bereitgestellt. Das bedeutet, dass das TV-Konto nicht auf die Freigabe zugreifen kann (Zugriff verweigert). Ich kann umountdie Freigabe mit Admin und lsmit TV machen, um sie für letzteres zu mounten, aber nach einiger Zeit hat Admin die Berechtigungen wieder.

Wie kann ich das beheben? Wie muss ich die Berechtigungen einrichten, damit TV das einzige Konto ist, das auf die automatisch bereitgestellte Freigabe zugreifen kann?

So sehen meine Automount-Dateien aus:


auto_master

Berechtigungen:-rw-r--r-- 1 root wheel

+auto_master      # Use directory service
/net              -hosts     -nobrowse,hidefromfinder,nosuid
/home             auto_home  -nobrowse,hidefromfinder
/Network/Servers  -fstab
/-                -static
/-                auto_nas   -nosuid,noowners


auto_nas

Berechtigungen:-rw------- 1 root staff

/NAS -fstype=smbfs,soft smb://TV:@192.168.1.56/Files


/NAS (der Einhängepunkt)

Berechtigungen:drwx------@ 1 TV wheel


Auf dem MM läuft Yosemite (10.10.3).

Antworten (1)

Angenommen, Sie möchten die Anmeldefunktion für „Root“-Benutzer NICHT aktivieren und die Datei- und Verzeichnisberechtigungen nicht so weit lockern, dass Ihr System möglicherweise einem erheblichen Vektor von Sicherheitsangriffen ausgesetzt wird (und genau das gehe ich davon aus ...), ab heute , 7. Februar 2017, es gibt keine Möglichkeit, das zu erreichen, was Sie beschreiben :(

Zumindest nicht für AFP / SMB / CIFS-Freigaben (das sind die einzigen drei, die ich getestet habe, Sie haben vielleicht anderes Glück mit NFS-Volumes, aber ich betreibe diese nicht in meinem Netzwerk, kann es also nicht bestätigen).

Es scheint zwei mögliche Ursachen zu geben. Einer ist, dass irgendwann um Yosemite herum einige Änderungen am Unterschied zwischen der Verwendung von direkter und indirekter Automounting-Funktion vorgenommen wurden, die zeitweilige Fehler verursachten, wenn mehr als ein Benutzer auf eine automatisch gemountete Freigabe zugegriffen hat.

Ab Sierra ist diese Funktionalität vollständig unterbrochen , da der Besitzer des speziellen /Volumes-Verzeichnisses zum "Root"-Benutzer gemacht wurde und dieser Benutzer automatisch den Besitz übernimmt, wenn einem anderen Benutzer der Besitz von Ordnern oder Dateien in diesem Verzeichnis gewährt wird Irgendwann. Es wurden Fehler gemeldet , Sie können gerne kommentieren und Ihre Empörung teilen.

Im Kommentarbereich zu diesem Blogbeitrag, in dem mehrere Beispiele für die Verwendung von Automount (und einige seiner Einschränkungen) erörtert werden, bietet Benutzer „Mark“ eine vollständige Analyse dieses Problems in Bezug auf die gemeinsame Nutzung von automatisch bereitgestellten Ordnern durch mehrere Benutzer.

TL;DR - es war irgendwo um 10.10 kaputt und obwohl es in vielen Foren diskutiert wurde, hat Apple den Fehler noch nicht anerkannt oder sich zu einer Behebung verpflichtet.

Ich denke, dass mit 10.11 etwas passiert, das die Prozedur zum Einhängen von AFP-Freigaben in Benutzerverzeichnisse unterbricht. Ich versuche, afp://user:pass@myserver.local/Music in /Users/me/Test zu mounten

auto_master hat die Zeile: /- auto_afp -nosuid

auto_afp hat die Zeile: /Users/me/Test -fstype=afp afp://serveuser:servepass@server.local/Music

Der Server wird problemlos gemountet, aber wenn Sie auf das Serversymbol in /Users/me klicken, wird der Fehler „Der Ordner „Test“ kann nicht geöffnet werden, da Sie keine Berechtigung haben, seinen Inhalt anzuzeigen“ angezeigt.

Nachdem ich das Problem durchgearbeitet habe, sehe ich, dass dies ein Berechtigungsproblem ist. Der Einhängepunkt hat den Besitzer und die Gruppe und die Berechtigungen: drwx——@ 1 root wheel 364 31 Dec 10:01 Test (Eigentlich ist es interessant — wenn ich meine auto_afp-Datei entleere und neu starte, kehrt dies zu einem regulären Verzeichnis mit owner/ zurück Gruppe/Berechtigungen drwx——+ 18 me staff 612 31 Dez 10:01 Test)

Das Problem hier ist also, dass autofs die Freigabe mit Root-Rechten einhängt und mein Benutzer die Freigabe nicht wirklich verwenden kann. Nach meiner Lektüre im Internet scheint dies ein relativ neues Problem zu sein – vielleicht im Zusammenhang mit El Capitan?

Zum Vergleich, wenn ich Folgendes mache (als Benutzer, nicht als Systembenutzer oder mit 'sudo'): Erstellen Sie einen neuen Ordner im Finder unter /Users/me mit dem Namen 'Test3' und geben Sie dann im Terminal ein: mount -o nosuid -t afp afp://serveuser:servepass@server.local/Music /Users/me/Test3

dann wird der Server wunderbar gemountet (allerdings mit dem Findernamen „Music“, den ich lieber ändern würde) und hat die folgenden Benutzer/Gruppen/Berechtigungen: drwx——@ 1 me staff 364 31 Dec 10:21 Test3 and I am Inhalte sehen und manipulieren können.

Zusammenfassend lautet das Problem also: Wie kann ich autofs dazu bringen, eine Netzwerk-AFP-Freigabe zu mounten und sie einem Benutzerverzeichnis zuzuordnen, sodass der Benutzer darauf zugreifen und seinen Inhalt bearbeiten kann? Historisch denke ich, dass Autofs genau so funktionieren sollte, aber es scheint, dass der Besitz des zugeordneten Ordners durch „Root Wheel“ verhindert, dass er jetzt wirklich von Nutzen ist.

Eine Sache noch, wenn ich schon dabei bin: Ich bin auf das oben skizzierte einfache Ziel zurückgefallen, aber mein längerfristiges Ziel ist es, JEDEM Benutzer einen externen Musikordner zuzuordnen. auto_afp sollte so aussehen:

/Users/me/Test -fstype=afp afp://serveuser:servepass@server.local/Music /Users/her/Test -fstype=afp afp://serveuser:servepass@server.local/Music /Users/him /Test -fstype=afp afp://serveuser:servepass@server.local/Music

Ich weiß, dass ich dieses Mount in den Login-Elementen jedes Benutzers vornehmen kann, aber das ist eigentlich nicht gut genug, um meine langfristigen Anforderungen zu erfüllen. Langfristig muss dieser Ordner beim Booten von autofs bereitgestellt werden, um ihn für die Cloud-Sicherung verfügbar zu machen.

Benutzer „Ben“ kommentierte, bestätigte diese Analyse und wiederholte, dass es zumindest zu dem Zeitpunkt, als er seinen Kommentar teilte, keine Lösung gab:

Die Verwendung einer indirekten Karte hilft auch nicht. Diese Funktionalität scheint in OSX grundlegend kaputt zu sein, zumindest seit Yosemite… Ich habe 3 Jahre lang Posts von Leuten durchforstet, die dasselbe Problem hatten, und soweit ich das beurteilen kann, gibt es einfach keine Möglichkeit, einen Einhängepunkt zu teilen Benutzer… was für ein riesiger, ärgerlicher, unglaublicher Fehler.

Danke Apfel!

HINWEIS: Ich empfehle dies für kein Netzwerk, daher werde ich hier keine detaillierten Anweisungen dazu geben, aber ein anderer Benutzer auf demselben Kommentarbrett gab an, dass die Aktivierung des Root-Benutzer-Logins und die Verwendung dieses Zugriffs auf sein System dies ermöglichen würde funktionieren wie erwartet:

Eine Möglichkeit besteht darin, root zu aktivieren und sich als root anzumelden. Sobald Sie das tun, beginnt alles zu funktionieren. Scheißoption, ich weiß, aber mein Anwendungsfall ist ein Medienserver in einem isolierten Netzwerk. Einzige Option, bis ich sehen kann, bis Apple den Kopf aus dem Arsch bekommt.

Dies wird von allen, Apple, Sicherheitsexperten usw., dringend abgeraten, daher denke ich, dass dies ein gangbarer Weg ist, um dieses Problem zu umgehen. Wir müssen warten, bis Apple einen Fix veröffentlicht.