• Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
    Näheres könnt Ihr hier nachlesen: AGB-Änderung
  • Es regnet, ist neblig und kalt, alle sind krank und der Chef wird zunehmend cholerisch. Das Thema des Monats ist also folgerichtig --> Das Grau(en)
    Wir sind gespannt, war Euch dazu einfällt! Zum Wettbewerb --> Klick
  • Auch in diesem Jahr möchten wir auf unserer Webseite mit einem passenden Banner etwas weihnachtliche Stimmung verbreiten. Jeder Apfeltalker kann, darf und sollte uns einen Banner-Entwurf zusenden, wie und wo das geht, könnt Ihr hier nachlesen --> Klick

Zwei Benutzer und nur eine Serververbindung

vromue

Jonagold
Registriert
22.06.21
Beiträge
22
Hallo zusammen

Ich stehe derzeit auf dem Schlauch und auch langes Suchen und Lesen im Internet hat mich noch nicht weitergebracht. Ich habe im Büro einen Mac (derzeit noch mit High Sierra), auf dem ich zwei Benutzer eingerichtet habe. Beide Kollegen sollen auf dem Mac-Server (Mojave) arbeiten können. Der erste User mountet den Server (via afp) und kann normal damit arbeiten. Loggt sich der zweite User ein, ist die Serververbindung bereits hergestellt, jedoch erscheint beim Versuch, darauf zuzugreifen, die Fehlermeldung: «Der Ordner "Mac-Server" kann nicht angezeigt werden, da du nicht die erforderlichen Zugriffsrechte zur Anzeige des Ordnerinhalts hast.» Es ist unerheblich, welcher der beiden Kollegen sich als erster mit dem Server verbindet – es ist einfach der andere, der nicht zugreifen kann. Mit einem Windows-Volume (via smb) gibt es keinerlei Probleme, da läuft's, wie's soll.

Kann mir jemand bitte auf die Sprünge helfen, wo es da hakt, wo man ansetzen muss?

Herzliches Dankeschön!
 

Marcel Bresink

Filippas Apfel
Registriert
28.05.04
Beiträge
8.877
Loggt sich der zweite User ein, ist die Serververbindung bereits hergestellt,

Es ist unklar, auf welche Weise sich der zweite Benutzer einloggt (direkt am Bildschirm, oder per SSH oder beide gleichzeitig mit Schneller Benutzerumschaltung, etc.) und mit welchem Authentifizierungsverfahren der erste beim AFP-Server angemeldet ist.

Dem Effekt nach dürfte es aber so sein, dass dem ersten Benutzer die Verbindung mit dem Server "gehört". Dann ist es völllig selbstverständlich, dass kein anderer Benutzer diese Verbindung nutzen darf. Benutzer 1 könnte ja mit einem Server-Konto A die Verbindung hergestellt haben, auf das Benutzer 2 kein Zugriffsrecht hat. Ansonsten könnte sich ja Benutzer 2 ein Server-Recht erschleichen, das ihm nicht zusteht.

Wenn das so ist, muss Benutzer 2 selbst eine Verbindung mit dem Server aufbauen, so dass der Server auch ihn authentifizieren kann.
 

vromue

Jonagold
Registriert
22.06.21
Beiträge
22
Vielen Dank für deine Antwort! Der geteilte Mac wird via Bildschirmfreigabe benutzt, also Login darüber. Betreffend Authentifizierungsverfahren musst du mir helfen: Wie wo was könnte ich da prüfen oder beeinflussen? Ist das in OSX Server konfiguriert? Wo?

Wenn das so ist, muss Benutzer 2 selbst eine Verbindung mit dem Server aufbauen, so dass der Server auch ihn authentifizieren kann.
Genau das ist der Punkt. Aber wie kann ich das bewerkstelligen?
 

Marcel Bresink

Filippas Apfel
Registriert
28.05.04
Beiträge
8.877
Der geteilte Mac wird via Bildschirmfreigabe benutzt, also Login darüber.

OK, also sind tatsächlich beide Benutzer gleichzeitig an einer Bildschirmsitzung angemeldet.

Ist das in OSX Server konfiguriert?

Wird wirklich macOS Server verwendet? Das ist zum Betrieb eines AFP-Servers überflüssig. Falls die Server-App allerdings genutzt wird, um einen Open Directory-Verzeichnisserver mit netzweiten Benutzer-Accounts einzurichten, könnte eine Kerberos-Anmeldung verwendet werden. Aber das ist jetzt offenbar nicht der Auslöser des Problems.

Aber wie kann ich das bewerkstelligen?

Ein ganz normaler Verbindungsaufbau, z.B. im Finder über "Gehe zu > Mit Server verbinden" über eine URL nach dem Muster

afp://benutzer@server/freigabe

sollte reichen.
 
  • Like
Reaktionen: ottomane und dg2rbf

vromue

Jonagold
Registriert
22.06.21
Beiträge
22
Wird wirklich macOS Server verwendet? Das ist zum Betrieb eines AFP-Servers überflüssig.
Ja, es ist MacOS X 10.14 Server. Das angehängte RAID ist der zentrale Filespeicher für ca. 15 Mitarbeiter. Diese Infrastruktur wurde von einem externen IT-Dienstleister eingerichtet und war schon vor meiner Zeit da. Inwiefern OS X Server hier überflüssig sei, kann ich gerade nicht beurteilen, aber mir scheint, dass mal unterschiedliche Arbeitsbereiche auf dem Server arbeiteten, z.B. auch Buchhaltung, die andere Zugriffsbereiche brauchten als «der gemeine Pöbel». Wie auch immer – es ist so, und schadet ja auch nicht, ein Server-Betriebssystem auf einem Server zu haben. ;)

Ein ganz normaler Verbindungsaufbau, z.B. im Finder über "Gehe zu > Mit Server verbinden" über eine URL nach dem Muster
afp://benutzer@server/freigabe
sollte reichen.
Benutzer1 des geteilten Macs meldet sich wahlweise via "Mit Server verbinden" (afp://192.168.100.X) und im folgenden entsprechenden Dialog mit User und Passwort oder im verkürzten Verfahren via Alias erfolgreich am Server an. Obige Erweiterung des Pfads mit Credentials ist ja nichts anders, oder? Das Problem ist aber: Wenn sich nun Benutzer2 einloggt, ist der Server hier bereits gemountet, allerdings nur mit der Berechtigung für Benutzer1. Wirft Benutzer2 den Server nun aus (gilt dann auch für Benutzer1) und meldet sich mit demselben User und Passwort wie Benutzer1 neu an, erscheint dieser auch bei Benutzer1 wieder, aber nun ist dieser der Gelackmeierte ohne Berechtigung.

Im Zusammenhang mit dem Mac-Server sieht es also so aus, als ob der geteilte Mac nur eine Verbindung zum AFP-Mac-Server aufbauen könnte, die ausschliesslich für jenen Benutzer gilt, der den Server gemountet hat. Auf den ebenfalls auf identische Weise gemounteten SMB-Win-Server können aber beide Benutzer problemlos zugreifen, egal welcher ihn gemountet hat. Wo ist hier der entscheidende Unterschied zum Mac-Server?
 

Marcel Bresink

Filippas Apfel
Registriert
28.05.04
Beiträge
8.877
Obige Erweiterung des Pfads mit Credentials ist ja nichts anders, oder?

Doch, das ist etwas anderes, so hätte ich es nicht geschrieben. Dadurch wird macOS schon von Vorneherein gezwungen, eine anderen Benutzer-Authentifizierung für den zweiten Mount zu verwenden. Es gibt allerdings Fälle, in denen sich macOS trotzdem entscheiden kann, einen bereits bestehenden Mount wiederzuverwenden. Das hängt wie gesagt vom Authentifizierungsverfahren, von den Benutzer-Accounts auf Client- und Server-Seite, und von den Berechtigungseinstellungen für den freigegebenen Ordner ab. Dann müsste man anders vorgehen.

afp://192.168.100.X

Hierzu noch die Anmerkung:
- Die Verwendung von AFP ist veraltet und sollte eigentlich seit OS X 10.9 nicht mehr verwendet werden. Standardprotokolle in macOS 10.14 sind SMB und NFS.
- IPv4-Adressen sind veraltet, der Server sollte über seinen DNS- oder Bonjour-Namen angesprochen werden. Standardprotokoll in macOS 10.14 ist dann IPv6, was schneller und sicherer sein kann.

Im Zusammenhang mit dem Mac-Server sieht es also so aus, als ob der geteilte Mac nur eine Verbindung zum AFP-Mac-Server aufbauen könnte

Es sind beliebig viele Verbindungen möglich, man muss nur verhindern, dass macOS automatisch annimmt, ein Mount könnte vermieden werden, weil er bereits mit kompatiblen Einstellungen aktiv ist. Dass hier jeweils ein Benutzer ausgesperrt wird, könnte beispielsweise an fehlendem Gruppenleserecht für die betreffenden Benutzer liegen.
 

vromue

Jonagold
Registriert
22.06.21
Beiträge
22
Hallo Marcel

Danke für deine weiteren Inputs!

Das Nichtangewiesensein auf den DNS-Server kann hilfreich sein, wenn man ein so ausfallanfälliges Ding hat, wie unseres zumindest phasenweise zu sein scheint. ;)

Ich habe nun heute mal alle Server-Volumes ausgeworfen und jeweils auch die Credentials aus dem Schlüsselbund gelöscht, damit ich sauber von Null anfangen kann. Habe mich nach Neustart unter Benutzer1 nach deinem Beispiel "Benutzer@Server/Volume/" angemeldet. Zu Benutzer2 gewechselt: Das Volume ist ohne Zugriffsberechtigung gemountet. Mit obigem Weg kann ich mich nun immerhin auch unter Benutzer2 nochmals anmelden und als zugriffsberechtigt ausweisen: Das Server-Volume erscheint ein zweites Mal auf dem Desktop, dieses nun mit Zugriffsberechtigung. Unter Benutzer1 vice versa.

Also kann ich nun unter beiden Benutzern auf dem Server arbeiten, das zugriffsunberechtigte Duplikat muss halt einfach tapfer ignoriert werden. Ein «sauberes» Verhalten wie mit dem Win-Server (ich sehe nur eine Version des Volumes, mit Zugriffsberechtigung) wäre natürlich weiter wünschenswert, aber es tut immerhin mal. :)
 

Marcel Bresink

Filippas Apfel
Registriert
28.05.04
Beiträge
8.877
Ein «sauberes» Verhalten wie mit dem Win-Server (ich sehe nur eine Version des Volumes, mit Zugriffsberechtigung) wäre natürlich weiter wünschenswert,

Das hat nichts mit dem Betriebssystem des Servers zu tun.
Zum einen kannst Du auch auf dem Mac-Server SMB nutzen (was von Apple seit Jahren empfohlen wird), zum anderen dürfte das beobachtete Verhalten wie gesagt an den Berechtigungen für den freigegebenen Ordner liegen.
 

vromue

Jonagold
Registriert
22.06.21
Beiträge
22
Das hat nichts mit dem Betriebssystem des Servers zu tun.
Sagt ja auch niemand. Irgendwo ist der entscheidende Unterschied bei den beiden Servern (die ich zur reinen Differenzierung mit dem Betriebssystemszusatz benenne), und den würde ich gerne finden und beheben können.

Zum einen kannst Du auch auf dem Mac-Server SMB nutzen
Diese Variante muss ich morgen, falls ich Zeit finde, mal noch gegenprüfen. Ich versuche mich zu erinnern, aber es will mir nicht einfallen, weshalb mal SMB keine Alternative gewesen sein soll … 🤔

zum anderen dürfte das beobachtete Verhalten wie gesagt an den Berechtigungen für den freigegebenen Ordner liegen.
Und da wäre noch immer die Frage: Wo müsste man da wonach suchen?
 

vromue

Jonagold
Registriert
22.06.21
Beiträge
22
Update: Ich habe heute Vormittag mal probiert, die Serververbindung mittels SMB aufzubauen. Da werden aber User/Passwort nicht akzeptiert. Leider hatte ich keine Zeit, mich auf die Suche nach dem Grund zu machen, und so kann ich derzeit nicht sagen, ob es im Verhalten des OS etwas ändert.