Volume 2 von 95% auf 5% ohne erkennbaren Grund

[Seppareh82]

Hallo zusammen,

ich habe ein für mich nicht nachvollziehbares Problem:
Mittels Safari war ich gerade im DSM "online"; auf dem Desktop habe ich ein Widget vom Speichermanager, was den Status von Volume 1 (meine Daten im RAID1) und Volume 2 (eine HDD für die Videoaufzeichnung der Surveillance Station).
Volume 2 liegt immer bei 95%, dann werden alte Aufzeichnungen überschrieben.
Dann - ohne erkennbaren Grund - ging vor meinen Augen der Balken auf 5% und sämtliche Aufzeichnungen älter 1 Tag waren weg.... ich habe parallel gerade mit HyperBackup ein Backup von Volume 1 auf eine ext. HDD gemacht, aber das mache ich schon seit ca. 1 Jahr ungefähr 1mal pro Woche ... das kann nicht der Grund gewesen sein.
Jetzt stelle ich mir die Frage, wie das passieren kann? Es kam noch eine Meldung der Speicherplatzrückgewinnung. Die habe ich leider zu schnell weggeklickt, aber das kann doch nicht der Grund gewesen sein???

Also jetzt die Frage: Wie finde ich raus, warum die Volume 2 plötzlich 90% des Inhaltes verliert ohne erkennbaren Grund. Und auch zum erstem Mal? Kann man das ggf. in Logdaten irgendwo einsehen?

Die DS ist eine DS920+; DSM ist die Version 7.1-42661

Ich bin für jede Idee Dankbar!

 

[iceman23]

hast mal im papierkorb geschaut. moin

 

[Seppareh82]

Hallo Iceman,

Vielen Dank für deine Antwort.
Nein, habe ich ehrlich gesagt nicht. Es geht mir in erster Linie nicht um die Daten, die weg sind, sondern warum sie weg sind, also warum sind sie ohne erkennbaren Grund gelöscht beziehungsweise wie finde ich raus, was sie gelöscht hat?

 

[Benie]

Kann man das ggf. in Logdaten irgendwo einsehen?

Hast Du schon mal in den Protokollen nachgeschaut ob sich da was ergibt?

 

[Seppareh82]

Hallo Benie,

Ich vermute du meinst direkt unter „Protokolle“? Nein, da ist keine Meldung bezüglich Löschen von Volume2 enthalten.

 

[ctrlaltdelete]

Schau mal im Protokoll der SS nach.

 

[AndiHeitzer]

Auf den Synos gibt es unter /var/log eine Datei 'rm.log'
Da würde ich nun als nächstes rein gucken ...

Auf meiner DS118 (OBELIX) schaut das so aus:
2022-08-29T12:17:06+02:00 OBELIX rm[26285]: uid: 0, euid: 0, arguments:["/volume1/_WARTUNGS-LOGS_/status4web__collect-data__OBELIX.txt"]
2022-08-29T12:32:06+02:00 OBELIX rm[30519]: uid: 0, euid: 0, arguments:["/volume1/_WARTUNGS-LOGS_/status4web__collect-data__OBELIX.txt"]
2022-08-29T12:47:06+02:00 OBELIX rm[2643]: uid: 0, euid: 0, arguments:["/volume1/_WARTUNGS-LOGS_/status4web__collect-data__OBELIX.txt"]

Da gibt es den Zeitstempel, DSNAME rm-Befehl mit Process-ID und dann was halt gelöscht wurde.
Wenn es hier noch einen LINUX-Spezi gibt, dann gibt das evtl. noch 'ne Info, wie man die PID nachverfolgen kann, wer also der löschende Prozess war.

 

[Seppareh82]

Guten morgen zusammen,

ich glaube ich stehe total auf dem Schlauch ...

@ctrlaltdelete: was meinst Du mit "SS"?
@Andi: ich finde die Datei "rm.log" bzw. das Verzeichnis /var/log nicht ... wo finde ich das?

Danke vorab!

 

[Seppareh82]

Update, Kaffee wirkt ... sorry, SS = Surveillance Station -> nichts auffälliges in den Protokollen zu finden ...

 

[AndiHeitzer]

ich finde die Datei "rm.log" nicht ... in welchem Verzeichnis sollte diese liegen?

Die Info stammt von mir und nicht von Benie ...
Ich hatte geschrieben ...

Auf den Synos gibt es unter /var/log eine Datei 'rm.log'

Dazu wäre allerdings das aufsuchen der LINUX-Konsole nötig.

 

[Seppareh82]

Hallo Andi,
ja, habe ich korrigiert. Sorry für diesen Fauxpas ... Kaffee Nr. 2 scheint zu wirken ...

Du meinst mit Linux-Konsole vermutlich ein Zugriff auf die DS via SSH? Hab gerade eine Verbindung aufgebaut. Allerdings bin ich da (noch) nicht so fit ... ich vermute, es würde zu lange dauern, das zu beschreiben, wie ich im Terminal bzw. via SSH auf diesen Pfad / dieses Verzeichnis komme?

UPDATE:
Hab die Datei gefunden ... konnte sie bisher nicht öffnen ...

 

[AndiHeitzer]

Kein Problem
Kaffee ist immer gut.

Ja, SSH zur DS ist damit gemeint.
Der Weg zum Verzeichnis wäre ...
cd /var/log
Dort dann ...
cat rm.log

Dann wirst Du recht viele Zeilen sehen ...

Was evtl. noch nötig sein wird, als allererstes zum Benutzer root wechseln, weil Du evtl. nicht die nötigen Rechte haben könntest um in /var/log hinein zu wechseln. Somit als erstes noch einen ...
sudo -i
absetzen. Du wirst nach einem Passwort gefragt. Hier dann das PW des Benutzers 'admin' verwenden.
Da der 'root' alles darf, gehe bitte mit äusserster Sorgfalt damit um, bevor Du 'irgendwelche' Befehle absetzen wirst. LINUX fragt nämlich nicht 'willst Du wirklich ...'

 

[Seppareh82]

Hallo Andi,
vielen Dank für Deine Hilfe an dieser Stelle schon mal.
Eine kurze, abweichende Frage zum Benutzer 'admin': der DSM empfiehlt, diesen Benutzer zu deaktivieren. Ist das sinnvoll?
Und ein Terminal direkt im DSM gibt es nicht, d.h. es muss immer der "Umweg" über SSH gemacht werden?

UPDATE:
ins Verzeichnis /var/log komme ich ohne "sudo -i". Allerdings kommt nach dem Befehl "cat rm.log" die Meldung "permission denied". Das PW vom admin bei Abfrage nach "sudo -i" geht nicht ... muss noch herausfinden, was da wieder nicht passt ...

 

[AndiHeitzer]

Kein Problem, alles wird gut. Und bissel was dazulernen hat noch nie geschadet.
Ja, der 'admin' wird empfohlen, zu deaktivieren. Das wird gemacht, weil das ein Standard-Account ist.
Meine erste Aktion, einen eigenen Account anzulegen, der Mitglied der Administratoren ist. Danach habe ich den 'admin' deaktiviert.
Ansonsten bin ich halt mit einem normalen Anwendungsaccount unterwegs.

Nein ein Terminal, das vom DSM aus genutzt werden kann, gibt es nicht (mehr).
Das mit dem Umweg, ja, ist nicht zu vermeiden.
Ich habe allerdings bei mir folgendes gemacht, um von DSM aus das Verzeichnis '/var/log' zur Verfügung zu haben ...
- Einen gemeinsamen Ordner erstellt (z.B. SYSTEMLOGS)
- Ein Script erstellt, dass mir den Inhalt von '/var/log' nach 'SYSTEMLOGS' kopiert
- Im Aufgabenplaner das KopierScript eingebaut, das zyklisch rennt, oder ich bei Bedarf manuell starte.

So habe ich, ohne die Konsole nutzen zu müssen, den Inhalt von '/var/log' in diesem gemeinsamen Ordner, den ich per Filestation durchforsten kann.
Das ist nicht viel, so etwa 120MB, das kann man locker verschmerzen.

 

[Seppareh82]

Hallo Andi,
war jetzt länger nicht online.
Also konnte die rm.log öffnen und in entsprechenden Zeitraum einen Haufen Log-Einträge sichten; ich acker die jetzt mal durch und google, was da im Details drin steckt. Vielleicht komme ich ja auf die Lösung, warum auf einmal mein Volume2 ca. 90% der Daten verloren hat ... auf alle Fälle vielen Dank für Deine / Eure Hilfe !!

Tolles Forum,
weiter so!

 

[Seppareh82]

also ich habe genau zwei Einträge bzgl. Volume2 in der Datei rm.log:

....
2022-08-28T17:31:55+02:00 Pluto rm[10313]: uid: 0, euid: 0, arguments:["-rf" "/volume2/@tmp.del"]
...
2022-08-28T17:32:29+02:00 Pluto rm[11204]: uid: 0, euid: 0, arguments:["-rf" "/volume2/surveillance/@eaDir/@tmp.10943"]
...

jetzt die Frage:
was bedeuten diese beiden Einträge?
Sonst ist am 28.08. kein Einträg mehr mit "volume2" in der rm.log enthalten; an diesem Tag sank der Dateninhalt von 95% auf 5% ohne für mich erkennbaren Grund ...

oder anders gefragt: nach was muss ich suchen?

 

[Benares]

Der Tipp von @AndiHeitzer mit den /var/log/rm.logs war nicht schlecht. Dort werden alle Lösch-Aktionen geloggt. Nach einer gewissen Zeit wird rm.log aber wohl irgendwie gezippt/umbenannt/neu gestartet, so dass in rm.log evtl. nicht mehr alles drin ist. Mein rm.log reicht bis 10.08. zurück.

root@DS415:/var/log# ls -als rm*
 36 -rw-rw---- 1 system log  31419 Aug 30 20:42 rm.log
 72 -rw-rw---- 1 system log  73680 Aug 10 14:08 rm.log.1.xz
 56 -rw-rw---- 1 system log  53320 Sep  1  2021 rm.log.2.xz
232 -rw-rw---- 1 system log 235668 Jun 23  2020 rm.log.3.xz

Wie man sich die Vorgänger anschauen kann (die .xz-Dateien) habe ich auf die Schnelle auch nicht rausgefunden.
Trotzdem vermisse ich in der rm.log auch Löschvorgänge, die ich kürzlich selbst vorgenommen habe.

Wie ist das bei dir? Deckt die aktuelle rm.log noch den Zeitraum ab?

Andere Idee. Hast du dir im Protoll-Center mal die Protokolle zur "Dateiübertragung" angeschaut?
Ich fürchte aber, dass dort (mit den Default-Einstellungen), nur die Löschungen protokolliert werden, die via SMB stattfinden.



Edit: Hab's rausgefunden. Die älteren kann man mit z.B. "7z e rm.log.1.xz" auspacken (-> rm.log.1) und dann mit "cat rm.log.1" anschauen.

 

[Rotbart]

Entpacken sollte eigentlich in der Konsole mit

xz -d datei.xz

funktionieren

 

[AndiHeitzer]

Ich verwende den MidnightCommander auf meinen Kisten, und mit dem kann ich direkt hineingucken. Auch in die TAR-Archive.

Dann mal zu dem, was da oben von @Seppareh82 dargestellt wurde:
2022-08-28T17:31:55+02:00 Pluto rm[10313]: uid: 0, euid: 0, arguments:["-rf" "/volume2/@tmp.del"]

Der Zeitstempel ist wohl hoffentlich klar.
Dann kommt ein Account/User 'Pluto', der, soweit ich das verstehe, unter 'root' (sagt mir die 'uid: 0' und euid*** sagt mir nix) einen Löschvorgang 'rm' angestossen hat. Als Parameter wurde '-rf' (recursive & force) im Verzeichnis '/volume2/@tmp.del' angewendet.
Die letzte Frage wäre, was zum fraglichen Zeitpunkt als Prozess '10313' diese Aktion ausgelöst hat bzw., welcher Prozess als ID 10313 unterwegs war.
Da gehen mir nun die Ideen aus ...

 

[Benares]

"xz -d rm.log.1.xz" geht, aber es kommt "xz: rm.log.1.xz: Cannot remove: Operation not permitted".
Aber die rm.log.1 ist dann da.
Ich frag mich grad, wie viele Entpack-Programme es unter Linux/auf den DS eigentlich gibt

Edit: "xzcat rm.log.1.xz" gibt's auch. Damit kann man sich diese .xz-Dateien ohne Entpacken direkt anzeigen lassen.
Edit2: Die Prozess-ID herauszufinden dürfte dann die nächste Hürde sein, sofern der der Prozess überhaupt noch läuft. "ps -ef | grep <ID>"?