Bekomme Skript nicht zum laufen

LPG Parts

Benutzer
Mitglied seit
22. Jan 2014
Beiträge
9
Punkte für Reaktionen
0
Punkte
1
Hallo liebe Experten :)

ich habe eigentlich eine "wahrscheinlich einfache" Sache für euch, für mich leider zum verzweifeln 🙃.

Grundsätzlich geht es mir darum, in einem Freigegebenen Ordner Dateien zu löschen welche älter wie 3 Tage sind.
Bei meiner alten DS713 hat folgender Befehl seit Jahren funktioniert:

find /volume1/"Verzeichnis" -mtime +3 -type f -delete

Nun habe ich die NAS gewechselt auf eine DS224 aber seitdem funktioniert dieser nicht mehr.

Hier bekomme ich folgende Fehlermeldung:

find: `/volume1/"Verzeichnis"/@eaDir/SYNO@.fileindexdb': Permission denied

Der Synolgy Support sagt dazu folgendes:

Basierend auf der Fehlermeldung ist eine Systemdatei, die nicht gelöscht werden kann. Andernfalls wird das DSM nicht mehr ordnungsgemäß funktionieren.

Wir empfehlen Ihnen, Verzeichnisse oder Dateien wie @eaDir und SYNO@ auszuschließen, um das Löschen von Systemdateien zu verhindern.

Soweit so gut...
Gerne kann ich mich auf avi Dateien beschränken und habe somit folgende Befehle getestet:

find /volume1/"Verzeichnis" -name ".avi" -mtime +1 -exec rm {} \;

Aber die Fehlermeldung bleibt weiterhin identisch :-(

Ich hoffe mir kann hier jemand helfen.
 

maxblank

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
25. Nov 2022
Beiträge
4.929
Punkte für Reaktionen
2.733
Punkte
289
Hallo @LPG Parts und Willkommen im Forum!

Das Script führst du als Benutzer "Root“ aus?

Grüße
maxblank
 

LPG Parts

Benutzer
Mitglied seit
22. Jan 2014
Beiträge
9
Punkte für Reaktionen
0
Punkte
1
Habe ich versucht aber egal welcher Nutzer ob root admin es funktioniert nicht.
Bzw. Neue Erkenntnis sobald ich die zeitoption (mtime oder atime) entfernen, funktioniert es. Aber die zeit ist ja zwingend erforderlich...
 

maxblank

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
25. Nov 2022
Beiträge
4.929
Punkte für Reaktionen
2.733
Punkte
289
Wenn du das als Root über die Console ausführst, sollte doch eine eindeutige Fehlermeldung kommen…

In deinem Fall nicht genügend Berechtigung auf die DB der Indexierung - so steht es dort zumindest. Dann mach doch das, was dir der Support schreibt und klammere diese Verzeichnisse aus.

Vorschlag:
Bash:
#!/bin/bash

# Definiere das Zielverzeichnis
TARGET_DIR="/volume1/Verzeichnis"

# Finde und lösche Dateien älter als 3 Tage, während bestimmte Verzeichnisse oder Dateien ausgeschlossen werden
find "$TARGET_DIR" -type f -mtime +3 ! -path "*/@eaDir/*" ! -path "*/SYNO@/*" -delete

# Finde und lösche leere Verzeichnisse, wobei die ausgeschlossenen Ordner ignoriert werden
find "$TARGET_DIR" -type d -empty ! -name "@eaDir" ! -name "SYNO@" -delete

echo "Bereinigung abgeschlossen."

Script benennen und speichern: bereinigung.sh
Datei ausführbar machen: chmod +x bereinigung.sh

Script ausführen als Root mit: ./bereinigung.sh
 
Zuletzt bearbeitet:
  • Like
Reaktionen: DaveR

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.888
Punkte für Reaktionen
1.871
Punkte
314
Nur so ein Gedanke…

Wenn du mit find nach -type f, also nach Dateien suchst, dann brauchst du Verzeichnisse nicht mehr von der Suche ausschließen, oder? Und @eaDir ist definitiv ein Verzeichnis. Von daher sollte der Ursprüngliche Befehl, den @LPG Parts ganz am Anfang gepostet hat, eigentlich funktionieren, wobei ich die Anführungszeichen anders setzten würde oder ggf. komplett weglassen würde, sollte der Verzeichnisname keine Leerzeichen enthalten,

Bash:
find "/volume1/Verzeichnis" -mtime +3 -type f -delete

Vermutlich hatte er den Befehl nur nicht als root ausgeführt. Das würde in meinen Augen die Ausgabe eines Permission denied erklären, denn wer sonst außer root sollte so was können dürfen.
 
  • Like
Reaktionen: maxblank

maxblank

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
25. Nov 2022
Beiträge
4.929
Punkte für Reaktionen
2.733
Punkte
289
Das hatte ich angefragt und er meinte, dass es als Root ausgeführt worden wäre.

Ich wollte nur sicher gehen, dass nicht zuviel gelöscht wird, bin da zu lange raus. 😉
 

Hagen2000

Benutzer
Mitglied seit
25. Mai 2016
Beiträge
404
Punkte für Reaktionen
151
Punkte
43
@LPG Parts Das muss doch … -name "*.avi" … heißen (mit Sternchen).
@Tommes SYNO@.fileindexdb ist doch aber kein Directory - oder?
@maxblank Deine Pfadangabe "*/SYNO@/*" passt nicht zu SYNO@.fileindexdb.
 

LPG Parts

Benutzer
Mitglied seit
22. Jan 2014
Beiträge
9
Punkte für Reaktionen
0
Punkte
1
Korrekt als Root wurde es ausgeführt aber dennoch kommt die Fehlermeldung.

@Tommes
Deine zeile funktioniert nur wenn ich das - mtime +3 weglassen, nur das er mir dann natürlich alles löscht unabhängig von der Zeit.
Füge ich die zeitoption wieder ein funktioniert es nicht.

Frage dazu, mtime +3, muss die Datei dann exakt 3 Tage alt sein oder mindestens 3 Tage?

@maxblank
Ich mache das ganze über den aufgabenplaner in der synology.
Ich glaube dein Weg ist ein anderer oder?
So gut bin ich leider nicht in dem ganzen :-(

Ich wäre ja sogar bereit gegen Zahlung per remote hilfe anzunehmen Hauptsache es funktioniert bald...habe schon stunden damit verbracht 😀
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.888
Punkte für Reaktionen
1.871
Punkte
314
Ich bin mit find auch nicht super vertraut, meine aber, das hierbei nicht automatisch rekursiv gesucht wird. Falls doch… und das versuche ich grade noch herauszufinden… könnte man mit der Option -maxdepth 0 das Ganze auf das angegebene Verzeichnis begrenzen, also in etwa so…

Bash:
find "/volume1/Verzeichnis" -maxdepth 0 -mtime +3 -type f -delete

Kann auch sein, das ich grade Blödsinn erzählt habe… denn das könnte die Ausgabe eines Permission denied auch erklären, wenn man als normaler Benutzer versucht etwas im Verzeichnis @eaDir zu löschen, wenn find standardmäßig rekursiv sucht.

SYNO@.fileindexdb ist doch aber kein Directory - oder?
Frag mich! Könnte auch ein Symlink auf eine Datenbank oder sowas sein. fileindexdb würde ja dafür sprechen. Jedoch sagt das Permission denied ja, das im Verzeichnis /@eaDir die Datei!?! SYNO@.fileindexdb nicht gelöscht werden konnte (/@eaDir/SYNO@.fileindexdb) was wiederum für eine rekursive Suche sprechen würde.
 
  • Like
Reaktionen: geimist

LPG Parts

Benutzer
Mitglied seit
22. Jan 2014
Beiträge
9
Punkte für Reaktionen
0
Punkte
1
Ja das hilft mir sehr viel, bzw. Verstehe ich davon nichts 😉
Gibt es denn eine Erklärung warum meins nicht funktioniert sobald das -mtime +3 nicht funktioniert?
 

Hagen2000

Benutzer
Mitglied seit
25. Mai 2016
Beiträge
404
Punkte für Reaktionen
151
Punkte
43
Doch, find sucht rekursiv.
Normalerweise macht find bei Zugriffsfehlern auch weiter, das sind also im Prinzip nur Warnungen. Aber der Exit-Code weist dann am Ende einen Fehler auf und der Aufgabenplaner zeigt dann vermutlich diesen Fehler an. Sollte aber trotzdem funktioniert haben. Ansonsten hat maxblank ja schon gute Vorschläge gemacht.
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.888
Punkte für Reaktionen
1.871
Punkte
314
Doch, find sucht rekursiv.
Das habe ich auch grade herausgefunden. Von daher ja, entweder Unterverzeichnisse ausschließen, in denen nicht gesucht werden soll, so wie @maxblank bereits schrieb, oder aber die Suche auf das eigentliche Verzeichnis mit -maxdepth 0 beschränken, so wie ich schrieb.
 
  • Like
Reaktionen: maxblank

LPG Parts

Benutzer
Mitglied seit
22. Jan 2014
Beiträge
9
Punkte für Reaktionen
0
Punkte
1
Leute eure Hilfe in allen Ehren und vielen dank, aber wir kommen grad vom Thema weg....

Das Problem ist lediglich die zeitoption...

find /volume1/Verzeichnis -type f -delete (funktioniert)

find /volume1/Verzeichnis -mtime +3 -type f -delete
(Funktioniert nicht und ja dateien sind definitiv älter wie 3 tage, ganz sicher)

Das ist die einzige Frage...warum?

Falls jemand bereit wäre per remote zu helfen, ich möchte nichts geschenkt haben!?
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.888
Punkte für Reaktionen
1.871
Punkte
314

LPG Parts

Benutzer
Mitglied seit
22. Jan 2014
Beiträge
9
Punkte für Reaktionen
0
Punkte
1
...bei dir funktioniert, dann müssten theoretisch alle Dateien rekursiv gelöscht worden sein. Ist das so?

Ja das ist so, zum Glück habe ich eine nas mit mehreren Verzeichnissen wo ältere Dateien liegen um es zu testen.
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.888
Punkte für Reaktionen
1.871
Punkte
314
Einfacher wäre es, wenn du dich auf die Konsole begeben würdest, dann würdest du mehr Feedback erhalten und könntest sehen, was ein…

find /volume1/Verzeichnis -mtime +3 -type f

… ohne die Option -delete überhaupt auswirft, ohne etwas zu löschen. So könnte man sich dann Schritt für Schritt weiter rantasten.

Wenn ich bei mir den Befehl in der Konsole absetze, funktioniert er jedenfalls. Auch kann ich mit dem -mtime Wert rumspielen um die Ausgabe zu verfeinern. Daher kann ich auch nicht nachvollziehe, warum das bei dir zu einem Fehler führt.

Vielleicht gelingt es dir ja anhand dieser Anleitung auf die Konsole zu kommen.
 

maxblank

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
25. Nov 2022
Beiträge
4.929
Punkte für Reaktionen
2.733
Punkte
289
Folgender Änderungsvorschlag:

Bash:
#!/bin/bash

# Zielverzeichnis definieren
TARGET_DIR="/volume1/Verzeichnis"

# Dateien älter als 3 Tage löschen und @eaDir sowie SYNO@ ausschließen
find "$TARGET_DIR" -type f -mtime +3 ! -path "*/@eaDir/*" ! -name "SYNO@.fileindexdb" -delete 2>/dev/null

# Optional: Leere Verzeichnisse löschen, ohne @eaDir-Verzeichnisse anzufassen
find "$TARGET_DIR" -type d -empty ! -name "@eaDir" -delete 2>/dev/null

echo "Bereinigung abgeschlossen."

Ausschließen von @eaDir und SYNO@.fileindexdb:
Mit ! -path "*/@eaDir/*" werden alle Unterverzeichnisse von @eaDir ignoriert und mit
! -name "SYNO@.fileindexdb" wird die spezielle Datei umgangen.

Fehlermeldungen unterdrücken:
Der Teil 2>/dev/null unterdrückt die Permission denied-Meldungen, falls der Zugriff auf systemgeschützte Dateien oder Verzeichnisse erfolgt.

Keine Änderungen an geschützten Systemverzeichnissen: Das Skript behandelt nur Dateien und Verzeichnisse, die explizit zugänglich sind.
 
  • Like
Reaktionen: DaveR

maxblank

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
25. Nov 2022
Beiträge
4.929
Punkte für Reaktionen
2.733
Punkte
289

Jo, bitte vorsichtig mit deinen Daten umgehen. Nicht, dass du mich nachher verfluchst. 😉
 


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat