DSM 6.x und darunter Systempartition voll - letzte Handlungsschritte?

[sonoio]

hallo, jetzt hat es auch mich erwischt mit der Meldung "Nicht ausreichende Kapazität für Aktualisierung. Die Systempartition benötigt mindestens 400 MB". Mit Hilfe des Forums habe ich mir über SSH Zugriff verschafft und mittels df -h festgestellt, dass dev/md0 voll ist.


Was kann ich jetzt mit dieser Info machen, ich weiß leider weder, was md0 ist (mit dem Webmin-Filemanager sehe ich eine Datei md0, aber kein Verzeichnis), noch, wie ich dort wieder für freien Platz sorgen kann. Könnte mir jemand bitte auf die Sprünge helfen, wie ich das über den SSH-Zugriff oder anderweitig wieder in den Griff bekomme?

Danke, SONOiO

 

[goetz]

Hallo,
wenn Du als admin angemeldet bist dann noch ein sudo -i absetzen (Passwort von admin) und dann
http://www.synology-forum.de/showth...md0-ist-voll-die-FAQ-hilft-nicht-(oder-doch-)

Gruß Götz

 

[sonoio]

Danke, ich konnte dort jetzt ein scheinbar schiefgelaufenes Backup löschen und die Diskstation reagiert wieder normal. Dennoch ist /dev/md0 noch immer zu 47 % gefüllt (1,1 GB), ist das ein "normaler" Wert für die Systempartition?

Nochmals danke, SONOiO

 

[Fusion]

Die Systempartition ist ja mit Absicht klein gehalten. Ein Füllstand zwischen 35-50% (Nagel mich jetzt nicht auf eine absolute Grenze fest) sind da absolut normal.

 

[Keef]

Hi !

hab ein bekanntes Proble, aber mangels Linuxunintelligenz komme ich nicht weiter:

df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md0 2.3G 2.1G 157M 93% /
none 1.5G 0 1.5G 0% /dev
/tmp 1.5G 1.6M 1.5G 1% /tmp
/run 1.5G 4.0M 1.5G 1% /run
/dev/shm 1.5G 4.0K 1.5G 1% /dev/shm
none 4.0K 0 4.0K 0% /sys/fs/cgroup
cgmfs 100K 0 100K 0% /run/cgmanager/fs
/dev/md2 11T 5.8T 5.0T 54% /volume1
/dev/sdq1 1.9T 977G 887G 53% /volumeUSB1/usbshare


du -sh /*
0 /bin
0 /config
4.0K /dev
8.7M /etc
7.7M /etc.defaults
4.0K /initrd
0 /lib
0 /lib32
0 /lib64
4.0K /lost+found
4.0K /mnt
du: cannot access ‘/proc/18578’: No such file or directory
du: cannot access ‘/proc/18581/task/18581/fd/4’: No such file or directory
du: cannot access ‘/proc/18581/task/18581/fdinfo/4’: No such file or directory
du: cannot access ‘/proc/18581/fd/4’: No such file or directory
du: cannot access ‘/proc/18581/fdinfo/4’: No such file or directory
0 /proc
20K /root
3.8M /run
0 /sbin
0 /sys
1.6M /tmp
4.0K /tmpRoot
802M /usr
210M /var
6.0M /var.defaults
1001M /video
5.8T /volume1
977G /volumeUSB1

Immerhin habe ich es geschafft als root via putty ins NAS zu kommen.
Und nun ??

wo muss ich was löschen ? /video ? oder wo ganz anders ? Bin echt verweifelt.

CU
Keef

 

[Fusion]

Ja, das video gehört da nicht hin.
Was drin liegt

ls -la /video

Löschen des Ordners

rm -rf /video

 

[Keef]

Hi

Vielen Dank für die Hilfe.
Hat prima geklappt.



CU
Keef

 

[PingIng]

Moin,

was hab ich bloß getan und warum?
Egal - Hauptsache es wird wieder besser - hoffentlich mit eurer Hilfe.

Auch meine DS218+ sagt: Systemkapazität reicht für Aktualisierung nicht aus. Bitte wenden Sie sich ...

Ich habe in letzter Zeit mit Docker hantiert. Werden die Images etwa auf der Systempartition abgelegt?
Alle Container haben ihren jeweiligen Datenordner in einem Mount auf volume1/docker/{container}_data
Ich habe laufen: ioBroker, PI-Hole, deconz (für Zigbee), Portainer

Ich kann aus den folgenden Daten leider keinen Verdächtigen filtern und weiß nicht weiter.

root@Wolke22:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/md0        2.3G  1.9G  324M  86% /
devtmpfs        4.8G     0  4.8G   0% /dev
tmpfs           4.8G  244K  4.8G   1% /dev/shm
tmpfs           4.8G   15M  4.8G   1% /run
tmpfs           4.8G     0  4.8G   0% /sys/fs/cgroup
tmpfs           4.8G  1.8M  4.8G   1% /tmp
tmpfs           981M     0  981M   0% /run/user/196791
/dev/vg1000/lv  3.5T  170G  3.4T   5% /volume1
shm              64M  1.5M   63M   3% /volume1/@docker/containers/759dbe90aafcee8e42000ddbc8fb761fb668e409a916d4ff72c6fce6bd3d3d54/mounts/shm


root@Wolke22:~# du -sh /*
0       /bin
0       /config
244K    /dev
3.5M    /etc
2.4M    /etc.defaults
4.0K    /initrd
0       /lib
0       /lib32
0       /lib64
4.0K    /lost+found
4.0K    /mnt
16K     /opt
du: cannot access '/proc/7898/task/7898/fd/12': No such file or directory
du: cannot access '/proc/7898/task/7907/fdinfo/12': No such file or directory
du: cannot access '/proc/7898/task/8051/fdinfo/12': No such file or directory
du: cannot access '/proc/20787/task/20787/fd/3': No such file or directory
du: cannot access '/proc/20787/task/20787/fdinfo/3': No such file or directory
du: cannot access '/proc/20787/fd/3': No such file or directory
du: cannot access '/proc/20787/fdinfo/3': No such file or directory
0       /proc
12K     /root
15M     /run
0       /sbin
0       /sys
1.8M    /tmp
1.1G    /usr
803M    /var
4.0M    /var.defaults
255G    /volume1


root@Wolke22:~# du -sh /usr/*
96M     /usr/bin
20K     /usr/etc
64K     /usr/include
275M    /usr/lib
13M     /usr/lib32
0       /usr/lib64
20K     /usr/libexec
279M    /usr/local
24M     /usr/sbin
134M    /usr/share
224M    /usr/syno

Ich freue mich sehr über Hinweise, die zur Verhaftung des Speicherfressers führen!
LG

 

[geimist]

/var scheint mir sehr groß zu sein. vermutlich zu viele Logs in /var/log …?

 

[PingIng]

Ist das 44MB groß? Oben stand 803M...

root@Wolke22:/var/log# du
4       ./cache-advisor/history
8       ./cache-advisor
340     ./diskprediction
4       ./cluster
6268    ./disk-latency
340     ./nginx
7480    ./surveillance
4       ./openvswitch
4       ./selfcheck
4       ./fsck
4       ./pstore
4       ./samba/cores/nmbd
4       ./samba/cores/smbd
12      ./samba/cores
1088    ./samba
8       ./bios
4       ./journal
40      ./synomibclient
4       ./healthtest
748     ./systemd
4       ./sssd
2068    ./synolog
308     ./Docker
920     ./packages
112     ./smart_result
44344   .
root@Wolke22:/var/log# du -sh
44M     .

 

[geimist]

Eben, die 800 MB fände ich zu groß …

 

[peterhoffmann]

/var/log scheint es eher nicht zu sein.

Schau mal direkt in /var
Dort liegt irgendwo dein Problem.

 

[himitsu]

sudo du -xhd 2 / | sort -hr | head -n 50 | sort -k 2

die ersten paar Zeilen reichen ja (vor allem wenn man viele/alle Ebenen auflösen würde, wird es schnell mehr als nötig)
die erste 2 und die 50 kannst noch etwas hoch-/runtersetzen, um mehr oder weniger Ebenen/Einträge im Dateisystem aufzulösen

 

[PingIng]

Sehr nettes Kommando. Da fehlt mir Übung.

root@Wolke22:/# sudo du -xhd 2 / | sort -hr | head -n 50
1.9G    /
1.1G    /usr
774M    /var
608M    /var/lib
279M    /usr/local
275M    /usr/lib
224M    /usr/syno
134M    /usr/share
96M     /usr/bin

In /var/lib sehe ich dies:

root@Wolke22:/var/lib# sudo du -xhd 2 /var/lib/ | sort -hr | head -n 50
608M    /var/lib/
600M    /var/lib/synosmartblock
3.5M    /var/lib/portforward
3.1M    /var/lib/portforward/routerdb

synosmartblock wird es dann wohl sein. Dazu recherchiere ich noch.

 

[PingIng]

Ok dazu gibt es Threads, z.B. https://www.synology-forum.de/threads/dev-md0-100-belegt.114501/#post-939187

Ich hab das gelöscht mittels

rm -fv /var/lib/synosmartblock/*

und der Spuk ist vorbei.
Platz für Aktualisierungen wieder genug da.

Ich danke Euch!!

 

[himitsu]

Das klingt irgendwie nach vielen Loginversuchen?
z.B. weil deine DS öffentlich im Internet mit Standardports erreichbar ist, irgendjemand bissl neugierig ist und unverfänglich mal bei dir reingucken möchte.

Dazu gab es schon mindestens einen Thread, in letzter Zeit, wobei auch die Systemplatte voll lief.

[edit]
jupp

 

[PingIng]

Das ist sehr plausibel.

Da ist zwar nichts öffentlich erreichbar aber ich hatte wochenlang (wenn nicht Monate) die Situation, dass ständig Warnungen kamen im Sinne von
Die IP xy wurde wegen Überschreitung der Login-Fehler gesperrt.
Diese IP war allerdings die der DSM selbst! Ich hatte das nach längerer Suche auf den ioBroker zurückgeführt. Und gelöst nur nur Löschen des Containers und Neuinst mit neuem Image.

Nochmal Dank!