Zum Inhalt

rclone - Dateien von Git Repository automatisch zu Nexcloud übertragen

Dateien werden in einem Git Repository im "Master Branch" verwaltet und sollen einer breiteren Öffentlichkeit über das Filesharing-Programm Nextcloud zugänglich gemacht werden.

Ich denke hier an Dateien wie Richtlinien, Arbeitsanweisungen, also Dateien, die hauptsächlich Text beinhalten und für das Miteinander in einem Unternehmen Verwendung finden.

rclone – Dateien von Git Repository automatisch zu Nexcloud übertragen

Damit auch andere Personen als Programmierer oder Maintainer auf die Dateien zugreifen können, ist es notwendig die Files in das gängige Filehosting-System, in diesem Beispiel Nextcloud, zu übertragen. Dort kann dann für alle Benutzer ein lesender Zugriff auf die Dateien eingerichtet werden, somit kann jeder immer die aktuellste Version abrufen.

Der Kopiervorgang vom Git "Master Branch" zur Nextcloud soll in regelmäßigen Abständen mit einem Cron Job erfolgen.

Das Ganze lässt sich auch mit einer E-Mail-Information koppeln, d.h. in Nextcloud kommt eine neue Datei an und automatisch wird eine Nachricht an eine definierte E-Mail-Adresse versendet.

Anschließend kann von der Nextcloud über den Client ein Sync auf weitere Endgeräte erfolgen, damit die Benutzer die Dateien einsehen und weiterverwenden können.

Der ganze Prozess soll nur in eine Richtung gehen, vom Git Server zu Nextcloud mithilfe eines Benutzerkontos, dass nur lesenden Zugriff auf die Git Repos hat.

Vorbereitung

Benutzer mit Read-Only-Zugriff auf das Git Repo einrichten

Ich verwende eine Gitea-Installation, wo man über den Webbrowser ganz bequem als Administrator einen neuen Benutzer anlegen kann.

Das neue Konto für den Read-Only-Benutzer lässt sich über die Administrations-Oberfläche von Gitea erstellen.

Das Ändern des Passworts könnt ihr abschalten. Der Benutzer soll sich nicht an der Weboberfläche anmelden, sondern nur für den Sync mit rclone verwendet werden.

Weitere Einstellung für das Benutzerkonto

Das Benutzerkonto für den Read-Only-Benutzer ist fertig.

Der neue Read-Only-Benutzer wird nun dem Git Repo mit Leserechten hinzugefügt.

Ready-Only-Benutzer dem Git Repo als Mitarbeiter hinzufügen

Ready-Only-Benutzer dem Git Repo als Mitarbeiter hinzufügen

Read-Only-Benutzer nur Leserechte gewähren

Der Read-Only-Benutzer sieht auf seiner Startseite, dass er einem bestehenden Git Repo hinzugefügt wurde. Er kann jedoch darin keine Dateien ändern.

Git Repo wird dem Ready-Only-User angezeigt

Git Repo wird dem Ready-Only-User angezeigt

Read-Only-User hat nur Lesezugriff, er kann keine Dateien ändern. Die Option ist nicht verfügbar.

SSH-Schlüssel für Read-Only-Benutzer erzeugen

Unser neuer Benutzer benötigt ein SSH-Schlüsselpaar, damit das Git Repository auf den Server kopiert werden kann, ohne das ein Benutzername und ein Passwort eingegeben werden muss.

Ich folge hier meiner Anleitung zum Erstellen von SSH-Schlüsseln Zugriff via SSH ohne Passworteingabe; Anmeldung erfolgt durch ausgetauschten SSH-Schlüssel

Bevor wir mit dem Erzeugen eines SSH-Schlüsselpaars beginnen, gilt es noch etwas zu beachten. Es gibt zwei Möglichkeiten ein Schlüsselpaar anzulegen:

  • mit Passwort
  • ohne Passwort

Was ist der Unterschied?

Mit Passworteingabe: Ihr arbeitet mit Git in eurem lokalen Repository und möchtet nun per SSH eure Änderungen auf den Remote Server pushen oder von dort holen (fetch/pull. Bevor der Transfer gestartet wird, müsst ihr eure SSH-Passwörter eingeben. Das Passwort wird so lange im "gespeichert" bis ihr euren PC neu startet, dann müsst ihr das Passwort erneut eingeben.

Ohne Passworteingabe: Das Gleiche wie oben, jedoch ohne die Eingabe eines Passworts.

SSH - Passwortabfrage für Zugriff auf privaten Key

Da der ganze Synchronisationsprozess im Hintergrund und vollautomatisch ablaufen soll, passt die Eingabe eines Passworts nicht so wirklich ins Konzept. Aus diesem Grund wäre es sinnvoll einen Key ohne Passwort anzulegen.

Was bedeutet das aus sicherheitstechnischer Sicht für das Git Repo?

Da der von uns verwendete Benutzer ausschließlich einen lesenden Zugriff auf das Git Repo bekommen soll, kann er keine Dateien ändern. Damit ist die Gefahr einer ungewollten Änderung so gut wie ausgeschlossen. Ihr müsst halt nur aufpassen, dass der Read-Only-Benutzer in Git auch für alle anderen Repository Read-Only bleibt. Zudem übertragen wir in diesem Szenario nur Dateien mit Text, die sowieso im Unternehmen veröffentlicht werden und kein geheimen oder schutzwürdigen Informationen enthalten.

Was bedeutet das aus sicherheitstechnischer Sicht für den Linux Benutzer?

Ich nehme hier einfach mal an, dass rclone auf einem Linux-Server ausgeführt wird. Da ist das gleiche Spielchen wie bei allen anderen Systemen auch, ROOT und SUDO kann so gut wie alles machen. In unserem Fall besteht das Risiko,

  • die Konfigurationsdateien von rclone zu ändern
  • unser bash-Skript zu ändern

In beiden Fällen sollte das relativ bald auffallen, wenn neue Dateien im Ziel, also der Nextcloud, nicht mehr auftauchen. Um eine Rückverfolgbarkeit zu gewährleisten, sollte auf dem Linux-System die Protokollierung angeschaltet sein.

Der neue Git-Benutzer soll wirklich nur einen lesenden Zugriff auf das und evtl. auch noch auf andere Git Repositories erhalten. Für Benutzer mit einem schreibenden Zugriff auf Repositories, also ein Programmierer oder ein Maintainer eurer Dateien ist die Verwendung eines Hardwaretoken, wie dem YubiKey auf jeden Fall zu empfehlen.

ssh-keygen

Anschließend werdet ihr nach dem Verzeichnis gefragt, wo der Schlüssel abgespeichert werden soll. Den Standard könnt ihr einfach mit Enter bestätigen.

generating public/private rsa key pair.
Enter file in which to save the key (/home/benutzername/.ssh/id_rsa): 
Created directory '/home/benutzername/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/benutzername/.ssh/id_rsa
Your public key has been saved in /home/benutzername/.ssh/id_rsa.pub
The key fingerprint is:

Das Schlüsselpaar ist erstellt und der öffentliche Schlüssel ist in das Profil des Read-Only-Benutzers in Gitea einzutragen.

SSH-Schlüssel zum Konto des Read-Only-Benutzers hinzufügen

SSH-Schlüssel zum Konto des Read-Only-Benutzers hinzufügen

Los gehts!

Git Remote Repository klonen

Mit dem Eintrag des öffentlichen Schlüssels im Profil des Read-Only-Benutzers in Gitea sind alle Voraussetzungen erfüllt, um das Git Repo auf die Festplatte eures Servers zu klonen.

git clone git@xxxxxxxxxxx.de /verzeichnis

Sollte Git aufmucken, dass in der .gitconfig noch keine Benutzerdaten hinterlegt sind, könnt ihr das mit den beiden Befehlen erledigen. Die Daten werden dabei nur für das Projekt angelegt und nicht global.

git config user.name 'read-only-benutzername'
git config user.email 'e-mail-addresse'

Die Einstellungen könnt ihr mit dem Befehl ausgeben lassen.

git config --list

Prüft auch gleich, ob ihr euer Git Remote Verzeichnis mit dem fetch-Befehl abholen könnt.

git fetch origin master

rclone - Übertrag zur Nextcloud

Das kleine Tool rclone wird auf dem Server installiert und kopiert in regelmäßigen Abständen ein definiertes Verzeichnis auf die Nextcloud.

Das Programm kann für unterschiedliche OS-Architekturen der Betriebssysteme Windows, macOS, Linux (.deb, .rpm), FreeBSD, NetBSD, OpenBSD, Plan9, Solaris heruntergeladen werden und ist damit sehr vielseitig einsetzbar.

Ihr könnt prüfen, ob rclone in den Repositories eurer Distribution enthalten ist.

apt-cache policy rclone

Die Ausgabe sollte bei einem aktuellen Ubuntu so aussehen:

rclone:
  Installed: (none)
  Candidate: 1.50.2-3
  Version table:
     1.50.2-3 500
        500 http://de.archive.ubuntu.com/ubuntu groovy/universe amd64 Packages

Damit steht einer Installation von rclone aus den Ubuntu Repositories nichts mehr im Wege.

sudo apt install rclone

Nach der Installation gehts mit dem Setup weiter.

Beachtet dabei, dass wir von einer Quelle zu einem Ziel die Dateien übertragen.

In unserem Setup sieht das so aus

  • Ziel = Nextcloud
  • Quelle = lokales Laufwerk des Servers

Wir müssen also die Konfiguration von rclone ZWEIMAL durchlaufen, einmal für das Ziel und einmal für die Quelle.

Die Konfiguration wird mit gestartet.

rclone config

Auswahl der Nextcloud als Remote Speicher

2021/02/08 20:05:50 NOTICE: Config file "/home/dev/.config/rclone/rclone.conf" not found - using defaults
No remotes found - make a new one
n) New remote
s) Set configuration password
q) Quit config
n/s/q> n
name> nextcloud
Can't use "nextcloud.strobel.xy-banking" as config name contains invalid characters - may only contain 0-9, A-Z ,a-z ,_ , - and space .
name> nextcloud                            
Type of storage to configure.
Enter a string value. Press Enter for the default ("").
Choose a number from below, or type in your own value
 1 / 1Fichier
   \ "fichier"
 2 / Alias for an existing remote
   \ "alias"
 3 / Amazon Drive
   \ "amazon cloud drive"
 4 / Amazon S3 Compliant Storage Provider (AWS, Alibaba, Ceph, Digital Ocean, Dreamhost, IBM COS, Minio, etc)
   \ "s3"
 5 / Backblaze B2
   \ "b2"
 6 / Box
   \ "box"
 7 / Cache a remote
   \ "cache"
 8 / Citrix Sharefile
   \ "sharefile"
 9 / Dropbox
   \ "dropbox"
10 / Encrypt/Decrypt a remote
   \ "crypt"
11 / FTP Connection
   \ "ftp"
12 / Google Cloud Storage (this is not Google Drive)
   \ "google cloud storage"
13 / Google Drive
   \ "drive"
14 / Google Photos
   \ "google photos"
15 / Hubic
   \ "hubic"
16 / JottaCloud
   \ "jottacloud"
17 / Koofr
   \ "koofr"
18 / Local Disk
   \ "local"
19 / Mail.ru Cloud
   \ "mailru"
20 / Microsoft Azure Blob Storage
   \ "azureblob"
21 / Microsoft OneDrive
   \ "onedrive"
22 / OpenDrive
   \ "opendrive"
23 / Openstack Swift (Rackspace Cloud Files, Memset Memstore, OVH)
   \ "swift"
24 / Pcloud
   \ "pcloud"
25 / Put.io
   \ "putio"
26 / SSH/SFTP Connection
   \ "sftp"
27 / Transparently chunk/split large files
   \ "chunker"
28 / Union merges the contents of several remotes
   \ "union"
29 / Webdav
   \ "webdav"
30 / Yandex Disk
   \ "yandex"
31 / http Connection
   \ "http"
32 / premiumize.me
   \ "premiumizeme"

Für Nextcloud brauchen wir 29.

Storage> 29
** See help for webdav backend at: https://rclone.org/webdav/ **

URL of http host to connect to
Enter a string value. Press Enter for the default ("").
Choose a number from below, or type in your own value
 1 / Connect to example.com
   \ "https://example.com"
 url> https://nextcloud.de/remote.php/dav/files/benutzername
 Name of the Webdav site/service/software you are using
Enter a string value. Press Enter for the default ("").
Choose a number from below, or type in your own value
 1 / Nextcloud
   \ "nextcloud"
 2 / Owncloud
   \ "owncloud"
 3 / Sharepoint
   \ "sharepoint"
 4 / Other site/service or software
   \ "other"
vendor> 1
User name
Enter a string value. Press Enter for the default ("").
user> benutzername
Password.
y) Yes type in my own password
g) Generate random password
n) No leave this optional password blank
y/g/n> y
Enter the password:
password:
Confirm the password:
password:
Bearer token instead of user/pass (eg a Macaroon)
Enter a string value. Press Enter for the default ("").
bearer_token> 
Edit advanced config? (y/n)
y) Yes
n) No
y/n> n
Remote config
--------------------
[nextcloud]
url = https://nextcloud.de/nextcloud/remote.php/dav/files/benutzername
vendor = nextcloud
user = benutzername
pass = *** ENCRYPTED ***
--------------------
y) Yes this is OK
e) Edit this remote
d) Delete this remote
y/e/d> y
Current remotes:

Name                 Type
====                 ====
nextcloud webdav

e) Edit existing remote
n) New remote
d) Delete remote
r) Rename remote
c) Copy remote
s) Set configuration password
q) Quit config
e/n/d/r/c/s/q> q

Nach dem Abschluss der Konfiguration könnt ihr den Inhalt der Nextcloud, auf den der angegebene Benutzer Zugriff hat, abfragen.

Ein einzelnes Verzeichnis wird mit dem aus Linux bekannten Befehl ls abgefragt

rclone ls nextcloud:Ordner/

Den Inhalt der gesamten Nextcloud geht auch, kann aber sehr lange dauern.

rclone ls nextcloud:

Etwas übersichtlicher lässt sich die Ausgabe mit tree darstellen.

rclone tree nextcloud:Ordner/

Die lokale Festplatte als Source-Laufwerk definieren

Current remotes:

Name                 Type
====                 ====
nextcloud webdav

e) Edit existing remote
n) New remote
d) Delete remote
r) Rename remote
c) Copy remote
s) Set configuration password
q) Quit config
e/n/d/r/c/s/q> n
name> localstorage
Type of storage to configure.
Enter a string value. Press Enter for the default ("").
Choose a number from below, or type in your own value
 1 / 1Fichier
   \ "fichier"
 2 / Alias for an existing remote
   \ "alias"
 3 / Amazon Drive
   \ "amazon cloud drive"
 4 / Amazon S3 Compliant Storage Provider (AWS, Alibaba, Ceph, Digital Ocean, Dreamhost, IBM COS, Minio, etc)
   \ "s3"
 5 / Backblaze B2
   \ "b2"
 6 / Box
   \ "box"
 7 / Cache a remote
   \ "cache"
 8 / Citrix Sharefile
   \ "sharefile"
 9 / Dropbox
   \ "dropbox"
10 / Encrypt/Decrypt a remote
   \ "crypt"
11 / FTP Connection
   \ "ftp"
12 / Google Cloud Storage (this is not Google Drive)
   \ "google cloud storage"
13 / Google Drive
   \ "drive"
14 / Google Photos
   \ "google photos"
15 / Hubic
   \ "hubic"
16 / JottaCloud
   \ "jottacloud"
17 / Koofr
   \ "koofr"
18 / Local Disk
   \ "local"
19 / Mail.ru Cloud
   \ "mailru"
20 / Microsoft Azure Blob Storage
   \ "azureblob"
21 / Microsoft OneDrive
   \ "onedrive"
22 / OpenDrive
   \ "opendrive"
23 / Openstack Swift (Rackspace Cloud Files, Memset Memstore, OVH)
   \ "swift"
24 / Pcloud
   \ "pcloud"
25 / Put.io
   \ "putio"
26 / SSH/SFTP Connection
   \ "sftp"
27 / Transparently chunk/split large files
   \ "chunker"
28 / Union merges the contents of several remotes
   \ "union"
29 / Webdav
   \ "webdav"
30 / Yandex Disk
   \ "yandex"
31 / http Connection
   \ "http"
32 / premiumize.me
   \ "premiumizeme"
Storage> 18
** See help for local backend at: https://rclone.org/local/ **

Disable UNC (long path names) conversion on Windows
Enter a string value. Press Enter for the default ("").
Choose a number from below, or type in your own value
 1 / Disables long file names
   \ "true"
nounc> 
Edit advanced config? (y/n)
y) Yes
n) No
y/n> n
Remote config
--------------------
[localstorage]
--------------------
y) Yes this is OK
e) Edit this remote
d) Delete this remote
y/e/d> y
Current remotes:

Name                 Type
====                 ====
localstorage         local
nextcloud webdav

e) Edit existing remote
n) New remote
d) Delete remote
r) Rename remote
c) Copy remote
s) Set configuration password
q) Quit config
e/n/d/r/c/s/q> q

Dry-Run vor dem ersten Kopiervorgang

Bevor wir den Kopiervorgang zu Nextcloud live durchführen, machen wir mal einen dry-run. Dabei seht ihr auch gleich, wie lange rclone benötigt, um die Dateien auf die Nextcloud zu schieben.

rclone sync --dry-run localstorage:/home/benutzername/git/repo nextcloud:/Ordner/

Bei Fehlern könnt ihr auch das Log Level und die Log File für die genauere Fehleranalyse angeben.

rclone sync --dry-run --log-file=logfile.txt --log-level DEBUG localstorage:/home/benutzername/git/repo nextcloud:/Ordner/

Weitere Informationen zum Log Level findet ihr in der offiziellen Doku 👉 https://rclone.org/docs/#log-level-level.

Es gibt die folgenden vier Level:

  • DEBUG = es werden Debug Infos ausgegeben, also alles was rclone macht
  • INFO = Gibt Informationen über jeden Transfer aus und erstellt jede Minute eine Statistik
  • NOTICE = es werden nur Warnungen und signifikante Ereignisse ausgegeben
  • ERROR = gibt nur Fehlermeldungen aus

In der Ausgabe werdet ihr sehen, dass alle Dateien an die Nextcloud übertragen werden, auch die für das Git Repo relevanten Dateien. Die seht ihr aber je nach Einstellung in eurer Nextcloud nicht, da die mit einem Punkt beginnen und deshalb als versteckter Ordner bzw. Datei gelten. Scrollt in der Nextcloud im Sync-Ordner an das Ende, dann seht ihr dazu einen Hinweis, wie z.B. 1 Ordner und 4 Dateien (3 versteckte eingeschlossen)

Ihr habt also nun mehrere Optionen, um die nicht benötigten Ordern und Dateien nicht zu übertragen.

  • Repo so strukturiert anlegen, dass die Dateien für die Nextcloud in einem Unterordner liegen, den ihr explizit für den Kopiervorgang auswählen könnt
rclone sync --dry-run localstorage:/home/benutzername/git/repo/unterordner/ nextcloud:/Ordner/
  • Ihr gebt ganz genau an, welche Dateien zu kopieren sind
rclone sync --dry-run localstorage:/home/benutzername/git/repo/datei.xlsx nextcloud:/Ordner/
  • Ihr führt eine Bereinigung mit rclone vor dem Übertrag durch. (dazu bitte die Doku genau studieren)

Kopiervorgang in Live

Hat der Trockenlauf funktioniert, dann entfernt ihr einfach "--dry-run" und schon funktioniert der Kopiervorgang auf die Nextcloud.

Sicherung der rclone-Config

Die Konfigurationsdatei von rclone findet ihr im Verzeichnis eures Benutzers unter ~/.config/rclone

Automatisierung mithilfe eines bash-Skripts und eines Cron Jobs

Wir haben bis jetzt alle Schritte manuell ausgeführt, was hoffentlich auch funktioniert hat, damit steht auch einer kompletten Automatisierung des ganzen Prozesses nichts mehr im Wege.

Erstellt ein neues bash-Skript mit dem Namen git-rclone-nextcloud.sh und kopiert den folgenden Inhalt rein.

Im Skript gibt es auch die --dry-run Funktion, die ihr dann gegen die Live tauschen müsst, wenn alles funktioniert.

Den E-Mail-Versand müsst ihr auch noch konfigurieren, falls gewünscht. Schaut euch dazu den Beitrag hier im Blog an 👉 E-Mail-Versand für den Raspberry Pi konfigurieren

#!/bin/bash

# by strobelstefan.de
# 2021-02-12
# Version: 1.0
# https://strobelstefan.de

# E-Mail address where the log file should be emailed to
EMAIL="e-mail@mail.de"

# Git Repo - local path
# Please put the full path to the local Git repo or
REPODIR="/home/benutzername/git/repo/unterordner/"

# Location of your log file
LOGFILE="/home/benutzername/rclone-git-process.log"

###################################
# This removes your old log file
###################################
echo $(date +%Y-%m-%d_%H-%M-%S) " -Start to remove old log file" >> ${LOGFILE}
rm -f ${LOGFILE}
echo $(date +%Y-%m-%d_%H-%M-%S) " - Finished to remove old log file" >> ${LOGFILE}

###################################
# Pull the Git Repo 
###################################
echo $(date +%Y-%m-%d_%H-%M-%S) " - Start to pull" >> ${LOGFILE}
cd $REPODIR
# dry-run
var=`git pull --dry-run origin master 2>&1`
# live
# var=`git pull origin master 2>&1`
echo $(date +%Y-%m-%d_%H-%M-%S) " - pull done" >> ${LOGFILE}

###################################
# Start rclone process
###################################
echo $(date +%Y-%m-%d_%H-%M-%S) " - Start rclone process" >> ${LOGFILE}
/usr/bin/rclone sync --log-file=${LOGFILE} --log-level DEBUG localstorage:/home/benutzername/git/repo/unterordner/ nextcloud:/Ordner/ 
exit 0
echo $(date +%Y-%m-%d_%H-%M-%S) " - Finished rclone process" >> ${LOGFILE}

###################################
# Send log file via E-Mail 
###################################
# echo $(date +%Y-%m-%d_%H-%M-%S) " - Send log file via e-mail" >> ${LOGFILE}
# echo $(date +%Y-%m-%d_%H-%M-%S) " - rclone process log file sent to ${EMAIL}" | mutt ${EMAIL} -a ${LOGFILE} -s "rclone sync process done"

Anschließend machen wir das Skript noch ausführbar

sudo chmod +x git-rclone-nextcloud.sh

Dann können wir auch schon einen crontab anlegen. Das funktioniert mit dem eingeloggten Benutzer. ROOT -Rechte sind nicht erforderlich

crontab -e

Dort tragt ihr in eine neue Zeile z.B. ein

# rclone - git repo to nextcloud
59 23 * * * /bin/bash /home/benutzername/git-rclone-nextcloud.sh

Das Skript wird dann automatisch jeden Tag um 23:59 Uhr ausgeführt und überträgt das Git Repo automatisch zu eurer Nextcloud.

Probleme

Nextcloud - Das Dokument wurde außerhalb des Editors gespeichert

Der Übertrag der Dateien durch rclone war erfolgreich, jedoch zeigt Nextcloud die folgende Meldung beim Aufruf an. Ich habe versucht die Datei README.md auf die Nextcloud zu übertragen.

Das Dokument wurde außerhalb des Editors gespeichert. Die Änderungen könnten nicht angewendet werden.

Am unteren Bildschirmrand werden zwei Optionen angezeigt zum Auswählen angezeigt

  • Verwendet aktuelle Version - Es wird die alte Datei verwendet
  • Die gespeicherte Version verwenden - Es wird die mit rclone übertragene Datei

Nextcloud - Das Dokument wurde außerhalb des Editors gespeichert

Das Verhalten der Nextcloud ist sehr unschön, schließlich wollen wir ja nicht eine manuelle Bestätigung, sondern einen automatisierten Prozess zum Übertragen der Dateien.

Bei mir hat der Lösungsansatz geholfen, den ich auf GitHub gefunden habe https://github.com/rclone/rclone/issues/5003.

Ich habe die "Umfangreiche Arbeitsbereiche anzeigen" einfach deaktiviert. Auf meiner Nextcloud habe ich das nie benötigt.

Im Business-Umfeld ist das ggf. aber ein sinnvolles Feature, weshalb eine Deaktivierung nicht infrage kommt. (Aber wer nutzt das Feature von den normalen Benutzern überhaupt?)

Möchte man viele Dateien über die Nextcloud so an den eigenen Mitarbeiterkreis kommunizieren, wäre ggf. eine eigene Nextcloud-Instanz möglich, die über Nextcloud Federation an die Haupt-Nextcloud Dateien verteilt, wäre evtl. eine Idee.

Habt ihr damit Erfahrung? Würde mich brennend interessieren.

Gib mir gerne einen Kaffee ☕ aus ❗️

Wenn dir meine Beiträge gefallen und geholfen haben, dann kannst du mir gerne einen Kaffee ☕️ ausgeben.

Donation via PayPalDonation via LiberaPay

Donation via Bitcoin
Bitcoin Address: bc1qfuz93hw2fhdvfuxf6mlxlk8zdadvnktppkzqzj

Fehler beim Löschen der Datei README.md

Nach ein paar Versuchen die Datei README.md auf die Nextcloud zu übertragen war die Datei dort auf einmal gesperrt und ich konnte sie nicht mehr löschen. Es wurde die Fehlermeldung ausgegeben:

Fehler beim Löschen der Datei "README.md"

Die Lösungen im WWW zum vollständigen der Datei gingen entweder über ein grafischen Datenbanktool, wie phpMyAdmin oder direkt über die Konsole auf die Datenbank. (siehe z.B. hier oder hier).

Ich habe mich jedoch für eine Quick-and-Dirty-Methode entschieden.

Ich bin mit einem Admin-Benutzer direkt in das Nextcloud /data-Verzeichnis und habe die Datei dort direkt auf Dateiebene gelöscht. (Das funktioniert nur, wenn die Dateien nicht verschlüsselt sind.)

Anschließend habe ich einen Datenbankscan durchgeführt und die Datei aus der Datenbank geschmissen. Bitte beachtet, dass die Laufzeiten für die beiden Operationen in Abhängigkeit von der Größe der Nextcloud sehr, sehr lange dauern können, deshalb ist ggf. der Weg über die Datenbank bei großen Installationen schneller!

cd /var/www/html/nextcloud
sudo -u www-data php occ files:scan --all

Ihr könnt dann auch noch diesen Befehl starten. War bei mir aber nicht mehr notwendig, die Datei war schon weg.

sudo -u www-data php occ files:cleanup

Die Dokumentation dazu gibt es hier

So, Datei weg, Datenbank in Ordnung, alles wieder okay 8-)

Gib mir gerne einen Kaffee ☕ aus ❗️

Wenn dir meine Beiträge gefallen und geholfen haben, dann kannst du mir gerne einen Kaffee ☕️ ausgeben.

Donation via PayPalDonation via LiberaPay

Donation via Bitcoin
Bitcoin Address: bc1qfuz93hw2fhdvfuxf6mlxlk8zdadvnktppkzqzj

Source

Photo by Yancy Min on Unsplash