Jun 27, 2021

5708

Dateien regelmäßig von FTP Server in Datenverzeichniss von Nextcloud kopieren

Hallo,

mein Scanner legt die Scans auf einem FTP Account auf Server 1 ab.

Auf Server 2 mit Ubuntu 20.04 habe ich eine Nextcloud laufen.

Kann ich irgendwie z.B. alle 5 min von Server 2 auf dem FTP Account auf Server 1 nachschauen ob neue Dateien drin sind und wenn ja diese ineinen bestimmten Ordner (im NC Datenverzeichnis) verschieben?

Hintergrund:
Binde ich den FTP in Nextcloud ein, erscheinen die Daten nicht im Webmenü der Nextcloud. Erst nach occ files:scan
Gehe ich den Umweg mit der Verschiebeaktion ins NC Datenverzeichnis werden sie angezeigt.
Extra einen FTP Server auf Server 2 zu installieren will ich auch aus Sicherheitsgründen nicht.

Kann jemand weiterhelfen?

Danke
Christian

Please also mark the comments that contributed to the solution of the article

Content-Key: 831551565

Url: https://administrator.de/contentid/831551565

Printed on: May 4, 2024 at 04:05 o'clock

37 Comments

Latest comment

Servus!
Warum nicht einfach einen cron-job auf dem Server erstellen, der das alle 5-10 Minuten occ files:scan macht?

Gruß
Luigi

Da hatte ich auch daran gedacht. Aber die Nextcloud hat mehrere 100 GB Daten. Und die mit occ files:scan zu scannen dauert deutlich länger als 5min bis zur nächsten Ausführung des Cronjobs

Gerne auch irgendeine andere Lösung die den Ordner auf Server 1 überwacht und neue Dateien sofort auf Server 2 verschiebt

Servus.
Rsync oder die Live-Variante lsyncd die via inotify auf Dateisystemänderungen reagiert.

Grüße Uwe

Moin,

was läuft denn auf Server 1 an Software und Betriebssystem?
Ich kenne die Möglichkeit das ein FTP Server nach einem Upload ein Kommando ausführt, er könnte dann ja die Datei aktiv auf Server 2 kopieren...

-teddy

Danke, schaue ich mir an. Auf beiden Servern Ubuntu 20.04 LTS

Ich hab es jetzt so gelöst:

sudo -u www-data crontab -e

*/5 * * * * php /var/www/nextcloud/occ files:scan --path="/USER/files/Ordner"

Das funktioniert. Aber ich muss halt immer 5 min warten. Ich schaue mir deshalb die naderen Lösungen an. Vll. geht damit ja ein sofortiges Kopieren / Verschieben

Zitat von @hokaido:

Vll. geht damit ja ein sofortiges Kopieren / Verschieben

Ja klar, wie oben schon geschrieben nutzt lsyncd inotify und damit die Events die das Dateisystem beim erstellen/modifizieren von Dateien generiert. Kann man sich natürlich mit inotifywait und rsync auch selbst in nem Bash Script zimmern wenn man will.

Muss ich mir anschauen, die Tage...

Ich hatte ein ähnliches Szenario: Dateien werden in ein Verzeichnis kopiert, das auch in der NextCloud ersichtlich ist / sein soll.

Mein Lösungsansatz: das Verzeichnis unterhalb des Datenvezeichnisses auf Dateisystemebene in der Nextcloud eingebunden und in der
Nextcloud als external Storage eingebbunden und freigegeben.
Die Rechteproblematik die sich daraus ergibt habe ich mit mount --bind gelöst.

Wenn du genauere Infos haben möchtest einfach ansagen.
Schliesslich gibt es viele Wege die nach Rom führen ;)

@linuxer1:
Ja gerne genauere Infos bitte.

Ich habe derweil lsyncd nach der Anleitung
https://www.howtoforge.de/anleitung/wie-synchronisiert-man-verzeichnisse ...
installiert und eingerichtet.

Leider funktioniert das aber nicht.

systemctl status lsyncd
● lsyncd.service - LSB: lsyncd daemon init script
Loaded: loaded (/etc/init.d/lsyncd; generated)
Active: active (exited) since Mon 2021-06-28 22:11:04 CEST; 18min ago
Docs: man:systemd-sysv-generator(8)
Tasks: 0 (limit: 2279)
Memory: 0B
CGroup: /system.slice/lsyncd.service

Jun 28 22:11:04 srv2 systemd[1]: Starting LSB: lsyncd daemon init script...
Jun 28 22:11:04 srv2 lsyncd[9864]: * Starting synchronization daemon lsyncd
Jun 28 22:11:04 srv2 lsyncd[9870]: 22:11:04 Normal: --- Startup, daemonizing ---
Jun 28 22:11:04 srv2 lsyncd[9870]: Cannot open logfile [/var/log/lsyncd/lsyncd.log]!
Jun 28 22:11:04 srv2 lsyncd[9864]: ...fail!
Jun 28 22:11:04 srv2 systemd[1]: Started LSB: lsyncd daemon init script.

Alle Verzeichnisse und .log & .status Dateien sind eingerichtet.

Woran kann das liegen?

folgende Vorgehensweise hat bei mir zum erfolg geführt:

ich habe das als nfs verzeichnis vorliegen und eingebunden

prereq
verzeichnis das die ftp daten vorhält: SERVER1/FTPVERZ
nextcloud-datenverzeichnis: NCVERZ
Das Datenverzeichnis meint das Verzeichnis in dem auch die NC-User die Daten vorhalten.

auf dem Nextcloud server
mountpoint erstellt: NCVERZ/FTPVERZ
mount SERVER1/FTPVERZ /NCVERZ/FTPVERZ --bind -o force-user=www-data,force-group=www-data

wobei www-data der user ist unter dem der Webserver läuft (bei mir debian)

und um das ganze direkt beim neustart wieder verfügbar zu haben
/etc/fstab edietieren

das bind mount war notwendig, weil sonst die cloud die daten nicht lesen konnte
ich habe hier kein lsync oder inotify oder ähnliches am laufen fuer diesen Vorgang

Danke, auch das probiere ich mal aus...
Jetzt hab ich schon 3 Möglichkeiten. Mal schaun, welche die geeignetste ist

Aktuell favorisiere ich aber lysnc, wobei das irgendwie noch zickt

Deswegen hasse ich solche Anleitungen, da schaltet der gemeine User schnell mal das Hirn aus.

Zitat von @hokaido:
Jun 28 22:11:04 srv2 lsyncd[9870]: Cannot open logfile [/var/log/lsyncd/lsyncd.log]!
Woran kann das liegen?

Die Meldung kommt genau dann wenn das Log-Verzeichnis nicht existiert oder die falschen Berechtigungen hat.

Hier ein aktuelles Ubuntu mit einwandfrei arbeitendem lsyncd

Und jetzt provoziere ich deinen Fehler mal selbst indem ich das Log-Verzeichnis aus dem Dateisystem entferne

Grüße Uwe

Wie geschrieben, Verzeichnis und Logfile vorhanden. In der Anleitung steht nämlich nicht, dass man beides erstellen muss. Habe ich aber gemacht. Hirn war also an...
Welche Berechtigungen hast du vergeben?

Zitat von @hokaido:

Wie geschrieben, Verzeichnis und Logfile vorhanden. In der Anleitung steht nämlich nicht, dass man beides erstellen muss. Habe ich aber gemacht. Hirn war also an...
Welche Berechtigungen hast du vergeben?

Keine, wenn du mal ins Service-File reinschaust erkennst du das der Dienst per Default mit Root-Rechten läuft. Die Logfiles selbst darfst du nicht selbst erstellen das macht der Dienst selbst, nur das Log-Verzeichnis erstellst du!.
Kann also Root in das Logfile Verzeichnis schreiben reicht das, danach noch ein systemctl restart lsyncd und es läuft einwandfrei. Ansonsten poste doch bitte deine Configs und Rechte der Verzeichnisse.
Läuft auf sämtlichen hier verfügbaren Distros problemlos, liegt also an deiner Installation.

Das Verzeichnis hat diese Rechte:
drwxr-xr-x 2 root root 4096 Jun 29 09:56 lysncd

setz dich mal die Rechte fuers LOG zu testzwecken auf
chmod 0777 lsyncd

BITTE NUR ZU TESTZWECKEN VERY INSECURE und ausserhalb Testszenario NOGO
sollte es dann starten, Rechte und Eigentümer entsprechend anpassen.

Also mit chmod 0777 lsyncd bekomme ich diese Fehlermeldung nicht mehr. Dafür dann eine, die angbelich den absoluten Pfad des Quell Ordners nicht finden kann, obwohl der definiert ist.

Ist sehr seltsam das Tool. Ich werds mal auf nem anderen Server probieren.

Zitat von @hokaido:

Also mit chmod 0777 lsyncd bekomme ich diese Fehlermeldung nicht mehr.

OK, dann schau mal wem das Logfile nun gehört, also wer ist der Owner?

Dafür dann eine, die angbelich den absoluten Pfad des Quell Ordners nicht finden kann, obwohl der definiert ist.

Geh doch bitte noch mal in dich und versetze dich in unsere Lage. Uns liegt hier nur das vor was du uns an Informationen lieferst. Ohne jegliche Information über deine Konfiguration von lsyncd und Informationen wo Quell- und Zielordner liegen geschweige denn unter welchem Account diese Ordner evt. mit welchen Rechten gemountet sind, oder ob private keys für SSH Accounts nicht richtig hinterlegt sind, können wir hier lange rum raten.

Ist sehr seltsam das Tool.

Wie gesagt lsyncd basiert auf bewährten Tools wie inotifywait und rsync und ist keine große Sache. Das gleiche kannst du dir mit einem simplen Shell-Script auch selber bauen bspw. im einfachsten Fall so
inotify-tools installieren

sudo apt install inotify-tools

Und einem Bash Script ala

#!/bin/bash
SOURCE="/path/to/quelle/"  
TARGET="/path/to/ziel/"  
inotifywait -e close_write -m -q -r "$SOURCE" | while read line ;do  
    rsync -av "$SOURCE" "$TARGET"  
done

Dann noch ne systemd-unit für nen Daemon zusammengetippt und du hast etwas sehr ähnliches ohne weitere Software realisiert.

Grüße Uwe

Vielen Dank. Wie gesagt, am Server ist eigentlich nichts großartiges umkonfiguriert. Alles andere läuft ja einwandfrei.
Quelle und Ziel hatte ich schon div. ausprobiert:
/test/1
/test/2

/home/xyz/quelle
/home/xyz/ziel

etc
SSH Keys funktionieren alle.
Aber ich teste es auch auf dem anderen Server mal.

Da bisher alle Scipte zuverlässig laufen, würde ich das auch ausprobieren. Quelle und Ziel sind klar, aber worauf bezieht sich "/path/to/folder".

Zitat von @hokaido:
Quelle und Ziel sind klar, aber worauf bezieht sich "/path/to/folder".

Auf den Quellordner, hatte den Namen hinterher aber nochmal angepasst das es eindeutiger ist. INotify muss ja die Quelle auf Änderungen überwachen nicht das Ziel

Danke, das probier ich doch gleich mal

Kannst du meine erste Frage aus dem vorletzten Post evtl auch noch beantworten, da du dich ja scheust hier vollständige Configs zu posten.

Zitat von @colinardo:
OK, dann schau mal wem das Logfile nach dem Anpassen der Rechte nun gehört, also wer ist der Owner?

Also auf dem anderen Server läuft lsyncd ohne irgendwelche Anpassungen der Rechte. Lediglich das
Log Verzeichnis und die Log Datei musste ich manuell anlegen (ohne manuellen Eingriff ging es nicht):

mkdir /var/log/lsyncd
touch /var/log/lsyncd/lsyncd.log
service lsyncd restart

Lösche ich allerdings die Dateien aus dem Quellordner, sind Sie auch aus dem Zielordner weg. Die Dateien aber nur an einem Ort zu haben, war das Ziel.

Die Dateien sollen also von der Quelle zum Ziel kopiert werden und dann aus Quelle gelöscht werden, oder aber gleich komplett nach Ziel verschoben werden

Zitat von @hokaido:

Also auf dem anderen Server läuft lsyncd ohne irgendwelche Anpassungen der Rechte.

Jepp.

Lediglich das
Log Verzeichnis und die Log Datei musste ich manuell anlegen (ohne manuellen Eingriff ging es nicht):

Log Verzeichnis anlegen reicht, die Log-Datei erstellt lsyncd selbst!

Lösche ich allerdings die Dateien aus dem Quellordner, sind Sie auch aus dem Zielordner weg.

Das musst du ja über die Config Datei von lsyncd konfigurieren, dort gibt es die Direktive delete die du auf false festlegen musst!

delete = false

https://axkibe.github.io/lsyncd/manual/config/layer4/
Wie gesagt baut lsyncd auf rsync auf und kennt deshalb so gut wie alle Parameter von diesem welche sich in der lsyncd config konfigurieren lassen.
Warum liest hier eigentlich keiner mehr Dokumentationen?!

Naja, delete = false hab ich schon eingebaut gehabt.
Löscht mir die Dateien aus beiden Ordnern, sowohl Quelle als auch Ziel

Zitat von @hokaido:

Naja, delete = false hab ich schon eingebaut gehabt.
Löscht mir die Dateien aus beiden Ordnern, sowohl Quelle als auch Ziel

Das ist Blödsinn! Das würde auch rsync niemals machen und tut es hier auch nicht! Die Quelle fast rsync niemals an.
Du erzählst hier ein Märchen nach dem anderen, sorry.

Deletions
By default Lsyncd will delete files on the target that are not present at the source since this is a fundamental part of the idea of keeping the target in sync with the source. However, many users requested exceptions for this, for various reasons, so all default implementations take delete as an additional parameter.

Valid values for delete are:

delete	=	true	Default. Lsyncd will delete on the target whatever is not in the source. At startup and what's being deleted during normal operation.  
delete	=	false	Lsyncd will not delete any files on the target. Not on startup nor on normal operation. (Overwrites are possible though)
delete	=	'startup'	Lsyncd will delete files on the target when it starts up but not on normal operation.  
delete	=	'running'	Lsyncd will not delete files on the target when it starts up but will delete those that are removed during normal operation.  

Zusätzlich lassen sich Aktionen nach dem Durchlauf konfigurieren
https://axkibe.github.io/lsyncd/manual/config/layer3/

Ich bin jetzt raus. Lsyncd arbeitet einwandfrei man muss es nur mit den richtigen Parametern füttern.

Viel Erfolg
Grüße Uwe

Und der delete Befehl kann in jeder Ausprägung nur aus dem Ziel löschen. Und genau da sollen die Dateien bleiben. Sie sollen in der Quelle nach dem kopieren gelöscht werden oder eben gleich verschoben. Das geht aber anscheinend nicht.

Zitat von @hokaido:

Und der delete Befehl kann in jeder Ausprägung nur aus dem Ziel löschen.

Korrekt aber das tut er nur wenn die Option falsch oder nicht gesetzt ist.

Und genau da sollen die Dateien bleiben.

Was delete = false ja schon macht. Es verhindert das in der Quelle gelöschte Dateien im Ziel auch gelöscht werden.

Sie sollen in der Quelle nach dem kopieren gelöscht werden oder eben gleich verschoben. Das geht aber anscheinend nicht.

Doch das geht, genau deswegen habe ich in meinem letzten Post den Link zu den 'Actions" gepostet, darin kannst du ein Löschbefehl für die Quelldateien hinterlegen, der nach dem Übertragen automatisch ausgeführt wird.
https://axkibe.github.io/lsyncd/manual/config/layer3/

Alternativ kannst du rsync in den lsyncd Optionen den Parameter --remove-source-files mitgeben der erledigt das gleich mit.

So damit das hier jetzt mal zu einem Ende kommt hat eine funktionsfähige Basis-Config die das macht was du oben geschildert hast nämlich folgendes:

Einen Quell-Ordner mit einem Zielordner One-Way synchronisieren ohne bereits existierende Dateien im Ziel zu löschen und nach der Übertragung die im Quellordner eingeworfenen Dateien zu löschen.

settings {
	logfile = "/var/log/lsyncd/lsyncd.log",  
	statusFile = "/var/log/lsyncd/lsyncd.status",  
	statusInterval = 20,
	nodaemon = false
}
sync {
	default.rsync,
	source = "/test/source",  
	target = "/test/target",  
	delay = 5,
	delete = false,
	rsync = {
		_extra = { "--remove-source-files" }  
	}
}

Vor dem Sync

Nach dem Sync

Fazit: Works how it was as designed.

Grüße Uwe

Wenns das dann war, den Beitrag bitte noch auf gelöst setzen, und Lösungen markieren. Merci.

-edit-

Wenn man dann noch leere von rsync hinterlassene Ordner in der Quelle tilgen möchte geht das mit folgender Config

settings {
	logfile = "/var/log/lsyncd/lsyncd.log",  
	statusFile = "/var/log/lsyncd/lsyncd.status",  
	statusInterval = 20,
	nodaemon = false
}
sync {
	default.rsync,
	source = "/test/source",  
	target = "/test/target",  
	delay = 5,
	delete = false,
	rsync = {
		binary = "/test/lsyncd.sh",  
		_extra = { "--remove-source-files" }  
	}
}

Statt dem rsync Binary gibt man den Pfad zu einem benutzerdefiniertem Script (im Beispiel "/test/lsyncd.sh") an und fügt dort folgendes ein:

#!/bin/bash
/usr/bin/rsync "$@"  
result=$?
if [ $result -eq 0 ];then
	find /test/source/* -type d -empty -delete
fi
exit $result

Das führt also den Rsync Befehl nach Vorgabe von lsyncd aus und bei Erfolg löscht es leere Unterordner aus der Quelle.

Danke.
Für alle, die ähnliches suchen. Damit ihr nicht mühsam suchen müsst:

settings {
logfile = "/var/log/lsyncd/lsyncd.log",
statusFile = "/var/log/lsyncd/lsyncd.status",
statusInterval = 20,
nodaemon = false
}

sync {
default.rsync,
source = "/Quelle",
target = "/Ziel",
delete = false,
rsync = {
_extra = { "--remove-source-files" }
}
}

Nur noch eine kurze Rückmeldung:
Das funktioniert soweit jetzt einwandfrei. Danke.
Falls jemand aber damit wie ich die Dateien in die Nextcloud verschieben will => Dort kann man die Dateien nicht öffnen, weil sie alle dem Besitzer root zugeordnet werden. Alle Dateien für Nextcloud müssen aber den Besitzer www-data haben.

Wenn man den Benutzer dabei gleich ändern will, dann so. Dann funktioniert es:
Lösung hokaido vor 22 Stunden | Bearbeiten
quote
Goto Top
Danke.
Für alle, die ähnliches suchen. Damit ihr nicht mühsam suchen müsst:

settings {
logfile = "/var/log/lsyncd/lsyncd.log",
statusFile = "/var/log/lsyncd/lsyncd.status",
statusInterval = 20,
nodaemon = false
}

sync {
default.rsync,
source = "/Quelle",
target = "/Ziel",
delete = false,
rsync = {
_extra = {"-og", "--chown=www-data:www-data", "--remove-source-files"}
}
}

Damit ihr nicht mühsam suchen müsst:

Wäre doch mal klasse und hilft der Community hier wenn du die Snippets und Screenshots von oben mal zusammensammelst und davon mal ein tolles Tutorial für alle machst !! 😉
Solche Szenarien werden ja gefühlt mindestens 3mal pro Woche hier gefragt und ein Tutorial würde garantiert helfen !

German solved Question Ubuntu Linux

Hotly discussed

End of availability for classic Teams clientDani - 2 Comments

Ubuntu 24.04 LTS Noble Numbat availableFrank

Developer diary: Release 6.1admtech