Nextcloud ist der Schlüssel eures Kreis-Systems: Hier liegen die Dateien, hier melden sich eure Mitglieder an (Identity), hier läuft Talk. Dieses Kapitel beschreibt, wie ihr eine Kreis-Nextcloud aufsetzt und so strukturiert, dass sie ohne hauptamtliche IT betreibbar bleibt. Alles hier Beschriebene läuft produktiv in der Referenz-Installation von WJ Konstanz-Hegau (Server "hafen", Nextcloud 34.0.2, Stand 2026-08-13) und wurde einmal komplett repliziert (Demo-Instanz für WJ Hochrhein). Die Struktur ist also nicht Theorie, sondern zweimal gebauter Ist-Zustand.
Die Architektur-Regel aus Kapitel 01 gilt durchgehend: VereinOnline bleibt System of Record für Mitglieder und Events. Nextcloud hält keine eigene Mitgliederverwaltung, sondern Dateien, Accounts und Kommunikation.
1. Server-Anforderungen
Die Referenz läuft auf einem Hetzner-Cloud-Server mit Ubuntu 24.04, Apache als Webserver und Let's-Encrypt-Zertifikaten. Für einen einzelnen Kreis mit Nextcloud, Talk-Hochleistungs-Backend (HPB) und Collabora rechnet ihr mit ca. 5 bis 10 Euro pro Monat für einen eigenen Cloud-Server im Hetzner-Account des Kreises.
Was ihr vor dem ersten Befehl entscheiden müsst (Rollout-Checkliste aus der Hochrhein-Anbahnung):
- Server-Ownership: eigener Hetzner-Account des Kreises (empfohlen) oder Mitnutzung eines bestehenden Servers. Achtung: Echte Mitgliederdaten gehören aus DSGVO-Sicht auf einen Server im Verantwortungsbereich des eigenen Vereins, nicht auf den Co-Tenant eines anderen Kreises.
- Domain und DNS-Verwaltung: Legt von Anfang an die finale Domain fest. Wer mit einer Übergangs-Domain startet, baut sich einen Umzug ein; mit finaler Domain ist ein späterer Serverwechsel nur rsync plus DB-Dump plus DNS-Flip.
- Scope: Kern ist Nextcloud + Talk-HPB + Collabora (+ Whiteboard). Kompetenz-Hub, eigene n8n-Instanz und Analytics sind kreisspezifische Extras.
- Langfrist-Admin: zentraler Admin mit SSH-Zugang oder der Kreis selbst mit Übergabe-Doku.
Kapazitäts-Erfahrungswert: Auf der Referenz-Maschine waren nach dem Aufbau der zweiten (Demo-)Instanz noch 2,7 GB RAM frei; ein Server dieser Klasse trägt also eine Instanz komfortabel, zwei mit Ach und Krach, drei nicht. Erweiterungen wie Talk-Recording plus lokales Whisper-STT brauchen zusätzlich ca. 8 GB RAM und damit eine größere Maschine.
Das Netzwerk-Muster der Referenz gilt als Standard: Alle Dienste binden nur auf 127.0.0.1 und werden über Apache-vHosts mit TLS nach außen gereicht. Einzige Ausnahme ist TURN/STUN für Talk (Port 3478 tcp/udp öffentlich, siehe Kapitel Talk).
2. Zwei Wege zur Installation
Es gibt zwei belegte Wege, beide laufen produktiv:
Weg A: Docker Compose (Empfehlung für neue Kreise). So ist die Hochrhein-Demo gebaut: ein Compose-Stack aus nextcloud:stable-apache, postgres:16-alpine und redis:alpine, gebunden an 127.0.0.1 (Demo: Port 8085), davor ein Apache-vHost als Reverse Proxy mit Let's-Encrypt-Zertifikat. Secrets entstehen serverseitig in einer .env (chmod 600, per openssl rand generiert) und landen nie im Repo oder in einer Session. Für den Betrieb hinter dem Proxy sind OVERWRITEHOST, OVERWRITEPROTOCOL=https, TRUSTED_PROXIES und APACHE_DISABLE_REWRITE_IP gesetzt. Der komplette Weg ist geskriptet (Repo wj/Nextcloud/wjhcloud-demo/):
| Script | Was es tut |
|---|---|
bootstrap.sh | legt das Verzeichnis an, generiert .env, docker compose up -d, aktiviert den vHost, wartet auf status.php mit "installed":true, holt das Zertifikat via certbot |
post-install.sh | Basiskonfig (default_phone_region DE, maintenance_window_start), SMTP-Übernahme, Admin-User mit generiertem Passwort (nur serverseitig abgelegt) |
setup-demo-11.sh | Apps, Gruppen, Gruppenordner-Matrix, Collabora-Anbindung; occ läuft via docker exec -u www-data <container> php occ |
Warum Docker die Empfehlung ist: reproduzierbar aus Scripts, sauber getrennte Datenhaltung (DB, Redis, App-Volume), und der Umzug auf einen anderen Server ist ein Volume-Transfer statt einer Server-Archäologie.
Weg B: Bare-metal (die historische Referenz). So läuft hafen selbst: Nextcloud unter /var/www/html, Apache direkt, PHP 8.3. Das funktioniert und ist mit setup-wj-nextcloud.sh ebenfalls geskriptet (occ via sudo -u www-data php /var/www/html/occ), aber es ist gewachsener Zustand. Für neue Kreise gibt es keinen Grund, diesen Weg zu wählen; er ist dokumentiert, damit die Referenz nachvollziehbar bleibt.
In beiden Wegen ist das Struktur-Setup (Abschnitte 4 bis 6) identisch, nur der occ-Aufruf unterscheidet sich (docker exec vs. sudo). Die Setup-Scripts sind idempotent gebaut: gefahrlos wiederholbar, jeder Lauf stellt den Soll-Zustand her.
Ein Hinweis zur Parametrisierung: Die vorhandenen Scripts tragen noch Konstanz-Hegau-spezifische Werte (Domain, Kreisname, Usernamen der Gruppen-Leads). Für euren Kreis ersetzt ihr diese Werte; eine parametrisierte Fassung ist als Ausbaustufe des Standards vorgesehen.
3. Apps-Grundausstattung
Die Referenz fährt 70 aktivierte Apps; das meiste davon ist Nextcloud-Serienausstattung. Installieren müsst ihr gezielt die tragenden Apps des Standards:
| App | Rolle |
|---|---|
| groupfolders | Team-Ordnerstruktur mit Rechte-Matrix (das Rückgrat, Abschnitt 5) |
| spreed (Talk) | Videokonferenz und Chat (eigenes Kapitel) |
| richdocuments | Collabora-Anbindung, Office im Browser (eigenes Kapitel) |
| calendar, contacts, tasks, notes, mail | Grundausstattung Zusammenarbeit |
| forms | Umfragen und Anmeldungen |
| polls | Terminfindung |
| deck | Kanban-Boards für Ressorts und Projekte |
| guests | Gast-Accounts für Externe (Abschnitt 7) |
| twofactor_totp, twofactor_webauthn | 2FA-Provider (Abschnitt 8) |
| files_automatedtagging | Auto-Tagging für DSGVO-Tags (Abschnitt 6) |
| whiteboard | Whiteboard (braucht einen eigenen Container, optional) |
| notify_push | Push statt Polling für Client-Sync (optional, braucht systemd-Service plus Apache-Proxy /push; Gotcha: trusted_proxies muss die eigene Public-IP enthalten, sonst scheitert der interne Loop) |
| oidc | Nextcloud als Identity Provider für weitere Kreis-Dienste (optional; auf der Referenz live, die Einrichtung ist aber noch nicht als eigenes Kapitel dokumentiert, siehe meta/qa-luecken.md) |
| webhook_listeners | Webhooks Richtung Flow/n8n (optional; im Standard bislang ungenutzt, alle Referenz-Flows arbeiten pull-basiert) |
Sicherheits-Apps, die in der Referenz aktiv sind und die ihr aktiviert lassen solltet: admin_audit, bruteforcesettings, password_policy, suspicious_login, twofactor_backupcodes.
4. Standard-Gruppenstruktur
Das Benennungs-Prinzip der Referenz: Gruppen heißen nach Themen, nicht nach Organisationsform. Also Events, nicht AK_Events. Der Grund ist Rotationssicherheit: Wenn ein Arbeitskreis zur Stabsstelle wird oder dieselbe Person das Ressort wechselt, bleibt die Gruppe stabil und nur die Mitgliedschaften ändern sich.
Drei Schichten von Gruppen, dazu technische Gruppen:
Rollen-Gruppen: admin (technische Administration), Vorstand (Vorstand und Geschäftsführung), Finanzen.
Themen-Gruppen (Ressorts und Arbeitskreise, Auswahl nach eurer Kreisstruktur): Mitglieder_Interessenten, Technik_Digitales, Kommunikation, Internationales, Events, dazu AK-Gruppen wie in der Referenz A-Team und Projektgruppen wie LAKO_2029.
Breite Mitglieder-Gruppen: Aktive_Mitglieder (alle aktiven Mitglieder), Interessenten (noch keine Mitglieder), Foerderer (Fördermitglieder). Diese drei steuern, wie weit Lesezugriff in die Breite geht.
Technische Gruppen: Automation für den Service-User des n8n-Kuriers (in der Referenz wj-bot, eigenes Kapitel), plus die Gruppen, die Integrationen selbst anlegen (in der Referenz OpenProject und guest_app).
5. Gruppenordner 01 bis 09 mit Rechte-Matrix
Die Arbeit findet in Gruppenordnern (Group Folders) statt, nicht in persönlichen Dateien. Neun nummerierte Ordner bilden die Kreisarbeit ab. Die Rechte-Matrix stammt wörtlich aus dem Live-Inventar der Referenz-Installation (Stand 2026-08-13). Permission-Codes: 31 = Vollzugriff (lesen, schreiben, anlegen, löschen, teilen), 1 = nur lesen, leer = kein Zugriff. Alle Ordner laufen mit separate-storage: true und Quota unbegrenzt (-3).
| # | Mountpoint | ACL | admin | Vorstand | Finanzen | Mitgl_Int | Technik_Dig | Kommunikation | Internationales | A-Team | Events | Aktive_Mitgl | Interessenten | Foerderer | Automation |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 01_Allgemeines & Vorlagen | nein | 31 | 31 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | ||
| 2 | 02_Vorstand & Geschaeftsfuehrung | nein | 31 | 31 | |||||||||||
| 3 | 03_Finanzen | nein | 31 | 1 | 31 | ||||||||||
| 4 | 04_Mitglieder & Interessenten | nein | 31 | 31 | 31 | ||||||||||
| 5 | 05_Stabsstellen | ja | 31 | 1 | 1 | 1 | 1 | 1 | |||||||
| 6 | 06_Arbeitskreise | ja | 31 | 1 | 1 | 1 | |||||||||
| 7 | 07_Sonderprojekte | ja | 31 | 1 | 1 | ||||||||||
| 8 | 08_Archiv | nein | 31 | 31 | 1 | ||||||||||
| 9 | 09_Fotos | nein | 31 | 31 | 1 | 1 | 1 | 31 |
(In der Referenz existiert zusätzlich ein zehnter Gruppenordner OpenProject als exklusiver Mount der OpenProject-Integration; er gehört nicht zum Kern-Standard.)
Die Logik hinter der Matrix in drei Sätzen: 01_Allgemeines & Vorlagen liest der ganze Kreis bis hinunter zu Interessenten, schreiben tut der Vorstand. 02 bis 04 sind geschlossene Bereiche der jeweiligen Rolle, wobei der Vorstand in 03_Finanzen bewusst nur liest (Transparenz ohne Durchgriff, die Finanzen-Gruppe arbeitet). 09_Fotos ist der einzige Ordner mit Schreibrecht für die Automation-Gruppe (der n8n-Kurier legt dort Event-Foto-Ordner an) und mit Leserecht bis zu Interessenten und Förderern.
Advanced Permissions (ACL) auf 05, 06 und 07. Diese drei Ordner fahren "Mode B": Am Ordner-Root haben die operativen Gruppen nur READ (Code 1 in der Matrix), WRITE/SHARE/DELETE bekommt jede Gruppe per Advanced Permissions nur am eigenen Unterordner. Effekt: Lese-Transparenz über alle Stabsstellen und Arbeitskreise hinweg, Schreib-Isolation im eigenen Bereich. Aktiviert wird das via occ groupfolders:permissions --enable. Das Regelwerk dazu: Bei Konflikt auf demselben Pfad schlägt ALLOW das DENY; ein DENY am Group-Folder-Root ist dagegen harter Boden und lässt sich nicht per Sub-ALLOW überschreiben. acl_default_no_permission bleibt überall false.
Unterordner legt ihr per WebDAV MKCOL an (idempotent, HTTP 405 heißt "existiert schon"), nicht per Filesystem-mkdir: Nextcloud indexiert direkt ins Dateisystem gelegte Ordner ohne files:scan nicht. Dasselbe gilt für Demo- oder Startinhalte: per WebDAV-PUT hochladen, nicht per docker cp in __groupfolders/.
6. Feinschliff nach dem Struktur-Setup
Quota-Strategie: Da die Arbeit in Gruppenordnern stattfindet (deren Quota unbegrenzt ist), bleibt die persönliche Files-Nutzung klein: Default-Quota 250 MB für normale User, unbegrenzt für Vorstand und admin.
Aufgeräumter Start für neue User: skeletondirectory und templatedirectory leer setzen (keine Nextcloud-Demo-Ordner für neue Accounts), defaultapp auf files.
DSGVO-System-Tags: Drei Tags per occ tag:add anlegen: "Vertraulich (DSGVO)" als restricted, "Streng vertraulich" als invisible, "Öffentlich" als public. Dazu Auto-Tagging-Regeln über die Workflow Engine (App files_automatedtagging). Gotcha aus der Praxis: Der "Dateiname"-Check der Workflow Engine matcht nur den Basename; wer nach Pfaden taggen will, muss den Filter auf "Anfrage-URL" (RequestURL) stellen, sonst feuern die Regeln nie.
Basiskonfig: default_phone_region auf DE, maintenance_window_start setzen, SMTP für Systemmails konfigurieren (die Demo übernimmt die SMTP-Konfiguration Key für Key aus der Haupt-Instanz, ohne Werte auszugeben).
Background-Jobs auf Cron: Stellt die Nextcloud-Hintergrundjobs auf den Cron-Modus (occ background:cron) mit einem System-Cron alle 5 Minuten als www-data (bare-metal) bzw. einem Host-Cron mit docker exec -u www-data <container> php cron.php (Docker-Weg). Der AJAX-Default läuft nur, wenn gerade jemand die Weboberfläche offen hat, und lässt sonst Erinnerungen, Mail-Abruf und Aufräumjobs liegen. Ehrlicher Hinweis: Dieser Punkt ist im Demo-Compose-Stack der Referenz noch nicht als Script abgedeckt und auf der Haupt-Instanz nicht verifiziert erhoben (offener Punkt im Live-Inventar).
7. Gäste-Konzept
Externe (Referentinnen, Sponsoren, Partner-Kreise) bekommen keinen Mitglieder-Account, sondern einen von drei abgestuften Zugängen:
- Gast-Account (App guests): ein echter Login mit stark eingeschränktem App-Zugriff, technisch in der Gruppe
guest_app. Richtig für Externe, die über längere Zeit an konkreten Dateien mitarbeiten. Gäste sind nie Mitglied in den Standard-Gruppen und tauchen damit in keiner Zeile der Rechte-Matrix auf; sie sehen nur, was ihnen explizit geteilt wird. - Link-Share: der normale Freigabe-Link für Einzeldateien und -ordner, bei Bedarf mit Passwort, Ablaufdatum und Download-Limit (App files_downloadlimit).
- File-Drop: ein Upload-only-Link (OCS-Share mit Permission 4: anlegen ja, lesen nein). Das ist das Foto-Drop-Pattern der Referenz: Teilnehmende laden Event-Fotos in einen Ordner unter
09_Fotoshoch, ohne die Fotos der anderen zu sehen. Ablauf, Passwort und Label lassen sich per OCS-API nachträglich setzen.
Für Fördermitglieder und Interessenten gilt: Sie sind keine Gäste, sondern haben eigene Gruppen mit gezieltem Leserecht (siehe Matrix: 01_Allgemeines & Vorlagen und 09_Fotos).
Ergänzendes Muster für Gremien-Vertraulichkeit: Talk-Räume für Gremien werden mit Einzeluser-Invites statt Gruppen-Invites angelegt. Wer später einer AK-Gruppe beitritt, landet so nicht automatisch im Gremien-Raum; die Raum-Leitung behält die Kontrolle.
8. 2FA-Rollout
Beide 2FA-Provider gehören zur Grundausstattung: twofactor_webauthn (Passkeys, Empfehlung) und twofactor_totp (Authenticator-Apps, Alternative), dazu twofactor_backupcodes für den Notfall-Zugang.
Der empfohlene Rollout in drei Stufen:
- Provider installieren und Anleitung verteilen. Die Referenz hat eine fertige Rollout-Anleitung für den Vorstand (WebAuthn/Passkey bevorzugt, TOTP als Alternative); schreibt eine kreiseigene Fassung oder übernehmt das Muster.
- Pflicht für privilegierte Accounts: Vorstand und Schatzmeister zuerst, danach Stabsstellen. Setzt euch dafür Fristen und verfolgt sie nach. Ehrlicher Erfahrungswert aus der Referenz: Dort sind TOTP und WebAuthn installiert, aber nicht enforced (Opt-in je User), und die intern gesetzten Rollout-Fristen für Vorstand (2026-05-15) und Stabsstellen (2026-06-30) wurden gerissen. Ohne Enforcement bleibt 2FA ein Vorsatz.
- Enforcement-Entscheidung explizit treffen. Nextcloud kann 2FA gruppenweise erzwingen. Ob ihr das für
adminundVorstandscharf schaltet, ist eine Vorstandsentscheidung, keine Technikfrage; der Standard empfiehlt es. Entscheidet es bewusst und protokolliert die Entscheidung.
Checkliste
Vorbereitung:
- Server-Ownership entschieden (eigener Hetzner-Account des Kreises)?
- Finale Domain festgelegt, A-Record zeigt auf den Server?
- Scope entschieden (Kern: NC + Talk-HPB + Collabora)?
- Langfrist-Admin benannt?
Installation (Weg A, Docker):
- Compose-Stack (nextcloud:stable-apache, postgres:16-alpine, redis:alpine) bindet nur auf 127.0.0.1?
.envserverseitig generiert, chmod 600, kein Secret im Repo oder in einer Chat-Session?OVERWRITEHOST,OVERWRITEPROTOCOL,TRUSTED_PROXIESgesetzt?- Apache-vHost aktiv, Let's-Encrypt-Zertifikat geholt,
status.phpmeldet"installed":true? default_phone_region,maintenance_window_start, SMTP gesetzt; Admin-Passwort nur serverseitig abgelegt?
Struktur:
- Tragende Apps aus Abschnitt 3 installiert und aktiviert?
- Gruppen angelegt (Rollen-, Themen-, breite Mitglieder-, technische Gruppen), Namen ohne AK_/Stab_-Präfix?
- Gruppenordner 01 bis 09 angelegt, Rechte exakt nach der Matrix in Abschnitt 5 gesetzt?
- Advanced Permissions auf 05, 06, 07 aktiviert (
occ groupfolders:permissions --enable), Schreibrechte je Gruppe nur am eigenen Unterordner? - Unterordner per WebDAV MKCOL angelegt (nicht per Filesystem-mkdir)?
- Default-Quota 250 MB gesetzt, unbegrenzt für Vorstand/admin?
skeletondirectory/templatedirectoryleer,defaultapp = files?- DSGVO-Tags angelegt, Auto-Tagging-Regeln mit RequestURL-Filter (nicht Dateiname)?
Sicherheit:
- Sicherheits-Apps aktiv (admin_audit, bruteforcesettings, password_policy, suspicious_login)?
- 2FA-Provider installiert (WebAuthn + TOTP + Backup-Codes)?
- 2FA-Pflicht für admin/Vorstand entschieden und protokolliert? Fristen gesetzt?
- Gäste-Konzept kommuniziert (Gast-Account vs. Link-Share vs. File-Drop)?
Referenz KNH
So läuft es bei Konstanz-Hegau konkret (Live-Inventar 2026-08-13):
- Server: "hafen", Hetzner, Ubuntu 24.04,
hafen.wj-konstanz-hegau.de. Nextcloud 34.0.2 bare-metal unter/var/www/htmlmit Apache und PHP 8.3 (historischer Weg B). Alle Dienste außer TURN/STUN binden auf 127.0.0.1 hinter Apache-vHosts mit Let's-Encrypt-TLS. - Zweitinstanz als Beleg für Weg A: Die Hochrhein-Demo (
wjhcloud.wjknh.de) läuft als Docker-Compose-Stack in/srv/wjhcloudauf demselben Server (Port 127.0.0.1:8085) und wurde komplett per Script aufgebaut; Collabora und Talk-HPB werden von der Hauptinstanz mitgenutzt. - Apps: 70 aktivierte Apps, darunter alle tragenden Apps aus Abschnitt 3; OpenProject-Integration als kreisspezifisches Extra.
- Gruppen: 17 Gruppen nach dem Schema aus Abschnitt 4, inklusive Projektgruppe
LAKO_2029und der technischen GruppenAutomation(Service-User wj-bot),OpenProjectundguest_app. - Gruppenordner: 01 bis 09 exakt nach der Matrix in Abschnitt 5, plus der OpenProject-Sondermount. Belegung zum Erhebungszeitpunkt:
09_Fotosca. 540 MB,02_Vorstandca. 5,7 MB,08_Archivca. 0,1 MB, Rest leer (Struktur steht, Befüllung läuft). - Automation im Ordner-Modell: Der n8n-Kurier legt über den Service-User wj-bot Foto-Ordner unter
09_Fotosan und verteilt File-Drop-Links (Permission 4) per Talk. - 2FA: Provider installiert, Rollout-Anleitung fertig, Enforcement noch offen; der Vorstands-Rollout ist der letzte offene Punkt der 2026-08-13-Betriebsrunde.
- Setup-Artefakte:
wj/Nextcloud/setup-wj-nextcloud.sh(bare-metal),wj/Nextcloud/setup-wj-nextcloud-phase2.sh(Tags, Talk-Raum, Unterordner via WebDAV) undwj/Nextcloud/wjhcloud-demo/(kompletter Docker-Weg: bootstrap, post-install, setup-demo-11).