Eine Auflistung meiner Vorträge aus dem Jahr 2025.

Veranstaltungsorte

• 22. März 2025 auf den Chemnitzer Linux-Tagen 2025
• 11. Dezember 2025 auf den IT-Tage 2025

Kurzprofil

Dieser Vortrag geht zuerst auf grundlegende Details und die Arbeitsweise von restic ein. Wir besprechen lokalen und Cloud Storage, Verschlüsselung, Snapshots, Restore, sowie verschiedene wichtige Optionen.

Im zweiten Teil erklären wir, wie resticprofile funktioniert. Als Beispiel wird ein Backup-Szenario sowohl mittels restic als auch mit resticprofile aufgebaut, um die Unterschiede in der Handhabung zu verdeutlichen.

Restic ist eine Open-Source-Backup-Software, die Daten zuverlässig speichert und vor Verlust schützt. Die Software ist plattformunabhängig und unterstützt viele verschiedene Speicherziele, darunter lokale Festplatten, Cloud-Speicher und Netzwerkprotokolle wie SFTP, REST oder S3. Restic implementiert Deduplizierung und bietet Verschlüsselung, um Backups effizient und sicher zu speichern. Deduplizierung sichert nur neue oder veränderte Daten, damit werden Duplikate vermieden und Speicherplatz wird gespart.

Resticprofile ist die logische Ergänzung für restic, welches die Konfiguration und Verwaltung mehrerer Backup-Jobs drastisch vereinfacht und übersichtlicher gestaltet. Es ermöglicht das Anlegen und Verwalten von Backup-Profilen, die alle nötigen Einstellungen speichern, wie Speicherorte, Backup-Zeiten und weitere Parameter. Dies erleichtert die Automatisierung und die übersichtliche Verwaltung von komplexen Backup-Szenarien, indem es die Bedienung von restic optimiert und wiederkehrende Aufgaben systematisch handhabt. Außerdem kann es die Verwaltung der Cronjobs in verschiedenen Systemen übernehmen.

Unterlagen

Chemnitzer Linux-Tage 2025

Den Vortrag habe ich das erste Mal zusammen mit Andreas Scherbaum auf den Chemnitzer Linux-Tagen 2025 gehalten.

• Programmankündigung
• Folien
• Aufzeichnung

IT-Tage 2025

Ein weiteres Mal habe ich den Vortag mit Andreas Scherbaum auf den IT-Tage 2025 gehalten.

• Programmankündigung
• Folien
• Aufzeichnung: Es gab keine Aufzeichnung.

Changelog

Ich wurde schon mal des Öfteren gefragt wie ich denn meine Kontakte, Kalender, Passwörter, EMails usw. verwalte.
Persönlich möchte ich diese Datenschätze nicht oder nur möglichst wenig der “Cloud” überantworten und mache daher vieles selbst. Das Setup bzw. das Konzept hat eine jahrelange Entwicklung und eine Menge Veränderungen hinter sich. Zu einigen Teilbereichen sind auch schon vereinzelte Blogartikel entstanden.

Ein Gespräch letztens auf Mastodon hat mich dazu veranlasst, dies mal aufzuschreiben und hier zu veröffentlichen. Wer mag, kann sich aus diesem Text Ideen holen und für seine Situation anpassen.

TL&DR;

• Nextcloud selfhostet auf eigener Hardware im Homelab
• Passwort-Safes KeePass, KeePassXC, Bitwarden, Vaultwarden
• Backup mit restic und resticprofile verschlüsselt mit Deduplizierung auf S3-Storage und externen Festplatten

Jetzt die Langfassung: Wie sieht mein Setup aus?

Die Details

Angefangen habe ich mit Owncloud auf einem BananaPi. Vor einigen Jahren bin dann zu Nextcloud gewechselt. Aktuell läuft die Installation auf meinem Heim-NAS von QNAP in einer virtuellen Maschine wo ein Debian drauf läuft.
Aus-Gründen^(tm) waren und sind die Installationen nie von außen erreichbar.

Nextcloud

In der Nextcloud nutze ich überwiegend folgende Funkionen:

• Verwaltung von
  • Kalendern
  • Kontakt-Daten (VCards)
• Dateiaustausch

Die gesamte Familie bindet alles in ihre jeweiligen Mail- und Kalender-Clients auf den unterschiedlichsten Rechnern, mobilen Geräten mit verschiedensten Betriebssystemen an. Die Synchronisation funktioniert somit natürlich nur im heimischen WLAN oder über VPN.

Backups

Da mir meine Daten (Kalender und Kontakte) sehr wichtig sind, sichere ich die Daten regelmäßig und fertige ein Backup an.
Aktuell läuft auf dem Server, wo die Nextcloud installiert ist, ein nächtlicher Cronjob:

• der die Nextcloud in den Wartungsmodus versetzt,
  • um einen konsistenten Zustand zu erreichen,
• einen Dump der mysql-Tabellen auf Festplatte zieht,
• eine dateibasierte Sicherung anfertigt
• und schlussendlich den Wartungsmodus wieder beendet.

Der Cronjob läuft mitten in der Nacht, wenn sowieso alle schlafen. Selbst wenn das mal nicht der Fall sein sollte, verhindert der Wartungsmodus schlimmeres.
Dieses Verfahren existiert schon so seit Jahren und hat sich aus meiner Sicht bewährt. Selbst der Umzug von Owncloud nach Nextcloud sowie vom BananaPi in die virtuelle Maschine hat damit wunderbar funktioniert.

Die dateibasierte Sicherung und die Dumps ins Dateisystem sind nur ein erster Schritt. Wenn ich einzelne Kontakte oder ähnliches wiederherstellen möchte, ist das rauspfriemeln einzelner Daten nicht wirklich schön, beispielsweise eine einzelne aus Versehen gelöschte Kontakt-Karte.
Allerdings gibt es die Möglichkeit alle Kalendereinträge in eine ics Datei herunterzuladen und alle Kontakte in eine .vcf-Datei herunterzuladen. Daraus ist die Wiederherstellung aus meiner Sicht wesentlich einfacher. Wenn alle Dateien gelöscht sind, reicht ggf. sogar ein Doppelklick im Dateiexplorer auf die jeweilige Datei und es wird im Standard-Mail-Programm geöffnet. Von diesem ist dann ein Import wieder möglich. Dadurch, dass das Mail-Programm wieder in die Nextcloud synchronisiert, ist der Kontakt wieder “drin”. Natürlich war ich faul und habe dies automatisiert; wie ich dies realisiert habe, lässt sich hier nachlesen.

Die ganzen Datenkopien (wie Dumps und Exporte) sichere ich nun mit einem Backup-Programm. Da mir die Daten allgemein wichtig sind und ich auch vor Diebstahl und Feuer gewappnet sein möchte, setze ich hier auf das 3-2-1 Prinzip.

3-2-1-Prinzip

Hinweis

Hinweis: Das 3-2-1-Prinzip bedeutet in kurz:
Du hast drei Kopien auf zwei unterschiedlichen Medien, wobei eine Kopie außerhalb liegt.

Die bedeutet: Ich habe eine externe Festplatte auf die ich die Backups regelmäßig kopiere, wobei eine Kopie bei meinen Eltern liegt. Das tägliche Backup schiebe ich in die Cloud. Details siehe in diesem Blog-Artikel im Abschnitt Offsite-Backup.

Cloudspeicher

“Cloud” bedeutet hierbei irgend ein Speicherort, der Dateien aufnehmen kann. Das kann ein OneDrive, eine Dropbox, PDrive oder was auch immer sein. Bei mir ist dies aktuell ein angemieteter S3-kompatibler-Speicher.
Die Backups verschlüssele ich natürlich, daher ist es egal, wo diese im Endeffekt liegen:

• ob es nun eine externe Festplatte ist, die geklaut wird
• oder irgendein Cloud-Speicher, wo Daten abfließen können.

Das gewählte Verschlüsselungspasswort sollte daher möglichst lang und komplex sein.

Backup-Software

Als Software verwendet ich seit einiger restic in Zusammenarbeit mit resticprofile, da ich mit diesen Tools und die Backup-Jobs gut weg-automatisieren kann. Wenn ich daran denken muss, Backups zu machen, vergesse ich das nur.
Wie die Software funktioniert und bedient wird, haben Andreas und ich mal auf den Chemmnitzer LinuxTagen erzählt.

Aus meiner Sicht ist der Vorteil, dass restic

• die Daten verschlüsselt,
• den Platzbedarf mittels Deduplizierung verringert
• und ausmisten nach Regeln beherrscht, da kein Speicher unendlich ist.

resticprofile unterstützt hierbei sogar bei der Erzeugung eines möglichst langen und zufälligem Passwortes. Dadurch, dass ich Dinge automatisch in die Cloud sichere, aber lokal noch eine Festplatte habe, die ich “natürlich” (leider) nur unregelmäßig befülle, hat mir dieses Konzept schon mehrfach wortwörtlich den Hintern gerettet. Aktuell kostet mich der S3-Storage irgendwas unter 4 Euro pro Monat. Bei Interesse nach mehr Details hier klicken. Die dortige Angabe Backblaze stimmt inzwischen nicht mehr. Wegen #unplugTrump bin ich zu Hetzner StorageShare gewechselt.

Passwort-Safes

Ebenfalls seit Jahren nutze ich einen Passwort-Speicher. Bisher reichte mir ein KeePass. Später wechselte ich zu KeePassXC. Die Tresor-Datei lege ich bei mir in meinen Nextcloud-Ordner. Dort synchronisiert sich diese Datei wunderbar zwischen meinen Geräten und ist überall verfügbar, wo ich sie benötige.
Das KeePass-Tersor-Format ist recht verbreitet und es gibt für die unterschiedlichsten Betriebssysteme Software dafür. Die Client-Software für Nextcloud ist ebenso für viele Betriebssysteme verfügbar.

Dank Auto-Fill-Funktion habe ich schon länger kein Passwort mehr getippt und durch die Passwort-Würfeln-Funktion kenne ich auch gar kein Passwort mehr auswendig. Jedem Dienst ein Passwort zu verpassen, ist dadurch für mich recht einfach geworden. In letzter Zeit musste ich jedoch öfters Passwörter teilen und da hat mir KeePassXC nicht gereicht. KeeShare habe ich erst vor kurzem in einen Artikel auf gnulinux.ch entdeckt.
Aus diesem Grund habe ich mir einen Vaultwarden installiert. Vaultwarden ist auch perfekt, wenn ich Dateien oder Textschnipsel über unsichere Kanäle verschicken möchte. Die Funktion nennt sich vaultwarden-send. Über diese Funktion kann ich Dateien oder kurze Texte in den Vault hochladen und danach einen Link zum Herunterladen generieren. Zusätzlich kann ich diesen Link noch mit Passwort-Schutz und sonstigen Parameter versehen. Diesen Link kann ich ruhigen Gewissens unverschlüsselt per E-Mail verschicken. Die Daten liegen verschlüsselt auf der Server-Festplatte und löschen sich standardmäßig nach sieben Tagen selbst.

Tipps zu Vaultwarden

Standard-Einstellungen

Ich empfehle zwei Standard-Einstellungen zu ändern:

• Standard-URI Übereinstimmungserkennung auf Beginnt mit
  • das funktioniert bei mir am zuverlässigsten.
  • gerade auch in Kombination, dass im URL-Feld des jeweiligen Eintrags dann nur die Domain hinterlegt wird.
  • Das bedeutet ohne Pfade und sonstige Parameter!
  • Auffindbar derzeit unter: Einstelllungen->Automatisches Ausfüllen
• Zwischenablage leeren würde ich auf einen kurzen Zeitraum setzen, z.B. auf 30 Sekunden.
  • soweit ich mich erinnere ist der Standard niemals.
  • Auffindbar derzeit unter: Einstelllungen->Sonstiges

Leider muss die Einstellung in jedem Client einzeln gesetzt werden (Browser-Plugin, Smartphone-App usw.)

Admin-Seite

Die Admin-Seite würde ich aus Sicherheitsgründen ausschalten bzw. ausgeschaltet lassen. Wenn ich die Funktionalität doch einmal benötige, schalte ich sie kurzzeitig ein, auch wenn es zwei kurze Downtimes bedeutet.

Verständnis entwickeln

Als ich vaultwarden aufgesetzt habe, hatte ich zuerst zwei Test-Accounts angelegt. Danach habe ich eine “Organistation” und mehrere “Sammlungen” angelegt. Mit diesen zwei Accounts konnte ich dann ein besseres Verständnis der beiden Begriffe und des Berechtigungssystems erlangen.

EMail

Das ist für mich persönlich so ein großes Unlust-Thema und PITA.
Seit ich online bin, lagere ich diesen Service als Dienstleistung aus. Ich klicke mir irgendwo eine Domain und einen E-Mail-Speicherplatz und lasse das Menschen machen, die mehr Ahnung von dem Thema haben als ich. Aktuell bin ich seit Jahren sehr glücklich bei uberspace.
Ich habe bei denen mehrere Accounts (asteroid genannt). Dort lassen sich ohne Zusatzkosten Domains “aufschalten”. In deren verfügbarer Dokumentation (manual) sind die benötigten Befehle recht gut beschrieben, sofern man sich an die Kommandozeile herantraut. In deren Dokumentationsbereich namens Uberlab sind weitere Möglichkeiten beschrieben, zusätzliche Software zu installieren; inkl. Update-Schritten. Vielfach ist es nur ein copy&paste von vorgefertigten Befehlen.

Idee und Ausblick

Soweit ein Einblick in mein Setup und so wie es für mich funktioniert und bewährt hat. Ich habe versucht es kurz zu halten und bei ausufernden Themen mit Verweisen zu arbeiten.

Wer mag, kann die für sich passenden Informationen herausziehen und die eigenen Verhältnisse und Anforderungen anpassen oder ein Konzept zu entwickeln.

Auf der Wunschliste steht noch die Generierung der TLS-Zertifikate per Let’s-Encypt, da muss ich mich nochmal einlesen, wie ich dies umsetze, wenn die Systeme nicht von außen erreichbar sind.

Changelog

Vor ein paar Tagen habe ich mal wieder an einer Ansible-Rolle geschraubt und wurde beim Ausführen von ansible-playbook mit folgender Fehlermeldung begrüßt:

Source /root/.ansible/tmp/ansible-tmp-1746359478.4110813-9236-74562322926004/.source not found

Das war seltsam, weil ich nur das Modul ansible.builtin.copy aufgerufen hatte, was vorher auf anderen Rechner problemlos funktioniert hatte.

Und jetzt?

Die Fehlermeldung

TASK [meine_rolle : inst | linux_install | Copy Binaries] *************************************************************************************************************************************************************************************************
failed: [t24] (item=/pfad/zur/datei/foo) => {"ansible_loop_var": "item", "changed": false, "checksum": "884109935b2a432cb6edb5003c4ac5adc9462cbe", "item": "/pfad/zur/datei/foo", "msg": "Source /root/.ansible/tmp/ansible-tmp-1746359476.4233594-9236-186673184030632/.source not found"}
failed: [t24] (item=/pfad/zur/datei/bar) => {"ansible_loop_var": "item", "changed": false, "checksum": "9e184000b3f2541c07f62dcbf8bf7e8927757bec", "item": "/pfad/zur/datei/bar", "msg": "Source /root/.ansible/tmp/ansible-tmp-1746359478.4110813-9236-74562322926004/.source not found"}

Die Task

 1- name: inst | linux_install | Copy Binaries
 2  ansible.builtin.copy:
 3    src: '{{ item }}'
 4    dest: '{{ meine_rolle_install_path }}'
 5    owner: 'root' 
 6    group: 'root' 
 7    mode: '0755'
 8  become: true
 9  loop:
10    - '/pfad/zur/datei/foo'
11    - '/pfad/zur/datei/bar'

Das Problem

Ich bin per ssh auf die betroffene Maschine gesprungen und musste feststellen, dass das Verzeichnis /root/.ansible/tmp/ auf der Remote-Maschine wirklich nicht da war. Auch wurde das /root Verzeichnis (meiner Erinnerung nach) nicht angefasst. Ein manuelles Erstellen des Verzeichnisses brachte keine Besserung.

Zuerst kam mir keine Idee und daher hatte ich diverse Suchmaschinen befragt. Ich erwähnte es eingangs: “auf anderen Rechner problemlos”. Nun erinnerte ich mich, dass bei mir eine andere Distribution Einzug gehalten hat, die auf Ubuntu basiert.

Die Lösung

Hier scheint das Modul ansible.builtin.copy: mit dem become: true laut meinen Recherchen das Problem zu sein.

Beheben lies sich dies, in dem ich in der ansible.cfg folgende Option gesetzt habe:

1remote_tmp = /tmp/ansible_tmp

Ich hab das Playbook dann noch mit einem Host, der unter einem Debian 12 läuft, probiert und auch da lief das Playbook anstandslos durch. Ich lass das jetzt so.

Derzeit sichere ich meine Nextcloud-Instanz mit einem dateibasierten Backup-Tool, sowie einem Dump der Datenbank. Letztens hatte ich in meinem Umfeld jemanden, der ein paar Kontakte aus Versehen gelöscht hat. Nun können die vermissten Kontakte zwar aus dem Dump der Datenbank herausgepfriemelt werden, schön ist das aber nicht.

Nach etwas Recherche bin ich auf einen recht simplen curl-Befehl gestoßen, der eine .ics bzw .vcf-Datei heraus exportiert.

Dies ist dann doch aus meiner Sicht etwas einfacher. Sofern z.B. alle Kontakte gelöscht worden sind, reicht dann sogar ein Doppelklick auf die Datei und alle Kontakte werden wieder importiert. Dies sollte wesentlich stressfreier sein.

Als Familien-Admin möchte ich den Export für alle Nutzenden der Instanz regelmäßig machen; daher habe ich mir eine Ansible-Rolle dafür gestrickt.

Das Grundprinzip und die Konfiguration der Rolle möchte ich in diesem Artikel beschreiben.

Auf die Bedienung und Verwendung von Ansible möchte ich hier nicht eingehen, da setze ich entsprechendes Wissen voraus.

Zum Zeitpunkt des Artikel ist die Nextcloud-Version 31 aktuell. Die Pfade, die in der Ansible-Rolle verwendet werden, orientieren sich an diesem Stand. Sollten sich die Subpfade der URLs ändern, müsste die Rolle angepasst werden.

Überblick

Um die Rolle zu verstehen, ist es womöglich am einfachsten, sich das Vorgehen zu verdeutlichen, wenn ein manuelles Backup angefertigt werden soll. Dies soll hier in den nächsten Abschnitten beschrieben werden, um dann im nächsten Schritt zur Automatisierung zu kommen.

Händisches Backup

Melde dich als ersten Schritt in Deiner Nextcloud an.

Kontakte

• Wähle den Reiter Kontakte.
• Gehe nach unten auf der linken Seite und klicke da auf Kontakte-Einstellungen.

• Navigiere jetzt zu den Allgemeinen Einstellungen.
• Beim gewünschten Adressbuch auf die drei Punkte klicken (1)
• und auf Herunterladen klicken (2).

• Voilà! Es wird eine .vcf-Datei mit einem aktuellen Datumsstempel zum Download angeboten.

Kalender

• Wähle den Reiter Kontakte.
• Wähle Deinen Kalender aus, den du exportieren möchtest.
• Fahre Deine Maus etwas nach rechts bis das Stift-Icon erscheint (1) und klicke auf diesen.

• Im nächsten Dialog Kalender bearbeiten gibt es dann eine Schaltfläche mit der Beschriftung Exportieren.

• Voilà! Es wird eine .ics-Datei mit einem aktuellen Datumsstempel zum Download angeboten.

Automatisierung

Jetzt wollen wir das ganze automatisieren; dafür gibt es meine Ansible-Rolle export_nextcloud. Die Rolle findet Du auf meinem Gitlab-Account.

Die Rolle solltest Du auf einem Linux-Host deployen, dem Du vertraust und der Zugriff auf die Nextcloud hat.

Minimale Angaben

Variable export_nextcloud_url

Zunächst benötigt die Rolle die URL, worunter die Nextcloud-Instanz erreichbar ist. Dazu hinterlegst Du diese in der Variable export_nextcloud_url als Hostvariable, wo das Export-Script später laufen soll.

Beispiel:

1export_nextcloud_url: "https://meine.nextcloud.instanz"

Variable export_nextcloud_user

Jetzt brauchst Du eine Liste mit einem oder mehreren Usernamen, die du sichern möchtest. Zusätzlich ein Passwort und einen Zeitpunkt, wann das Export-Script laufen soll.

Empfehlung

Statt des regulären Passwortes für Deinen User, empfehle ich die Generierung eines Personal Access Token kurz “PAT”.

Die Einrichtung eines PAT beschreibe ich in einem anderem Blog-Artikel.

Als dritten Parameter wird noch der Zeitstempel benötigt, wo der Export laufen soll. Mit dieser Angabe wird später eine SystemD-Timer-Unit erstellt.

Die Syntax dieses Attributes folgt dem Parameter on_calendar von systemd.unit(5). Aus jeden username wird eine extra SystemD-Timer-Units erstellt, nach folgendem Muster:

• export_nextcloud-user1.timer
• export_nextcloud-user2.timer

Die Konfiguration sieht am Ende zum Beispiel so aus:

1export_nextcloud_user:
2  - username: "user1"
3    password: "password1"
4    on_calendar: '*-*-* 03:00'
5  - username: "user2"
6    password: "password2"
7    on_calendar: '*-*-* 03:01'

Optionale Angaben

Variable export_nextcloud_script_path

Die nächste Variable bestimmt, wohin das Script kopiert werden soll. Der Standardpfad lautet /opt/export_nextcloud.

Variable export_nextcloud_backup_path

Über diese Variable kann bestimmt werden, wohin die exportierten Kalender- und Kontakte-Dateien hingeschrieben werden sollen. /backup/nextcloud_export lautet hier der Standardpfad.

Hier entsteht pro Username eine Kalender- und eine Kontakte-Datei mit dem Username nach folgendem Muster:

• kalender-${username}.ics
• kontakte-${username}.vcf

Und ja, ich war zu faul, noch ein extra Aufräum-Mechanismus zu schreiben. Für die Versionierung ist bei mir mein Backup-Programm zuständig ;-) . Das kann mein Sicherungsprogramm viel effizienter als ich. Wenn ich an ältere Versionen herankommen möchte, muss ich die Sicherung bemühen; ich spare mir dadurch zusätzliche Fehlerquellen und Abhängigkeiten.

Variable export_nextcloud_prometheus_path

Diese Variable legt den Pfad fest, wo die Prometheus-Statistiken hingeschrieben werden.

Variable export_nextcloud_extra_curl_options

Diese Variable habe ich am 03.10.2025 eingeführt, weil der zugrunde liegende curl sich am selbst-signierten Zertifikat meiner Nextcloud-Instanz störte. Mit dem Parameter -k oder --insecure lässt sich das aber übersteuern. Dies erforderte allerdings eine Anpassung des Scriptes.

Nun können weitere Parameter über diese Variable optional mitgegeben werden.

Im unteren Beispiel Ansible Playbook fügt ihr an den einen Task folgende zwei Zeilen an.

1  vars:
2    export_nextcloud_extra_curl_options: "--insecure"

Ansible Playbook

Jetzt kannst Du die Rolle in ein Ansible-Playbook einbinden.

Ein minimales Beispiel wäre:

1---
2
3- name: Setup export_nextcloud
4  hosts: export_nextcloud
5  roles:
6    - export_nextcloud

Backup

Im Nachgang bzw. nach dem Ausführen der jeweiligen SystemD-Timer-Unit, empfehle ich noch ein Backup des Verzeichnisses wo die exportierten Dateien liegen. Das Verzeichnis kannst zum Beispiel dateibasiert mittels deiner präferierten Wunsch-Backup-Software gesichert werden. Ich selbst habe dazu die Pfade in meinem Sicherungsscript aufgenommen; hier verwende ich restic seit längerem erfolgreich.

Fertig.

Im Grunde war es das auch schon. Viel Spaß beim Benutzen. Der Source-Code der Rolle liegt in meinem Gitlab-Account.

Changelog

Soll auf Daten in einer Nextcloud zugegriffen werden, erfolgt dies häufig mittels der Kombination aus Username und Passwort. Erfolg dieser Zugriff jedoch mittels mobilen Geräten oder automatisiert aus anderen Diensten, ist es meist eine schlechte Idee, das Passwort großflächig zu verteilen. Mobile Geräte haben manchmal die Eigenschaft verloren zu gehen oder gestohlen zu werden. Weiterhin werden Dienste oder Geräte kompromitert oder unterstützen vielfach keine Zweifaktor-Authentisierung (2FA). Hierbei hilft die Generierung eines Personal Access Token kurz “PAT”.

Ein PAT hingegen sollte nur genau einem Dienst oder einem Gerät zugeordnet werden. Das jeweilige PAT und kann dann bei Verlust oder Kompromittierung über den Hauptzugang gesperrt werden, so dass der Zugriff feingranular entzogen werden kann. Vorteil: Das “Hauptpasswort” und die anderen PAT müssen nicht geändert werden und können bestehen bleiben.

Erstellung

Hinweis

Zum Zeitpunkt des Artikel ist die Nextcloud-Version 31 aktuell.

Zur Erstellung eines PAT melde dich als ersten Schritt in Deiner Nextcloud an.

Rechts oben sollten Deine Initialen oder Dein Profilbild stehen, dort bitte drauf klicken und es erscheint ein weiteres Pull-Down-Menü, wo du auf Einstellungen klickst.

Danach gibt es eine Übersicht von Deinem Profil und links eine Menüstruktur.

Mit Klick auf den Menüpunkt Sicherheit geht es jetzt weiter. Unterhalb des Abschnittes, findest Du schon eine Auflistung der schon aktiven Zugriffe unterhalb von Geräte & Sitzungen.

Am Ende der Tabelle (sofern sie existiert) gibt es eine Eingabemaske mit App-Name und dem Button “Neues App-Passwort erstellen”.

Trage hier bitte einen sinnvollen Namen ein, so dass Du das erstellte PAT später wieder zuordnen kannst. Ein sprechender Name erleichtert Dir später die Suche, falls Du einem Gerät oder Dienst den Zugriff entziehen möchtest.

Wichtig

Wenn Du auf das kleine Fenster wieder schließt, wird der Dialog geschlossen. Es gibt keine Möglichkeit, das Passwort nochmal anzuzeigen. Daher ist es wichtig, sich das Passwort an einem sicheren Ort zu notieren. Hast Du dies vergessen, musst Du ein neues PAT anlegen.

Das generierte PAT ist im Grunde nichts anderes ist, als ein extra Passwort. Notiere Dir jetzt das generierte Passwort an einer sicheren Stelle, übertrage es z.B. in Deinen Passwort-Safe. Das Passwort ist sofort aktiv und kann verwendet werden. Der gewohnte Benutzername bliebt hierbei gleich.

Wenn Du z.B. den Nextcloud-APP auf deinem Smartphone einrichten möchtest, hast Du jetzt die Chance mit Klick auf QR-Code für mobile Apps anzeigen Dir einen QR-Code anzeigen zu lassen, den Du mit der Nextcloup-App abscannen kannst und die Tipparbeit und Tippfehler ersparst.

Ist das Passwort in der Anwendung hinterlegt, kann der Dialog mit Klick auf das kleine X geschlossen werden.

Löschen

Das Löschen eines PAT wird auf der selben Seite in den Profil-Einstellungen vorgenommen werden. Über die drei Punkte bekommst Du ein Pulldown-Menü.

Hier kannst Du das PAT Widerrufen. Sofern der Client dies Unterstützt (z.B. die Smartphone-App) können via Klick auf Gerät löschen sogar die lokal vorgehaltenen Daten gelöscht werden.

+++ EIL ++++ EIL ++++ EIL +++

Es gibt neue Layer im OSI-Modell! Nummer Acht und Nummer Neun.