Update nicht möglich, da Systempartition voll

oberhex

Benutzer
Mitglied seit
18. Apr 2015
Beiträge
15
Punkte für Reaktionen
3
Punkte
3
Ok, sorry - danke hab mich vertan! ok du hast recht, da ist ne 1.1GB-Datei "synosmartblock"

root@DS916:/lib# cd /var/lib
root@DS916:/var/lib# du -xhd1
12K ./letsencrypt
120K ./data_update
24K ./drive_attribute
32K ./temperature
2.0M ./disk-compatibility
16K ./net-snmp
4.0K ./ldap
1.1G ./synosmartblock
3.7M ./portforward
8.0K ./btrfs
8.0K ./securityscan
20K ./postfix
4.0K ./raid_bitmap
4.0K ./ntp
32K ./synologan
40K ./sss
8.0K ./dovecot
236K ./smartmontools
8.0K ./ssd-bundle
8.0K ./datascrubbing
16K ./dpkg
16K ./nfs
8.0K ./openvswitch
1.8M ./samba
20K ./diskaction
4.0K ./drbd
8.0K ./systemd
32K ./space
16K ./memory-compatibility
1.1G .
 

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.310
Punkte für Reaktionen
2.870
Punkte
423
Und was liegt dort? Bei mir eine kleine db.sqlite-Datei
Code:
root@DS415:~# ls -als /var/lib/synosmartblock
total 116
  4 drwx------  2 root root   4096 Dec  4 15:41 .
  4 drwxr-xr-x 37 root root   4096 Dec  5 14:42 ..
108 -rw-------  1 root root 105472 Dec  4 15:41 db.sqlite
Ich bin mir nicht sicher, aber das könnte eine Datenbank sein, in der geblockte Zugriffe geloggt werden. War da was?
 

oberhex

Benutzer
Mitglied seit
18. Apr 2015
Beiträge
15
Punkte für Reaktionen
3
Punkte
3
Ja, da liegt ne Datenbank-Datei!....mir wär nichts bewusst.

root@DS916:/var/lib# ls -als /var/lib/synosmartblock
total 1085596
4 drwx------ 2 root root 4096 Dec 5 00:08 .
4 drwxr-xr-x 31 root root 4096 Dec 5 15:14 ..
1085540 -rw------- 1 root root 1109590016 Dec 5 00:28 db.sqlite
16 -rw------- 1 root root 16384 Dec 5 15:14 db.sqlite-shm
32 -rw------- 1 root root 32768 Dec 5 00:28 db.sqlite-wal
root@DS916:/var/lib#
 

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.310
Punkte für Reaktionen
2.870
Punkte
423
Da bläst wohl irgendwas Daten rein, weiß aber nicht was.
Hier war mal ein ähnlicher Fall. Da wurde das Verzeichnis einfach geleert. Das kann aber m.E. nicht die Lösung sein.
Ist unter Systemsteuerung, Sicherheit, Schutz, Freigabe-/Blockierungsliste was zu finden?
 

oberhex

Benutzer
Mitglied seit
18. Apr 2015
Beiträge
15
Punkte für Reaktionen
3
Punkte
3
Hi Benares,
nein ist komplett leer! Keine Ahnung.
Hab den Thread kurz überflogen. Habe auch den iO-Broker via Docker installiert, läuft aber nicht produktiv, war mal zum testen. Werde den jetzt mal auch löschen!
Vielen Dank mal dir und allen anderen, welche geholfen haben!
Werde jetzt mal weitersuchen!
Gruß
 

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.310
Punkte für Reaktionen
2.870
Punkte
423
Löschen brauchst du nicht, Container anhalten reicht.
Halt mal den Zeitstempel und die Größe der Dateien dort etwas im Auge. Wenn etwas Ruhe einkehrt, würde ich die Dateien dort löschen und die DS neu starten. Ich hoffe, dass die Datenbank dann neu angelegt wird.
 

peterhoffmann

Benutzer
Sehr erfahren
Mitglied seit
17. Dez 2014
Beiträge
5.555
Punkte für Reaktionen
1.394
Punkte
234
Code:
root@DS716+ /var/lib/synosmartblock $ ls -la
total 204
drwx------  2 root root   4096 Nov 29 14:38 .
drwxr-xr-x 25 root root   4096 Dec  5 12:31 ..
-rw-------  1 root root 196608 Nov 29 14:38 db.sqlite
Bei mir hat sie auch nur 200kb und ist das letzte Mal vor 6 Tagen geändert worden.
 

oberhex

Benutzer
Mitglied seit
18. Apr 2015
Beiträge
15
Punkte für Reaktionen
3
Punkte
3
Hi nochmal...hab die Dateien gelöscht und den Docker-Container ebenso! Jetzt läuft wieder alles wie es soll! Danke nochmal an alle die geholfen haben! Wünsch euch einen schönen Advent!!
 

akoerber

Benutzer
Mitglied seit
31. Mrz 2017
Beiträge
120
Punkte für Reaktionen
1
Punkte
18
Ich hatte das Problem auch und habe /var/lib/synosmartblock gelöscht. Das hat wohl etwas mit der Blockierung von Adressen nach mehrfachem BruteForce-Einlog-Versuchen zu tun (Systemsteuerung/Sicherheit/Schutz). Da muss man wohl einstellen, dass diese Blockierung auch wieder endet (also Adressen nach einiger Zeit herausgenommen werden), sonst läuft das voll.

Nun habe ich aber gefunden, dass auch weitere sehr voll sind in /usr/bin/, v.a. folgende. Weiß jd, was die sind und ob man die löschen, klein bekommen kann?

  1. synonode
  2. slapcat32
  3. sqlite3
  4. postgres
  5. php
 

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.137
Punkte für Reaktionen
898
Punkte
424
Was heißt denn "sehr voll"?
In /bin/ Verzeichnissen liegen binaries, ausführbare Programme (bsp. unter Windows .exe Dateien). Die kann man nicht kleiner bekommen als sie sind.
 

Nordlicht01

Benutzer
Mitglied seit
31. Aug 2014
Beiträge
271
Punkte für Reaktionen
10
Punkte
18
Hallo zusammen,

ich habe unter DSM 7.2-64570 auch das Problem, dass die Systemkapazität nicht ausreicht.

Das Systemverzeichnis (?) /dev/md0 ist zu 79% benutzt. Alleine im Verzeichnis /usr schlummern 1,2G

Code:
root@DS_MK_920:/usr# df -h
Filesystem              Size  Used Avail Use% Mounted on
/dev/md0                2.3G  1.8G  466M  79% /
devtmpfs                9.7G     0  9.7G   0% /dev
tmpfs                   9.7G  244K  9.7G   1% /dev/shm
tmpfs                   9.7G   37M  9.7G   1% /run
tmpfs                   9.7G     0  9.7G   0% /sys/fs/cgroup
tmpfs                   9.7G  2.5M  9.7G   1% /tmp
tmpfs                   2.0G     0  2.0G   0% /run/user/196791
/dev/mapper/cachedev_0   11T  5.9T  4.7T  56% /volume1
tmpfs                   1.0T  4.0G 1020G   1% /dev/virtualization

root@DS_MK_920:/usr# /usr/bin/du -d 1 -xh /
25M    /root
4.0K    /mnt
4.0K    /lost+found
40K    /.old_patch_info
16K    /opt
214M    /var
2.5M    /etc.defaults
4.2M    /etc
4.0K    /.system_info
9.4M    /var.defaults
1.2G    /usr
291M    /.log.junior
52M    /.syno
4.0K    /initrd
1.8G    /
root@DS_MK_920:/usr#

Code:
root@DS_MK_920:/usr# /usr/bin/du -d 1 -xh /usr
32K    /usr/libexec
16M    /usr/lib32
285M    /usr/local
280M    /usr/syno
336M    /usr/lib
26M    /usr/sbin
76K    /usr/include
20K    /usr/etc
88M    /usr/share
118M    /usr/bin
1.2G    /usr

So richtig stehe ich auf dem Schlauch, wo ich da ansetzen soll bzw. was nicht im grünen Bereich ist bzw. wo ich Dateien löschen kann.

Für Hilfe wäre ich dankbar

Viele Grüße Nordlicht
 

plang.pl

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
14.180
Punkte für Reaktionen
4.915
Punkte
519
Bei mir ist auch 70% belegt. Werde wohl in naher Zukunft neu aufsetzen. Bei neuen Installationen mit DSM 7 ist die Root-Partition wesentlich größer.
Der usr hat bei mir 1,1G, also unwesentlich kleiner als bei dir.
Hast du mit der Belegung aktuell Probleme oder ist dir das einfach nur so aufgefallen?
Aus dem Bauch heraus würde ich mir mal den log.junior ankucken und da ggfs. was rauslöschen.
 

Nordlicht01

Benutzer
Mitglied seit
31. Aug 2014
Beiträge
271
Punkte für Reaktionen
10
Punkte
18
Ich bekomme den Hinweis, dass ich das System nicht aktualisieren, da die Systemkapazität nicht ausreicht.
 

plang.pl

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
14.180
Punkte für Reaktionen
4.915
Punkte
519
Ich sehe da jetzt bis auf den Log Ordner erstmal nix ungewöhnliches. Bin da aber kein Vollprofi drin. Generell muss man sagen, dass Synology vor DSM7 die Root-Partition einfach deutlich zu klein generiert hat.
 

Nordlicht01

Benutzer
Mitglied seit
31. Aug 2014
Beiträge
271
Punkte für Reaktionen
10
Punkte
18
Der Hinweis mit .log.junior war gut. Da steckten folgende Dateien drin:

Code:
-rw-r--r--  1 root root    82944 Apr 21 21:05 logs.tar
-rw-r--r--  1 root root    83456 Mar  9 08:59 logs.tar.1
-rw-r--r--  1 root root 43113984 Jul 29  2023 logs.tar.10
-rw-r--r--  1 root root 43115520 Jul 29  2023 logs.tar.11
-rw-r--r--  1 root root 43119616 Jul 29  2023 logs.tar.12
-rw-r--r--  1 root root 43116544 Jul 29  2023 logs.tar.13
-rw-r--r--  1 root root 43119616 Jul 29  2023 logs.tar.14
-rw-r--r--  1 root root 43131392 Jul 29  2023 logs.tar.15
-rw-r--r--  1 root root 43133440 Jul 29  2023 logs.tar.16
-rw-r--r--  1 root root    82432 Jan 27  2023 logs.tar.17
-rw-r--r--  1 root root    82432 Jan 26  2023 logs.tar.18
-rw-r--r--  1 root root    82432 Jan 14  2023 logs.tar.19
-rw-r--r--  1 root root    82944 Aug 25  2023 logs.tar.2
-rw-r--r--  1 root root    82944 Jan 12  2023 logs.tar.20
-rw-r--r--  1 root root    82944 Jan 12  2023 logs.tar.21
-rw-r--r--  1 root root    82944 Jul 12  2022 logs.tar.22
-rw-r--r--  1 root root    82432 Jul 11  2022 logs.tar.23
-rw-r--r--  1 root root    82432 Jul 11  2022 logs.tar.24
-rw-r--r--  1 root root   167936 Jul  8  2022 logs.tar.25
-rw-r--r--  1 root root    81408 Mar 11  2022 logs.tar.26
-rw-r--r--  1 root root    81920 Feb 23  2022 logs.tar.27
-rw-r--r--  1 root root   153600 Nov  8  2021 logs.tar.28
-rw-r--r--  1 root root    81408 Oct  4  2021 logs.tar.29
-rw-r--r--  1 root root    82944 Aug 13  2023 logs.tar.3
-rw-r--r--  1 root root    80896 Sep 22  2021 logs.tar.30
-rw-r--r--  1 root root    82944 Aug  8  2023 logs.tar.4
-rw-r--r--  1 root root    82944 Aug  1  2023 logs.tar.5
-rw-r--r--  1 root root    82944 Jul 30  2023 logs.tar.6
-rw-r--r--  1 root root    82944 Jul 29  2023 logs.tar.7
-rw-r--r--  1 root root   122880 Jul 29  2023 logs.tar.8
-rw-r--r--  1 root root   229888 Jul 29  2023 logs.tar.9

Die habe ich mal einfach gelöscht und jetzt ist die Meldung weg.
 

plang.pl

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
14.180
Punkte für Reaktionen
4.915
Punkte
519
Jawoll. Bei mir hat der genannte Ordner nur 2 MB. Und ich denke, dass man die Daten dort nicht braucht (suggeriert ja der Ordnername).
 

Nordlicht01

Benutzer
Mitglied seit
31. Aug 2014
Beiträge
271
Punkte für Reaktionen
10
Punkte
18
Bei mir ist auch 70% belegt. Werde wohl in naher Zukunft neu aufsetzen. Bei neuen Installationen mit DSM 7 ist die Root-Partition wesentlich größer.
Komplett neu aufsetzen oder nur DSM neu aufsetzen und die Daten erhalten (das geht m.E. oder)?
 

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.310
Punkte für Reaktionen
2.870
Punkte
423
Das mit dem Verzeichnis /.log.junior kannte ich noch nicht. Wozu gehört das?
Es gab da ab DSM7.1 auch mal eine /usr/syno/synoinstall/space-preserve Datei, die Platz auf der System-Partition reservieren sollte und vor jedem Update gelöscht wurde. Ab DSM7.2 hat Synology diese Konzept aber scheinbar wieder aufgegeben. Schau mal nach, ob die bei dir evtl. noch da ist.
 
  • Like
Reaktionen: Benie

plang.pl

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
14.180
Punkte für Reaktionen
4.915
Punkte
519
Wenn man die größere Root-Partition will, muss man tatsächlich komplett neu aufsetzen.
 

Nordlicht01

Benutzer
Mitglied seit
31. Aug 2014
Beiträge
271
Punkte für Reaktionen
10
Punkte
18
In dem Ordner /usr/syno/synoinstall/space-preserve-for-configs gabe es jede Menge temp-config Dateien; auch mit Datum 29.07.2023 wie die tar-Archive in .lg.junior

Jetzt habe ich 66% frei
 


 

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