Was PUID und PGID in Docker Compose bewirken

Was PUID und PGID tatsächlich sind

PUID und PGID sind zwei Umgebungsvariablen, die bestimmte Container-Images beim Start auswerten. Docker selbst berücksichtigt sie nicht. Es handelt sich um eine Konvention, die von linuxserver.io-Images und einigen anderen verwendet wird. Ein Image, das nicht für ihre Auswertung entwickelt wurde, ignoriert sie daher stillschweigend.

In einem linuxserver.io-Image gibt es einen Benutzer namens abc. Er wird beim Erstellen des Images mit der UID (Benutzer-ID) 911 und der GID (Gruppen-ID) 911 angelegt. Der Container startet als root und führt seine Init-Skripte aus. Eines dieser Skripte ändert die IDs dieses Benutzers, bevor etwas anderes geschieht:

groupmod -o -g "${PGID}" abc
usermod -o -u "${PUID}" abc

Das Flag -o erlaubt eine ID, die an anderer Stelle bereits verwendet wird. Danach gibt das Init-Skript die Berechtigungen ab und startet die Anwendung als abc. PUID=1000 erreicht Docker daher nie. Die Variable ändert die ID eines Benutzers innerhalb des Containers, bevor die Anwendung startet. Dadurch wird jede Datei, die die Anwendung schreibt, auf Ihrem Datenträger dem Benutzer 1000 zugeordnet. Wenn PUID nicht gesetzt ist, behält abc die ID 911. Deshalb füllt ein nicht konfiguriertes Bind-Mount das Dateisystem mit Dateien, die 911:911 gehören.

Ermitteln Sie Ihre beiden numerischen Werte mit id

Führen Sie diesen Befehl auf dem Host als der Benutzer aus, dem die Datenverzeichnisse gehören:

id

uid=1000(deploy) gid=1000(deploy) groups=1000(deploy),27(sudo),988(docker)

uid ist Ihre PUID und gid ist Ihre PGID. Für ein Skript geben id -u und id -g nur die Zahlen aus. Bei den meisten frisch installierten VPS-Images lautet das Paar für das erste Benutzerkonto 1000:1000. Gehen Sie jedoch nicht davon aus. Ein neu aufgesetzter Server oder ein später hinzugefügtes zweites Konto verwendet 1001 oder einen höheren Wert. Eine falsche Zahl an dieser Stelle ist die gesamte Fehlerursache. Wenn Ihre Dienste unter einem dedizierten Dienstkonto statt unter Ihrem eigenen Anmeldekonto ausgeführt werden, führen Sie id thatuser aus und übernehmen Sie die Werte von dort.

Warum Ihre Dateien als 911:911 angezeigt werden

ls -l gibt eine numerische ID statt eines Namens aus, wenn kein Konto auf dem Host zu dieser ID passt. Auf Ihrem Server gibt es keine UID 911. Daher kann kein Name ausgegeben werden. Verwenden Sie ls -ln, um immer die Nummern anzuzeigen und die Zuordnung eindeutig zu machen:

ls -ln /srv/appdata/sonarr

drwxr-xr-x 2 911 911 4096 Aug  7 09:12 Backups
-rw-r--r-- 1 911 911  512 Aug  7 09:12 config.xml

Diese Ausgabe zeigt, dass der Container mit den integrierten Standardwerten gestartet wurde. Die Datei config.xml in dieser Auflistung enthält außerdem die Authentifizierungseinstellungen. Das ist wichtig, wenn Sie die Weboberfläche zum ersten Mal öffnen und feststellen, dass Sonarr und Radarr ohne Standardbenutzername und Standardpasswort ausgeliefert werden. Prüfen Sie dies direkt im Container, anstatt zu raten:

docker exec sonarr id abc
docker compose logs sonarr | head -n 25

Die linuxserver-Initialisierung schreibt ihr Ergebnis beim Start als zwei Zeilen in das Startprotokoll:

User UID:    911
User GID:    911

Wenn diese Zeilen 911 anzeigen, nachdem Sie PUID=1000 in Ihrer Compose-Datei gesetzt haben, wurde die Variable nicht an den Container übergeben. Die häufigste Ursache ist, dass Sie docker-compose.yml bearbeitet und anschließend docker compose restart ausgeführt haben. Dabei wird der vorhandene Container mit seiner ursprünglichen Umgebung weiterverwendet. Änderungen an Umgebungsvariablen erfordern docker compose up -d. Dadurch wird der Container neu erstellt.

Warum Sie eine Datei nicht löschen können, die der Container geschrieben hat

Der Kernel vergleicht Zahlen, niemals Namen. Ihre Shell läuft mit der UID 1000. Die Datei gehört der UID 911. Das Verzeichnis, in dem sie liegt, ist drwxr-xr-x und gehört ebenfalls 911. Für Gruppe und andere gelten dort daher Lese- und Ausführungsrechte, aber kein Schreibrecht. Zum Löschen einer Datei benötigen Sie Schreibrechte für ihr Verzeichnis, nicht für die Datei selbst. Deshalb erhalten Sie diese Ausgabe, obwohl die Datei selbst unproblematisch aussieht:

rm: cannot remove '/srv/appdata/sonarr/config.xml': Permission denied

Ein schreibender Container stößt auf dasselbe Problem aus der anderen Richtung. Wenn das Host-Verzeichnis Ihrem Benutzer gehört und den Modus 755 hat, läuft die Anwendung aber mit der UID 911, schlägt ihr erster Schreibversuch mit Permission denied fehl. Die Anwendung meldet den Fehler dann in ihrer eigenen Formulierung. In einer .NET-Anwendung wie Sonarr oder Radarr erscheint er als UnauthorizedAccessException: Access to the path '/data/downloads' is denied. Die Berechtigungszeichenfolge vor dem Dateinamen zeigt, anhand welcher der drei Berechtigungsmengen der Zugriff tatsächlich bewertet wird. drwxr-xr-x korrekt zu lesen macht aus diesem scheinbar rätselhaften Fehler eine eindeutige Ursache.

Dies ist speziell ein Problem von Bind Mounts. Wenn Docker ein leeres benanntes Volume erstellt und es über einen Pfad mountet, der bereits im Image vorhanden ist, kopiert Docker den Inhalt dieses Pfads in das Volume. Dabei werden auch Eigentümer und Berechtigungsbits übernommen. Die Anwendung findet dadurch ein Verzeichnis vor, das ihr bereits gehört. Bei einem Bind Mount geschieht das nicht: Docker mountet Ihr Host-Verzeichnis exakt in seinem aktuellen Zustand. Dieser Unterschied ist einer der praktischen Gründe, zu wissen, wann ein Bind Mount gegenüber einem benannten Volume die bessere Wahl ist und wann nicht.

Ein bereits falsch angelegtes Verzeichnis korrigieren

Das Setzen von PUID und PGID ändert das Verhalten der Anwendung ab diesem Zeitpunkt. Es korrigiert nicht nachträglich die Dateien, die bereits auf dem Datenträger liegen. Stoppen Sie den Stack, korrigieren Sie den Besitz selbst und starten Sie den Stack anschließend wieder:

docker compose down
sudo chown -R 1000:1000 /srv/appdata/sonarr
docker compose up -d

Verwenden Sie sudo chown -R "$(id -u):$(id -g)" /srv/appdata/sonarr, wenn Sie die Zahlen nicht eingeben möchten. Führen Sie den Befehl bei gestopptem Container aus. Eine laufende Anwendung, die während eines rekursiven chown gerade schreibt, kann sonst einen nur teilweise korrigierten Verzeichnisbaum und eine schwer nachvollziehbare zweite Runde von Fehlern hinterlassen.

Was PUID und PGID nicht beheben

Hier liegt der Fall, der Nutzer überrascht, obwohl sie alles richtig gemacht haben. Das linuxserver-Init-Skript ändert beim Start mit chown genau die drei Pfade /app, /config und /defaults. Ihre Media-Mounts gehören nicht dazu. /data, /downloads und /tv werden unverändert an die Anwendung übergeben. Wenn der Host-Pfad dieser Mounts einem Benutzer gehört, für den der Container-Benutzer keine Schreibrechte besitzt, startet der Container fehlerfrei, gibt in seinem Banner die korrekte UID aus und scheitert dann beim ersten Import.

Das ist das richtige Verhalten. Ein rekursives chown über eine zwölf Terabyte große Medienbibliothek bei jedem Containerstart wäre ein schwerwiegendes Problem. Das bedeutet jedoch, dass Sie für die Medienverzeichnisse selbst verantwortlich sind. Genau bei diesen Mounts treten Berechtigungsfehler tatsächlich auf. Solche Fehler erscheinen oft unauffällig erst Stunden später in einem Anwendungslog, obwohl der Container zunächst fehlerfrei wirkte. Ein regelmäßig ausgeführter Schreibtest mit ntfy auf Ihrem eigenen VPS, der Benachrichtigungen an Ihr Telefon sendet ist daher eine einfache Möglichkeit, den Fehler zu erkennen, bevor Ihnen eine Woche fehlender Episoden die Ursache zeigt.

Drei Möglichkeiten zur Steuerung des Benutzers und wann welche verwendet wird

Umgebungsvariablen PUID und PGID

Das funktioniert nur bei Images, deren Entrypoint diese Variablen ausliest. Die Methode ist verbreitet, weil der Container weiterhin als root startet, seine Einrichtung selbst durchführt, /config korrigiert und erst danach die Berechtigungen reduziert. Docker Mods und benutzerdefinierte Init-Skripte funktionieren weiterhin. Der Nachteil ist, dass Sie einer Konvention statt einer Plattformfunktion vertrauen. Außerdem sind die Variablennamen projektübergreifend nicht standardisiert.

Der Schlüssel user: in Compose

Dies ist eine echte Docker-Funktion und funktioniert mit jedem Image, weil die Container-Laufzeit die Einstellung anwendet, bevor der eigene Code des Images ausgeführt wird:

services:
  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    user: "1000:1000"

Der Prozess läuft niemals als root, auch nicht kurzzeitig. Das ist ein echter Sicherheitsgewinn. Gleichzeitig funktionieren alle Bestandteile des Entrypoints nicht mehr, die root benötigen. Bei linuxserver-Images unterstützt das Projekt diese Methode nach bestem Bemühen und nur für Images, die es getestet hat. Die Einschränkungen sind konkret: PUID und PGID haben keine Wirkung mehr, Docker Mods werden nicht ausgeführt, benutzerdefinierte Dienste werden nicht ausgeführt, und Sie sind für die Berechtigungen auf allen eingebundenen Volumes verantwortlich. Das dokumentierte Muster kombiniert das Flag mit einem beschreibbaren /run:

user: 1000:1000
tmpfs:
  - /run:uid=1000,gid=1000,exec
security_opt:
  - no-new-privileges=true

Ein kosmetischer Nebeneffekt überrascht viele Benutzer. Ein numerischer user: hat keinen passenden Eintrag in /etc/passwd des Containers. Deshalb zeigen Tools im Container whoami: cannot find name for user ID 1000 an. Die ID ist gültig, und der Dateizugriff funktioniert normal. Nur die Namensauflösung schlägt fehl.

Rootless Docker

Rootless Docker führt den Daemon selbst als Ihr nicht privilegierter Benutzer aus. Dadurch läuft auf dem System nichts als echter root. Das ändert die Zuordnung der Besitzrechte grundlegend. Die Container-UID 0 wird auf die Host-UID des Benutzers abgebildet, der Rootless Docker ausführt. Die Container-UID n für jeden n von 1 oder höher wird auf subuid + (n - 1) abgebildet. Dabei ist subuid die Basis des Ihnen zugewiesenen Bereichs in /etc/subuid und /etc/subgid. Docker erwartet dort mindestens 65,536 untergeordnete IDs.

Lesen Sie diese Zuordnung noch einmal, denn sie kehrt die übliche Empfehlung um. Bei Rootless Docker erzeugt ein Container, der als root schreibt, Dateien, die Ihnen gehören. Ein Container, der als UID 1000 schreibt, erzeugt Dateien, die einer untergeordneten ID im Bereich um 100999 gehören. Ihre Shell kann auf diese Dateien nicht zugreifen. Der PUID-Wert, der bei einem rootful Daemon korrekt ist, ist hier daher falsch. Beide Mechanismen lösen dasselbe Problem auf unterschiedlichen Ebenen. Wenn Sie sie ohne Prüfung kombinieren, kann ein Verzeichnis entstehen, für dessen Entfernung Sie sudo benötigen. Wenn Sie Rootless Docker verwenden, testen Sie auf Ihrem eigenen Server zunächst den Besitz einer geschriebenen Datei, bevor Sie eine Bibliothek dorthin migrieren.

Für die meisten selbst gehosteten Stacks auf einem einzelnen VPS ist PUID und PGID bei einem rootful-Daemon die pragmatische Wahl, weil die Images dafür erstellt und dokumentiert sind. Verwenden Sie user:, wenn die README des Images angibt, dass das Image dafür getestet ist, oder wenn Sie ein offizielles Upstream-Image ausführen, das überhaupt keine PUID-Unterstützung bietet. Ein Dokumentenarbeitsbereich wie eine selbst gehostete AFFiNE-Instanz auf einem VPS fällt in den letzten Fall, weil keiner seiner Container PUID ausliest und die Eigentümerschaft seines Datenbankverzeichnisses und der hochgeladenen Dateien zur Laufzeit festgelegt wird und nicht durch Einträge im Environment-Block. Dasselbe gilt für einen selbst gehosteten Chatwoot-Supportdesk, bei dem der Rails-Container und sein Sidekiq-Worker beide in ein gemeinsames Upload-Verzeichnis schreiben und keiner von ihnen PUID ausliest. Daher muss dieses Verzeichnis dem Benutzer gehören, unter dem das Image bereits ausgeführt wird. Das ändert sich auch bei einem neueren Stack nicht. Wenn Sie also für jede Person im Team einen eigenen isolierten OneCLI-Agent bereitstellen, gehören die Workspace-Verzeichnisse der einzelnen Personen und das Postgres-Datenverzeichnis weiterhin dem Benutzer, unter dem das jeweilige Image bereits ausgeführt wird. Damit handelt es sich um ein user:- und chown-Problem und nicht um ein PUID-Problem. Setzen Sie eine einzelne selbst gehostete API vor Codex, Claude Code und Hermes, übernehmen Sie dieselbe Struktur. Dieses Image wird unter seinem eigenen integrierten Benutzer ausgeführt. Der Bind-Mount mit seiner Datenbank und den gespeicherten Schlüsseln übernimmt daher die Eigentümerschaft dieses Benutzers.

Der Media-Stack-Fall: eine gemeinsame Gruppe für alle Container

Ein Arr-Media-Stack mit Sonarr, Radarr und einem Download-Client zeigt, wann dieses Konzept praktisch relevant wird. Der Download-Client schreibt eine fertige Datei nach /data/downloads. Sonarr erstellt anschließend einen Hardlink auf diese Datei oder verschiebt sie nach /data/media. Damit der Hardlink funktioniert, benötigen beide Container Schreibzugriff auf denselben Verzeichnisbaum. Wenn der Download-Client mit 1000 und Sonarr mit 1001 läuft, besitzt jeweils einer der beiden Dateien, die der andere nur lesen kann.

Die Lösung ist eine gemeinsame Gruppe, die jeder Container im Stack als PGID verwendet:

sudo groupadd -g 13000 media
sudo usermod -aG media deploy
sudo chown -R deploy:media /srv/media
sudo find /srv/media -type d -exec chmod 2775 {} +
sudo find /srv/media -type f -exec chmod 0664 {} +

Das führende 2 in 2775 ist das setgid-Bit. Bei einem Verzeichnis bedeutet es, dass jede darin erstellte Datei und jedes Unterverzeichnis die Gruppe media statt der primären Gruppe des Erstellers erbt. Dadurch funktioniert die Konfiguration auch für neue Downloads, ohne dass Sie chown erneut ausführen müssen. Melden Sie sich ab und wieder an oder führen Sie newgrp media aus, bevor Sie Ihren eigenen Zugriff prüfen. Eine mit usermod -aG hinzugefügte Gruppe erscheint nicht in einer bereits geöffneten Shell-Sitzung.

Im Container nummeriert groupmod -o -g 13000 abc die Gruppe abc auf 13000 um. Dadurch schreibt abc mit derselben GID wie Ihre media-Gruppe auf dem Host. Jeder Container im Stack behält seine eigene PUID und verwendet diese eine gemeinsame PGID. Das gilt auch für die Container weiter unten in der Verarbeitungskette, die die fertige Bibliothek nur lesen, beispielsweise Jellyfin selbst und Frontends, die darauf aufsetzen, etwa Halcyon, das diese Bibliothek als begehbaren Videoladen der 90er präsentiert.

Setzen Sie anschließend UMASK=002 für jeden linuxserver-Container im Stack. Dieser Schritt wird häufig übersehen. Der Standardwert in diesen Images ist UMASK=022. Er entfernt bei jeder neuen Datei das Gruppenschreibrecht. Die Dateien werden dadurch als 0644 angelegt, und die soeben konfigurierte gemeinsame Nutzung funktioniert nicht. 002 erzeugt 0664-Dateien und 0775-Verzeichnisse, auf die die Gruppe schreiben kann:

services:
  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    container_name: sonarr
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=002
      - TZ=Etc/UTC
    volumes:
      - /srv/appdata/sonarr:/config
      - /srv/media:/data
    restart: unless-stopped

Diese beiden Werte gehören in eine .env-Datei neben die Compose-Datei. Dadurch verwendet der gesamte Stack dieselbe Definition:

PUID=1000
PGID=13000

Compose liest diese Datei automatisch für die Substitution im Stil von ${PUID} ein. Das ist derselbe Mechanismus, den Sie für Zugangsdaten verwenden. Die Regeln zum Ablegen von Werten außerhalb von docker-compose.yml in einer .env-Datei gelten auch hier. Der Unterschied besteht darin, dass diese beiden Zahlen keine Geheimnisse sind.

Prüfen Sie die Konfiguration vollständig, statt ihr nur zu vertrauen. Schreiben Sie aus einem Container eine Datei und lesen Sie sie auf dem Host:

docker exec sonarr touch /data/downloads/permtest
ls -ln /srv/media/downloads/permtest

Ein korrektes Ergebnis zeigt Ihre PUID als Eigentümer, 13000 als Gruppe und -rw-rw-r-- als Modus. Wenn die Gruppe 1000 anzeigt, fehlt das setgid-Bit für dieses Verzeichnis. Wenn der Modus -rw-r--r-- anzeigt, wurde die Variable UMASK nicht übernommen. Prüfen Sie dann, ob Sie den Container neu erstellt und nicht nur neu gestartet haben. Entfernen Sie die Testdatei anschließend mit rm /srv/media/downloads/permtest.

Welche Images verwenden welche Variable

linuxserver.io-Images verwenden PUID, PGID und UMASK. Paperless-ngx verwendet für dasselbe Konzept andere Namen: USERMAP_UID und USERMAP_GID, beide standardmäßig mit dem Wert 1000. In der Dokumentation wird angegeben, dass Sie diese Werte aus id -u und id -g auslesen sollen. Bei Fotoservern gibt es ebenfalls unterschiedliche Varianten: PhotoPrism verwendet ein eigenes Paar aus PHOTOPRISM_UID und PHOTOPRISM_GID, während Immich kein entsprechendes Gegenstück mitliefert. Stattdessen verwendet der Container den Docker-Schlüssel user:. Die Entscheidung zwischen PhotoPrism und Immich bestimmt daher auch, welchen dieser Mechanismen Sie für die größte Bibliothek auf dem Server verwalten müssen. Viele offizielle Upstream-Images, darunter gängige Images für Datenbanken und Webserver, verwenden einen fest integrierten Benutzer. Sie erwarten, dass Sie user: verwenden oder die Vorgabe unverändert lassen. Bei kleinen Bereitstellungen mit nur einer Anwendung stellt sich dieselbe Frage. Wenn Sie beispielsweise einen selbst gehosteten openGym-Workout-Tracker einrichten, sollten Sie prüfen, unter welchem Benutzer der Container tatsächlich ausgeführt wird, bevor Sie einen Bind-Mount darauf verweisen. Das Verzeichnis mit der Datenbank übernimmt diese Vorgabe, unabhängig davon, ob Sie PUID setzen. Auch ein Relay für den Fernzugriff fällt in diese Kategorie. Wenn Sie Ihren eigenen RustDesk-Relay-Server betreiben, wird das Ed25519-Schlüsselpaar, das hbbs beim ersten Start schreibt, in Ihrem Bind-Mount mit dem Benutzer angelegt, unter dem das Image endet. Auf der Host-Seite steht Ihnen dann nur chown als Korrektur zur Verfügung. Dasselbe gilt für später ergänzte Infrastruktur. Wenn Sie Authentik als zentrale Anmeldung vor Ihre Anwendungen setzen, führen Sie offizielle Images für den Server, Postgres und Redis aus, die PUID überhaupt nicht auslesen. Die Eigentümerschaft ihrer Volumes wird dann durch die Laufzeit und nicht durch einen konfigurierbaren Entrypoint bestimmt.

Prüfen Sie daher die README jedes Images, bevor Sie einen Umgebungsblock zwischen Projekten kopieren. Docker übergibt jede von Ihnen gesetzte Umgebungsvariable an jeden Container, unabhängig davon, ob sie innerhalb des Containers ausgelesen wird. Ein PUID, das von keinem Prozess verwendet wird, erzeugt keinen Fehler, keine Warnung und keine Wirkung. Der Container wird unter dem Benutzer ausgeführt, den das eigene Dockerfile zuletzt festlegt. Das erkennen Sie an der Eigentümerschaft der von ihm geschriebenen Dateien. Führen Sie diese Prüfung durch, bevor Sie etwas Neues auf dem Server einrichten. Das gilt auch für einen selbst gehosteten open-kritt-Sicherheits-Scan-Stack. In dessen Compose-Datei sehen Sie, ob die Images PUID unterstützen oder ob die Eigentümerschaft der eingebundenen Verzeichnisse durch die Images selbst festgelegt wird.

FAQ

Warum gehören meine Docker-Dateien 911:911?

911 ist die UID und GID des in abc-Images von linuxserver.io integrierten Benutzers. Das bedeutet, dass der Container ohne gesetzte Werte für PUID und PGID gestartet wurde und sein Init-Skript daher die integrierten Standardwerte beibehalten hat. ls -l zeigt die numerischen Werte an, weil auf Ihrem Host kein Konto die ID 911 besitzt und daher kein Name angezeigt werden kann. Setzen Sie PUID und PGID auf die Ausgabe von id, erstellen Sie den Container mit docker compose up -d neu und korrigieren Sie anschließend die vorhandenen Dateien im betroffenen Verzeichnis mit sudo chown -R 1000:1000.

Funktionieren PUID und PGID mit jedem Docker-Image?

Nein. Sie sind keine Docker-Funktion, und Docker liest sie niemals aus. Sie funktionieren nur bei Images, deren eigenes Entrypoint-Skript sie ausliest und vor dem Start der Anwendung usermod und groupmod aufruft. Dazu gehört die linuxserver.io-Familie sowie einige Projekte, die dieses Muster übernommen haben. Andere Projekte verwenden andere Namen, beispielsweise USERMAP_UID und USERMAP_GID in paperless-ngx. Bei einem Image, das keine dieser Variablen ausliest, werden sie ohne Warnung akzeptiert und ignoriert.

Sollte ich PUID und PGID oder den user:-Schlüssel in Docker Compose verwenden?

Verwenden Sie PUID und PGID, wenn das Image diese unterstützt. Das Entrypoint-Skript läuft dann weiterhin lange genug als root, um /config zu korrigieren und die eigenen Dienste korrekt zu starten. Verwenden Sie user:, wenn das Image PUID nicht unterstützt oder wenn die README des Images den Betrieb ohne root als getestet ausweist. Bei einem linuxserver-Image macht das Setzen von user: PUID und PGID wirkungslos, verhindert die Ausführung von Docker Mods und benutzerdefinierten Diensten und überlässt Ihnen die Verantwortung für die Berechtigungen aller eingebundenen Volumes.

Sonarr hat die richtige PUID, kann Dateien aber weiterhin nicht verschieben. Woran liegt das?

Prüfen Sie drei Punkte in dieser Reihenfolge. Erstens das Media-Mount selbst: Das Init-Skript ändert nur den Eigentümer von /app, /config und /defaults. Daher behält /data oder /downloads die Eigentumsverhältnisse des Hosts bei. Zweitens die gemeinsame Gruppe: Wenn Download-Client und Sonarr unter unterschiedlichen GIDs laufen, kann keiner die Dateien des anderen ändern. Weisen Sie daher jedem Container im Stack dieselbe PGID zu. Drittens die umask: Der Image-Standardwert UMASK=022 erstellt Dateien mit den Berechtigungen 0644 ohne Gruppen-Schreibrecht. Dadurch kann eine gemeinsame Gruppe nicht genutzt werden. Setzen Sie UMASK=002 und setzen Sie das setgid-Bit für die Verzeichnisse mit chmod 2775, damit neue Dateien die Gruppe erben.