M6 Mac mini: Claude Code 2026 bereitstellen, isolieren

Symptom → schnellste Lösung: Wenn mehrere Entwickler denselben macOS-Account oder dasselbe Arbeitsverzeichnis für Claude Code verwenden, stoppen Sie diesen Aufbau und trennen Sie zuerst Benutzer, Projekte, Zugangsdaten und Protokolle. Für ein kleines Team genügt zunächst ein M6 Mac mini mit separaten macOS-Accounts und einer Aufgabenwarteschlange; bei sensiblen Repositorys oder dauerhaftem Parallelbetrieb sollten Sie projektbezogene Mac-Umgebungen einplanen.

Diese Anleitung ist für Sie gedacht, wenn Sie als technische Leitung einen M6 Mac mini als gemeinsamen AI-Programmierknoten betreiben wollen. Sie richtet sich außerdem an verteilte Entwicklungsteams, die Claude Code remote ausführen, sowie an Administratoren, die Codeberechtigungen, API-Zugangsdaten und die Sicherheit der Entwicklungsumgebung verantworten.

Zuletzt aktualisiert: 02.09.2026. Die Aussagen zu M6 Mac mini, macOS 27 und der aktuellen Claude-Code-Bereitstellung wurden gegen die Apple-Produktinformationen zum M6 Mac mini, die offizielle Installationsanleitung für Claude Code und die offizielle CLI-Referenz geprüft. Der M6 Mac mini ist zwar veröffentlicht, hat am Prüfdatum aber noch nicht mit einer breiten Auslieferung begonnen. Aussagen zur maximalen Parallelität bleiben daher ohne reale Belastungstests bewusst offen.

Warum ein gemeinsamer macOS-Account für Claude Code nicht genügt

Die Frage „Kann Claude Code von mehreren Personen auf einem Mac gemeinsam genutzt werden?“ lässt sich technisch mit „ja“, organisatorisch aber nur unter engen Bedingungen beantworten. Ein gemeinsamer Account kann für einen einzelnen Maintainer funktionieren, der Aufgaben entgegennimmt, prüft und nacheinander ausführt. Er ist keine echte Mehrbenutzerumgebung.

Das Problem liegt nicht allein in der Anzahl geöffneter Terminals. Sie müssen mindestens vier Grenzen voneinander trennen:

• Identität: Es muss nachvollziehbar sein, welcher Entwickler eine Aufgabe gestartet, Dateien verändert oder einen Commit vorbereitet hat.
• Dateizugriff: Ein Arbeitsverzeichnis darf nicht gleichzeitig als Schreibbereich für unabhängige Aufgaben dienen.
• Zugangsdaten: Persönliche Git-Schlüssel, Claude-Code-Anmeldungen, Tokens und externe Plattformschlüssel gehören nicht in eine gemeinsam geladene Shell-Konfiguration.
• Betriebszustand: Prozesse, temporäre Dateien, Logs und Sitzungen können Informationen über andere Projekte preisgeben oder laufende Änderungen überschreiben.

Ein gemeinsamer Account erschwert zudem die nachträgliche Untersuchung eines Fehlers. Selbst wenn Git den Autor eines Commits speichert, beweist das nicht, welcher Systembenutzer den Prozess gestartet oder eine Datei vor dem Commit verändert hat. Die Claude-Code-CLI-Dokumentation beschreibt die Bedienung und Befehle, ersetzt aber keine Mandantentrennung auf Betriebssystemebene.

Ein weiterer versteckter Kostenpunkt ist die Wartung. Eine zentrale Konfiguration ist am Anfang schneller eingerichtet, führt aber später zu Sonderfällen: Ein Entwickler benötigt einen anderen Repository-Zugriff, ein Projekt darf keine externen Netzwerkziele erreichen oder ein festhängender Prozess blockiert die Sitzung eines anderen Teams. Die vermeintlich einfache Lösung wird dann zu einer manuellen Rechteverwaltung ohne klare Beweiskette.

Erfahrungshinweis: Mehrere Ordner unter /Users/Shared sind keine Sicherheitsgrenze. Wenn derselbe macOS-Account verwendet wird, bleiben Prozesse, Schlüssel, Umgebungsvariablen und viele lokale Zustände grundsätzlich innerhalb derselben Identität.

Welche Architektur passt zu welcher Teamgruppe?

Die passende Architektur hängt weniger vom M6-Namen als von der Arbeitsweise Ihres Teams ab. Entscheidend sind die Sensibilität der Repositorys, die Zahl gleichzeitig laufender Aufgaben, die gewünschte Nachvollziehbarkeit und die Frage, ob ein Fehler den gesamten Entwicklungsbetrieb unterbrechen darf.

Ein Maintainer für ein kleines Team

Bei einem niedrigen Aufkommen kann eine Person Aufgaben aus Tickets oder Chat-Nachrichten sammeln, priorisieren und Claude Code kontrolliert ausführen. Die Entwickler liefern Branch, Ziel, erlaubte Änderungen und Abnahmekriterien; der Maintainer startet die Aufgabe in einem eigens dafür vorgesehenen Konto und veröffentlicht anschließend das Ergebnis.

Vorteile:

• geringer Einrichtungs- und Pflegeaufwand,
• eine zentrale Prüfung vor Änderungen und Commits,
• leichter kontrollierbare Zugangsdaten,
• kein unkoordinierter Schreibzugriff auf dasselbe Arbeitsverzeichnis.

Nachteile:

• der Maintainer wird zum Engpass,
• spontane interaktive Arbeit durch mehrere Entwickler ist kaum möglich,
• persönliche Verantwortung und Ausführung lassen sich nur sauber trennen, wenn jede Aufgabe protokolliert wird,
• ein Neustart oder eine blockierte Sitzung kann alle nachfolgenden Aufgaben verzögern.

Diese Variante ist sinnvoll, wenn der Mac primär als kontrollierter Automatisierungsknoten dient. Sie passt nicht, wenn Entwickler gleichzeitig interaktive Sitzungen benötigen oder jeder Benutzer auf private Projektbereiche zugreifen muss.

Ein eigenes Konto für jeden Entwickler

Für ein kleines, regelmäßig arbeitendes Team ist die robustere Zwischenstufe ein separater macOS-Account pro Entwickler. Jeder Benutzer erhält ein privates Home-Verzeichnis, ein eigenes Claude-Code-Anmeldeverfahren, eigene SSH-Schlüssel und eine eigene Git-Identität. Remote-Zugriff wird über einen individuellen Benutzer und nicht über ein gemeinsam verwendetes Administratorkonto eingerichtet.

Apple beschreibt die Aktivierung von Remote Login und SSH unter macOS. Für Git-Zugriffe mit mehreren Identitäten liefert die Anleitung zu mehreren Git-Konten und SSH-Konfigurationen die passende Grundlage. Die Host-Aliase in ~/.ssh/config müssen dabei im jeweiligen Benutzerkonto liegen, nicht in einer globalen Datei, die versehentlich von allen Sitzungen gelesen werden kann.

Vorteile:

• Betriebssystemberechtigungen bilden eine echte erste Trennlinie,
• persönliche Git- und Claude-Code-Anmeldungen bleiben getrennt,
• Fehler und Prozesse können einem Benutzer zugeordnet werden,
• private Arbeitsverzeichnisse lassen sich mit weniger Ausnahmen schützen.

Nachteile:

• gemeinsame Abhängigkeiten und Caches müssen bewusst geplant werden,
• Updates und Toolchains können pro Konto unterschiedliche Zustände haben,
• Administratorrechte dürfen nicht pauschal an alle Entwickler vergeben werden,
• ein einzelner Mac bleibt ein gemeinsamer Ausfallpunkt.

Mehrere Projekte mit echter Warteschlange

Sobald mehrere Repositorys und längere Aufgaben zusammentreffen, benötigen Sie zusätzlich zur Benutzertrennung eine Aufgabensteuerung. Jeder Auftrag sollte Projekt, Branch, Arbeitsverzeichnis, Startzeit, verantwortliche Person, erlaubte Aktionen und Endstatus enthalten. Claude Code darf nicht automatisch in einem Verzeichnis starten, das gerade von einer anderen Aufgabe verändert wird.

Ordnen Sie jedem Projekt einen eigenen Workspace zu. Gemeinsame Paket-Caches können sinnvoll sein, sofern sie keine Quelltexte, Tokens oder projektspezifischen Konfigurationsdateien enthalten. Private Build-Ausgaben, .env-Dateien, lokale Datenbanken und temporäre Agent-Dateien sollten dagegen im Projektbereich bleiben und durch Dateirechte geschützt werden.

Legen Sie für lange Aufgaben vier Zustände fest: wartend, aktiv, abgeschlossen oder abgebrochen. Ein Auftrag, der die Sitzung verliert, darf nicht einfach erneut gestartet werden, ohne den Workspace auf uncommittete Änderungen, laufende Prozesse und zurückgebliebene temporäre Dateien zu prüfen.

Sicherheitskritische Entwicklung

Bei personenbezogenen Daten, proprietären Modellen, Kundencode oder Produktionszugängen reicht ein separater macOS-Account allein nicht. Trennen Sie persönliche Anmeldungen, technische Dienstkonten und externe Plattformzugänge. Ein Dienstkonto sollte nur die Repositorys und Aktionen sehen, die für den konkreten Automatisierungsauftrag erforderlich sind.

Die Dokumentation zum LLM-Gateway und zu Sicherheitsgrenzen von Claude Code sollte Ihre Audit- und Freigabegrenzen ergänzen. Hochrisikoaktionen wie das Löschen großer Verzeichnisse, Änderungen an Deployment-Konfigurationen, Zugriff auf Produktionssysteme oder das Veröffentlichen eines Commits sollten eine manuelle Bestätigung verlangen.

Bei DSGVO-relevanten Projekten müssen Sie zusätzlich klären, welche Eingaben an externe Dienste übertragen werden dürfen, wie lange Logs gespeichert werden und wer auf Sitzungsprotokolle zugreifen kann. Der Mac-Standort allein beantwortet diese Fragen nicht. Sie brauchen eine dokumentierte Datenklassifizierung und eine Regel, welche Repositorys auf dem gemeinsamen Knoten überhaupt zugelassen sind.

Schritt für Schritt: einen isolierten Claude-Code-Knoten aufbauen

Erster Schritt: den Betriebsmodus schriftlich festlegen

Entscheiden Sie vor der Installation, ob Sie den Mac als Maintainer-Knoten, als Mehrbenutzer-Entwicklungsgerät oder als kontrollierte Aufgabenwarteschlange betreiben. Schreiben Sie außerdem auf, welche Projekte ausgeschlossen sind. Ohne diese Entscheidung wächst eine provisorische gemeinsame Installation meist unbemerkt zu einer Umgebung mit zu vielen Ausnahmen.

Definieren Sie pro Auftrag mindestens:

• verantwortliche Person,
• Repository und Branch,
• erlaubtes Zielverzeichnis,
• zulässige Netzwerkzugriffe,
• erforderliche Freigaben,
• Aufbewahrungsdauer für Logs,
• Verfahren für Abbruch und Wiederherstellung.

Zweiter Schritt: getrennte macOS-Accounts anlegen

Erstellen Sie für Entwickler und technische Dienstprozesse getrennte Konten. Nutzen Sie kein gemeinsames Passwort und lassen Sie normale Benutzer nicht dauerhaft mit Administratorrechten arbeiten. Der Wartungsaccount sollte nur für Systemupdates, Benutzerverwaltung und Wiederherstellung verwendet werden.

Prüfen Sie die Zugriffsmatrix anschließend mit einem absichtlich harmlosen Testprojekt:

1. Konto A legt eine Testdatei im eigenen Home-Verzeichnis an.
2. Konto B versucht, diese Datei zu lesen und zu verändern.
3. Beide Konten starten je einen ungefährlichen Prozess.
4. Sie prüfen, ob Prozessinformationen und Logs mehr preisgeben als beabsichtigt.
5. Sie entfernen Testdateien und kontrollieren temporäre Verzeichnisse.

Das ist keine vollständige Sicherheitszertifizierung, deckt aber typische Fehlkonfigurationen auf, bevor echte Quelltexte auf den Mac gelangen.

Dritter Schritt: Arbeitsbereiche und Git-Identitäten trennen

Legen Sie für jeden Auftrag einen eindeutigen Workspace an, statt alle Projekte in einem gemeinsamen Verzeichnis zu klonen. Vermeiden Sie Namen wie latest, shared oder temp, wenn mehrere Aufgaben gleichzeitig laufen. Ein Name sollte Projekt, Branch und Auftragskennung nachvollziehbar machen, ohne vertrauliche Inhalte in den Pfad zu schreiben.

Konfigurieren Sie Git pro Benutzer und prüfen Sie vor jeder Aufgabe:

• user.name und user.email,
• den Remote-Endpunkt,
• den aktiven Branch,
• den Status mit git status,
• lokale Hooks und projektspezifische Skripte.

SSH-Schlüssel gehören in das Home-Verzeichnis der jeweiligen Identität und sollten nicht über eine gemeinsam geladene .zshrc exportiert werden. Wenn ein Projekt mehrere Git-Konten benötigt, verwenden Sie getrennte SSH-Host-Aliase nach dem Muster der offiziellen Mehrkonten-Anleitung, statt Schlüsseldateien zwischen Benutzern zu kopieren.

Vierter Schritt: Claude Code pro Identität authentifizieren

Installieren Sie Claude Code nach der aktuellen offiziellen Installationsanleitung. Die Authentifizierung muss pro Benutzer oder ausdrücklich über ein kontrolliertes Dienstkonto erfolgen. Kopieren Sie keine Anmeldedateien aus dem Home-Verzeichnis eines anderen Entwicklers und legen Sie keine Tokens in globale Umgebungsdateien.

Dokumentieren Sie, welcher Zugang für welche Aufgabenklasse verwendet wird. Ein persönlicher Zugang ist nicht automatisch für einen unbeaufsichtigten Dienstprozess geeignet. Umgekehrt sollte ein Dienstkonto nicht als Ersatz für persönliche Verantwortlichkeit dienen. Wenn Ihre Organisation ein Gateway, eine zentrale Richtlinie oder eine verwaltete Authentifizierung verwendet, testen Sie Ablauf, Widerruf und Rotation der Zugangsdaten vor dem Produktiveinsatz.

Wie lassen sich API-Zugangsdaten bei mehreren Claude-Code-Nutzern trennen? Am zuverlässigsten trennen Sie zuerst die Betriebssystemidentität und anschließend deren lokale Anmeldedateien, Umgebungsvariablen und SSH-Konfiguration. Verwenden Sie keine gemeinsame Shell-Datei mit allen Tokens. Für unbeaufsichtigte Aufgaben sollten Sie ein begrenztes Dienstkonto einsetzen, dessen Zugang widerrufbar ist und dessen Nutzung in den Aufgabenlogs erscheint.

Fünfter Schritt: Befehle, Netzwerk und Freigaben begrenzen

Erstellen Sie pro Projekt eine Liste erlaubter Werkzeuge und Aktionen. Lesen, Testen und Formatieren können andere Risiken besitzen als Löschen, Paketinstallation, Netzwerkzugriff oder Deployment. Eine pauschale Freigabe aller Shell-Befehle ist besonders problematisch, wenn Claude Code in einem Workspace mit vertraulichen Dateien läuft.

Prüfen Sie auch die macOS-Berechtigungen für Dateien, SSH, Netzwerkzugriff und Bildschirm- oder Automatisierungsfunktionen. Ein Prozess, der wegen einer Berechtigungsabfrage auf Eingabe wartet, ist in einer unbeaufsichtigten Sitzung nicht „sicher fertig“, sondern lediglich blockiert. Die Freigabe muss einer verantwortlichen Person zugeordnet und anschließend protokolliert werden.

Sechster Schritt: Warteschlange, Abbruch und Aufräumen testen

Starten Sie zunächst nur nicht sensible Repositorys. Simulieren Sie eine normale Aufgabe, einen Fehler, eine manuelle Unterbrechung, einen abgebrochenen Prozess und einen Neustart des Mac. Nach jedem Durchlauf kontrollieren Sie:

• ob der Workspace wieder eindeutig zugeordnet ist,
• ob Hintergrundprozesse beendet wurden,
• ob temporäre Dateien entfernt oder gesichert wurden,
• ob Logs Start, Ende, Benutzer und Ergebnis enthalten,
• ob ein erneuter Auftrag versehentlich alte Änderungen übernimmt.

Legen Sie einen Timeout nicht als vermeintliche Leistungsgrenze fest. Die passende Dauer hängt von Repository-Größe, Tests, Netzwerkanforderungen und Aufgabenart ab. Messen Sie zunächst echte Aufgaben und wählen Sie danach eine betriebliche Grenze mit Sicherheitsreserve.

Siebter Schritt: Remote-Zugriff und Wiederherstellung absichern

Remote Login über SSH ist für administrative Zugänge besser geeignet als ein offen erreichbarer grafischer Fernzugriff. Setzen Sie keine Management-Ports direkt dem öffentlichen Internet aus. Verwenden Sie stattdessen eine abgesicherte Netzwerkverbindung, restriktive Firewall-Regeln und individuelle Schlüssel beziehungsweise verwaltete Zugänge.

Planen Sie für macOS 27 und den M6 Mac mini ausdrücklich diese Fehlerfälle:

• Neustart nach Systemupdate,
• Wechsel oder Ausfall der Netzwerkverbindung,
• abgelaufene Authentifizierung,
• blockierte Berechtigungsabfrage,
• Schlafmodus oder unerwartetes Aufwachen,
• volle lokale Speicherkapazität,
• ein Prozess, der nach dem Abbruch weiterläuft.

Eine Wiederherstellungsanleitung sollte beschreiben, wer den Mac erreichen darf, wie eine Sitzung beendet wird und wie ein Workspace vor der Freigabe für den nächsten Auftrag geprüft wird. Dokumentieren Sie außerdem einen lokalen Administratorzugang, der nicht im täglichen Claude-Code-Betrieb verwendet wird.

Entscheidungshilfe: gemeinsam starten oder getrennte Knoten planen?

Die folgende Entscheidungs-Checkliste ist das zentrale Auswahlwerkzeug für Ihren Testlauf. Setzen Sie bei jeder zutreffenden Aussage ein Häkchen. Die Empfehlung am Ende der jeweiligen Zeile beschreibt den nächsten sinnvollen Schritt.

• [ ] Nur eine Person nimmt Aufgaben an, prüft Änderungen und startet Claude Code nacheinander.

Dann wählen Sie: einen Maintainer-Account mit privaten Workspaces und einem vollständigen Aufgabenprotokoll.

• [ ] Mehrere Entwickler arbeiten gelegentlich auf demselben Mac, aber ohne sensible Produktionsdaten.

Dann wählen Sie: getrennte macOS-Accounts, individuelle SSH- und Git-Identitäten sowie eine Warteschlange.

• [ ] Mehrere Repositorys benötigen gleichzeitig eigene Schreibbereiche.

Dann wählen Sie: projektbezogene Workspaces, Laufzeitgrenzen, Abbruchlogik und eine dokumentierte Ressourcenprüfung.

• [ ] Persönliche Zugangsdaten, Kundencode oder Produktionsrechte sind beteiligt.

Dann wählen Sie: getrennte Benutzer- und Dienstidentitäten sowie eine manuelle Freigabe für riskante Aktionen.

• [ ] Aufgaben warten regelmäßig, Projekte konkurrieren um dieselben Ressourcen oder ein Fehler stoppt alle Entwickler.

Dann wechseln Sie: zu getrennten Mac-Knoten oder projektbezogenen Umgebungen.

• [ ] Ein Projekt benötigt physische Schnittstellen, lokale Spezialhardware oder dauerhaft hohe Last.

Dann prüfen Sie: einen eigenen Mac statt einer gemeinsam gemieteten Umgebung.

• [ ] Sie können nicht feststellen, welcher Benutzer einen Prozess gestartet oder eine Datei verändert hat.

Dann stoppen Sie: den Mehrbenutzerbetrieb, bis Konten, Logs und Git-Identitäten getrennt sind.

• [ ] Nach einem Abbruch bleiben Prozesse, temporäre Dateien oder uncommittete Änderungen zurück.

Dann aktivieren Sie: keine weiteren parallelen Aufgaben, bevor Bereinigung und Wiederherstellung getestet sind.

Diese Checkliste ersetzt keinen Belastungstest. Sie verhindert aber, dass Sie eine gemeinsame Ordnerstruktur fälschlich als vollständige Isolation bewerten. Die maximale sinnvolle Parallelität kann erst mit Ihren Repositorys, Builds, Tests, Netzwerkzugriffen und tatsächlichen Claude-Code-Aufgaben beurteilt werden.

Wie müssen Sie die Erweiterung nach dem Test bewerten?

Die Frage „Wie soll ein Team bei vielen Claude-Code-Aufgaben skalieren?“ darf nicht mit einer theoretischen Nutzerzahl beantwortet werden. Die Apple-Hardwaredaten beschreiben den Mac mini, aber sie legen keine sichere Parallelität für Ihre Repositorys, Tests, Netzwerkzugriffe oder Agentenläufe fest. Der offizielle CLI-Leitfaden von Claude Code ist ebenfalls keine Belastungsmessung für Ihre Umgebung.

Führen Sie deshalb einen begrenzten Praxistest mit nicht sensiblen Projekten durch. Erfassen Sie mindestens:

• Wartezeit vom Auftragseingang bis zum Start,
• Laufzeit nach Aufgabentyp,
• Zahl und Dauer von Abbrüchen,
• Konflikte durch gemeinsam genutzte Ressourcen,
• belegten Arbeitsspeicher und lokalen Speicher,
• Netzwerkausfälle und Authentifizierungsfehler,
• Zeit bis zur Wiederherstellung,
• Zahl manueller Eingriffe pro Auftrag.

Werten Sie nicht nur den Durchschnitt aus. Ein einzelner sehr langer Build oder ein hängen gebliebener Prozess kann für die Planung wichtiger sein als viele kurze erfolgreiche Aufgaben. Die reale Repository-Struktur und die verwendeten Tests entscheiden, nicht die Produktbezeichnung M6.

Wenn Wartezeiten dauerhaft steigen, Abbrüche manuelle Bereinigung erfordern, Berechtigungen nur noch über Ausnahmen funktionieren oder ein Ausfall mehrere Projekte gleichzeitig stoppt, ist die Ein-Mac-Architektur organisatorisch überlastet. Teilen Sie dann zunächst nach Projektkritikalität oder Datenempfindlichkeit auf, statt einfach weitere Benutzer in denselben Account aufzunehmen.

Der sinnvollste Test vor einer größeren Beschaffung

Beginnen Sie mit einem nicht sensiblen Repository und einer klar begrenzten Gruppe. Lassen Sie jede Person eine eigene Identität, einen eigenen Branch und einen eigenen Workspace verwenden. Prüfen Sie danach gezielt das Lesen fremder Dateien, die Sichtbarkeit laufender Prozesse, das Verhalten nach Sitzungsabbruch und die Wiederherstellung nach einem Neustart.

Erst wenn diese Tests bestanden sind, sollten Sie sensible Projekte oder unbeaufsichtigte Aufgaben hinzufügen. Halten Sie die Messergebnisse in einer kurzen Betriebsdokumentation fest. Dazu gehören die verwendete macOS-Version, die Claude-Code-Version, Authentifizierungsmethode, Git-Aufbau, Freigaberegeln, Log-Aufbewahrung und der Zeitpunkt des nächsten Reviews. Ändert sich das Berechtigungs- oder Authentifizierungsmodell von Claude Code, müssen Sie die Isolationstests erneut ausführen.

Wenn Sie zunächst eine abgegrenzte Remote-Entwicklungsumgebung prüfen möchten, können Sie die verfügbaren kvmboot-Umgebungen für Ihren Standort als Vergleichspunkt heranziehen. Für organisatorische Fragen zur Bereitstellung ist außerdem der kvmboot-Hilfebereich sinnvoller als eine improvisierte gemeinsame Konfiguration.

Ein selbst verwalteter M6 Mac mini bietet gegenüber einer gemieteten Umgebung maximale Kontrolle über lokale Tools, physische Schnittstellen und langfristig stabile Dauerlast. Dafür tragen Sie Anschaffung, Ersatzgerät, Strom, Remote-Recovery, macOS-Updates, Benutzerverwaltung und den vollständigen Ausfallpunkt selbst. Ein einzelner gemeinsam genutzter Mac ist außerdem keine gute Wahl, wenn mehrere Projekte gleichzeitig strikte Daten- und Verfügbarkeitsgrenzen benötigen.

Für einen zeitlich begrenzten Versuch, wechselnde Teamgrößen oder eine Prüfung mit nicht sensiblen Repositorys kann die Miete von Mac-Umgebungen von kvmboot praktischer sein: Sie vermeiden eine sofortige Hardwarebindung und können projektbezogen erweitern, sobald Warteschlangen, Berechtigungen oder Wiederherstellungsanforderungen den gemeinsamen Knoten überfordern. Entscheidend bleibt, dass Sie auch in einer gemieteten Umgebung getrennte Konten, Zugangsdaten und Arbeitsbereiche einrichten, statt nur mehrere Ordner auf derselben Identität anzulegen.